我感觉有时候往往出现这种情况,代码越美观,结构越好,或者用了更多的设计模式,会大大的增加人对业务逻辑的学习和接收难度,这是怎么回事?

代码

逻辑

设计模式

18 条回复 • 1970-01-01 08:00:00 +08:00

1

ipconfiger

2013-08-20 09:58:21 +08:00

3

这个时候说明你已经被“设计模式”带沟里去了，哈哈。

2

fangzhzh

2013-08-20 10:32:00 +08:00 via Android

设计模式一般就是把易变的东西抽象出来抽象一层复杂一层

3

luikore

2013-08-20 10:53:01 +08:00

"美观", "好" 是因人而异的主观概念
抽象必然导致难懂, 设计模式, 是给不懂抽象的人来装懂用的

4

otakustay

2013-08-20 11:43:10 +08:00

1

学习和接受难度是一回事，学完了以后的工程效率是另一回事
学习曲线陡峭不代表完成学习后依旧要艰难地进行开发
工程师最终负责的应当是整个系统、产品的生产效率，而学习只是其中的一部分，并不是全部

5

fucktwice

OP

2013-08-20 14:43:49 +08:00

@otakustay 哥,给个结论呗

6

otakustay

2013-08-20 15:42:43 +08:00

@fucktwice 结论我已经表达了啊，代码美观、结构好，代码的仅仅是“学习难度有所提升”，但学习完成后，开发的效率是有非常大的优势的
比如不美观结构一条线的代码，学习只要10天可以上手，以后一个功能开发5天
而美观结构好的代码，学习用了40天，以后一个功能只要2天
这么一算，10个功能是一个转折点

所以我还是更倾向于代码美观和结构合理，除非你们想当临时工

7

levn

2013-08-20 16:14:22 +08:00

应该有结构好同时也更容易理解的吧。

8

chisj

2013-08-21 12:38:21 +08:00

模式就是为了让代码更好理解和维护的，不然就是耍流氓。

9

ksc010

2013-08-21 13:28:36 +08:00

@otakustay 同意
其实就类似于使用 vim和记事本的区别

10

luikore

2013-08-21 13:34:58 +08:00

@otakustay 易学不代表容易维护, 但以为难学就容易维护升级就错了...

11

luikore

2013-08-21 13:51:54 +08:00

@ksc010 模式和 vim 完全相反: 用了模式后, 总代码量会增加, 但用了 vim, 总按键量会减少.

如果一个模式可以重用, 它就是个 api call 而不是模式了. 模式说白了就是复制粘贴一坨东西然后改改名字调个顺序, 这就违反了软件设计的三原则(DRY, KISS, YAGNI)之一: don't repeat yourself.

随着编程语言不断添加特性和库的增强, 需要用到模式的场景会越来越少. 语言的特性需要学习去理解, 模式就是个类比根本就不存在学习这回事(个别名字起得很晦涩的模式除外)... 模式在不会模板元编程的 C++ 程序员和不会函数式编程的 java 程序员中特别流行. 就 java 说, 很多模式要做的事情现在直接加个 annotation 就可以了, 不需要一遍又一遍的重复拷贝那些错漏百出的实现...

12

fucktwice

OP

2013-08-21 14:33:28 +08:00

@luikore 模板元编程这个本来就需要花很大功夫去学习的, 你说的是把代码的重复用语言特性去减少,但是大多数的语言在OO方面都是类似的.
这个....

13

otakustay

2013-08-21 14:36:08 +08:00

@luikore 赞同“难学就容易维护升级就错了”，但这并不代表“难学就一定不易维护升级”，一定的学习代价确实能换来未来维护升级的优势，我个人也并没有针对楼主单个案例来表明“一定是后续易维护所以你要忍受着”这样的态度，可能是信息传递有些问题。

另外，如果说模式就是“复制粘贴一坨东西然后改改名字调个顺序”，只能说对模式的理解还只限于照着书抄Design Pattern的程度，尚为肤浅。

语言和库的增强，只是将模式变得更容易使用（通过语言特性等解决，比如事件之于观察者），但并不代码就不用模式。如果没有对观察者模式的理解，一个工程师可以设计出使用事件的系统？总之我不这么认为。

14

luikore

2013-08-21 15:02:07 +08:00

@otakustay 反了, 是先有工程师设计出了使用事件的系统, 然后才被人总结成设计模式...

在表达力比较弱的语言里, 用设计模式写的 XxxSingleton, 就得自己写 getInstance. 抄/背诵/IDE生成和拷贝粘贴是一回事.

用元编程实现的 XxxSingleton, 你不用自己写 getInstance, 它实际上就是个 API call 了, 叫不叫设计模式都没影响, 也避免了无谓的重复.

15

otakustay

2013-08-21 15:06:39 +08:00

@luikore 设计模式和模式是两回事，事件系统的出现就代表了“观察、订阅、分发”这一模式，随后被总结为“设计”模式，仅仅是挂了个名字并总结出一个共性

我们一直在谈的，是“模式”，而不是“设计模式”，这两者有很大的区别。无论是架构、设计还是开发过程，模式是始终贯穿的，而设计模式仅仅是对模式的一种常见的表达方法，取其优而去其粗即可。

所以我才说对“模式”理解成“复制粘贴一坨东西然后改改名字调个顺序”，那就等同于把“模式”和“设计模式”混为一谈，并不是一个值得推广的思路吧

16

msg7086

2013-08-21 15:32:21 +08:00

比如说吧，RoR，之前我学习的时候感觉非常累。但是做开发的时候用PHP写很久的代码，RoR很快就能写完了，各种框架包办。大概就是类似的感觉吧。

17

luikore

2013-08-21 15:41:54 +08:00

@otakustay 我一直指的设计模式. 广义的"模式", 含义太广泛, 不是 well-defined 的概念没什么好讨论的...

一种是正常人的思路, 看到问题去想怎么解决, 然后自然形成的代码结构和项目结构, 容易看懂容易改.

一种是架构太空人的思路, 先套用各种模式作出结构来, 再把问题交给别人解决, 太空人的理解(我们常常把"习惯"当"理解"用)和一般人区别越大, 就越难看懂和修改.

18

luikore

2013-08-21 16:15:02 +08:00

@otakustay “观察、订阅、分发”模式也是一个类比的设计模式(有人会把它升华到"夹沟模式"), 除此之外什么都没有说, 看到的人可能以为自己"理解"了, 但其实最后看代码才知道是什么回事. 两个人脱离实际讨论一个假大空设计模式, 很可能说的完全不是一回事, "这类概念可以交流"是个错觉而已.

光就 pattern 这个词来说, 在 "设计模式", "代码模式", "模式识别", "模式匹配", "正则模式" 语境下意思各不相同. 还有博大精深语把 mode 也翻译成 "模式", 进一步把浆糊搅得更浑, 造成微妙的"深刻"的错觉. 你说的"模式"如果不是设计模式, 那到底是什么? 如果没有一个人人都同意的准确定义, 那这个概念就是不值得讨论的, 也无法对我们的代码产生有意义的影响.