IT圈一直有轮回，一开始说某某某东西非常好，似乎出现了救世主，依靠它能解决一切问题，再过段时间，用的人多了，就慢慢出现异样的声音，再过段时间很多人就开始提出反对的口号，甚至全盘否定。设计模式就是这么一个概念。
十多年前，国内的软件开发还处于粗犷式的野蛮发展阶段，各种码农写各自的代码，码农之间经常看不懂对方在写什么东西，同时又互相轻视对方的代码水平。直到有一天，不知哪冒出来设计模式这一术语，顿时天亮了，各种码农，不管有事没事，不管有懂没懂，都开始啃Gof的书，开口闭口设计模式，一时间成为一种高大上的流行，你要不会写过抽象工厂，你都不好意思和人说自己是码农。风水轮流转，现在设计模式没之前那么火了，甚至有人开始质疑，并认为设计模式带来了太多的流毒。网上流传甚广的就是一个hello world的例子，简简单单的一行代码，被设计模式强奸的体无完肤，先后用到抽象工厂，单例模式，观察者模式，最终输出了hello world。这个笑话现实中也有很多人在写。
设计模式是从通用的代码方案中提炼出来，形成一种可以复用的经验，并不是说它是最好的，但如果场景恰当，就像套模板一样使用，并且大多数情况下都不是最坏的方案。但这里的问题就是何为场景恰当。有人认为这里该使用策略模式，有人认为该使用代理模式，这种情况下，谁是老板谁说的就是对的，不要去争执。
使用设计模式，或者说使用这些经验能让代码更灵活，它封装了部分变化模式，降低了耦合，并且能很好的扩展和复用，当需求变化时，采用合理的设计模式使得代码改动非常小。但是问题来了，需求怎么变，是难以预知的，产品经理并不会因为你使用了这个设计模式，而去迎合你规定的变法。产品经理定出来的变化千奇百怪，防不胜防，这时候即使你精通各种设计模式，也无法做出良好的设计。（这一切不能全怪码农，而应该怪产品狗。很多软件产品，还不需要惊动设计模式这种高大上的武器）。这也是很多人提出避免过度设计的一个理由，因为很多设计都是徒劳，但是如果码农非常熟悉行业领域，能够预判哪里会出现变化，那倒是可以赌一把，也许套对了模板之后，很多事情做起来就方便多了。
设计模式是为了弥补丑陋的语言。 很多主流语言，都内置了设计模式，在不知不觉中已经使用到了。正如网上的一个文档，
http://cdn.oreillystatic.com/en/assets/1/event/12/_The%20Lack%20of_%20Design%20Patterns%20in%20Python%20Presentation.pdf里面有句话This pattern is invisible in languages with first-class functions（摘自维基百科），意思就是函数式语言中很多设计模式被隐藏了。（first-class functions是指语言将函数视作一等公民）。
观察者模式——当一个对象变化时，观察到这种变化的对象，也能做出一些变化。在C#中的delegate/event很好的解决了这种问题。
单例模式——不用再去纠结什么双重检测之类的问题了，在C#直接使用静态变量，在Java中是用枚举类型。
简单工厂模式——通过传递泛型类型，在C#中直接使用 Activator.CreateInstance();Java中也有类似用法。
装饰模式——动态的给一个对象加上额外的功能。C#中使用属性标签就可以完美解决。
策略模式——C#中是用delegate，能更简单的封装策略。
迭代器模式——C#和Java中完美的支持。
还有很多模式，可能我这辈子都用不上，比如那个抽象工厂模式，一直没遇到需要用这个东西的地方，还有命令模式，享元模式，也从未用到过。但这并不影响我写代码，没有这些模式的羁绊，代码写的也很顺畅。（也许确实水平有限，还未能正确的套模板）。
胡适说的对，多研究些问题，少谈些主义。多解决些问题，少谈些模式。
本文出自 “一只博客” 博客，请务必保留此出处http://cnn237111.blog.51cto.com/2359144/1665933
原文地址：http://cnn237111.blog.51cto.com/2359144/1665933
