编程新手求问大家对设计模式都怎么看？（主要是动态语言）

[sethverlo]

[fanzeyi]

大大又在装新手了..

[sethverlo]

@fanzeyi 你妹…最近关于这个很困惑啊……

[tioover]

好像有时候听别人提起过，也在书店的书架上看到过……但是感觉太厚就没看。

[senghoo]

程序大了就必定需要一定的设计，但是过度的设计是灾难。

[subpo]

新手一枚，我自己的做法是找一篇设计模式讲得好的不是非常长的文章看看，了解一下。然后上手使用设计模式的类库等工具，等我用熟了，感觉到了好处，再去看书。

[FrankFang128]

听说有设计模式的存在是因为面向对象的弊病太多。

[felix021]

我的学习经历基本上是 困惑->膜拜->理性对待 这样的感觉。

困惑的时候，是写了一些代码以后，发现自己不管怎么改进，似乎写出来的代码都挺恶心的，写不了多少就受不了了，然后删掉。

后来了解到有设计模式，找了本《Head First 设计模式》看了些，觉得设计模式的确可以解决当时的困惑，产生的崇拜感甚至让我在自己的毕设里的某些地方为了使用设计模式而是用设计模式，现在回头想想觉得挺傻的。有些模式因为实用，其实日常不知不觉在用着（也许你都不知道原来你对某些问题的实现方式有个别人起好的名字），但是因为实践不够多，有些模式其实看过了也就忘了。

后来看到的、写过的代码越来越多，就发现其实设计模式没有那么神。对于设计模式，业界也有很多争论。

类似 @FrankFang128 所说, “在 Lisp 这样的动态（函数）语言中，由于不需要管理类和对象，不需要解决类给设计上带来的限制， GoF 的 23 种模式中，有 16 种要么用不着，用语言本身提供的机制就可以了，要么实现起来要简单得多。” ，出处:http://blog.csdn.net/liujiangce/article/details/4867748。

正如这篇文章的标题，《设计模式是编程语言本身太弱的表现？》，比如在Python里头，decorator作为语言的内建解决方案，你可以很自然地完成一些其他语言里必须麻烦地使用decorator模式来实现的东西。

但是这篇文章的观点似乎对函数式编程有过多推崇。比如Haskell“装纯”的代价，使其必须引入一种叫做 monad 的东西，来解决有关状态的问题，这个可以认为是Haskell的设计模式，只是它不在GoF里面（p.s. haskell/monad我实际上没太多了解，所以这个理解也可能是错的）。

总结一句我的看法：设计模式有相当的指导作用，但是需要理性地对待。

p.s. 貌似设计模式的狂热崇拜者大多是纯Java程序猿。这可以列入我讨厌Java的理由之一。。。

[luikore]

java 专用名词. GoF 模式算啥, wiki 模式大全里有几百种呢... 硬要把模式套到动态语言/函数式的话:

动态语言的成员查找是 service locator 模式, 等价于依赖注入 -- 我们都知道用了 DI 以后很多模式都可以不用了.
动态语言的执行主要是解释模式
动态语言的方法调用是命令模式
对象层级是原型模式
动态语言没有静态成员, "类方法", "类属性" 全是单例模式的应用
function/lambda/block 是 visitor 模式
...

或者说 java 程序员需要艰苦修炼才能用出来的设计模式, 在其他语言里就像呼吸空气一样平常, 使用者甚至不需要意识到自己是在应用"模式".

@felix021 反了, 应该说很多语言有状态的问题, haskell 就没有状态的问题. haskell 的 monad do-notation 语法糖里看似状态的东西其实都不是真的状态, 不会出现并发修改同步或者死锁等等状态导致的问题, 因此特别适合处理带复杂状态的程序.

[felix021]

@luikore 好吧，我说得不够清楚，我说的“状态的问题”，更准确地说是haskell里“没有状态的问题”，遇到伪随机数生成器这种需要状态的问题，在其他语言里实现起来很自然的，在haskell里就得蛋疼地用monad这种东西来解决——这就是我所说的“装纯”的代价。

[luikore]

@felix021 你为什么要说"蛋疼地"... randomIO 签名是比较复杂, 但用起来写到 do 里就和其他语言写法没什么区别啊

[felix021]

@luikore 因为我不了解haskell = =. 所以有些表述可能不太准确。等看完sicp以后，我会找点haskell的东西再深入了解下……