多少有些标题党了。首先声明一下，就我个人来说，我对设计模式没有丝毫反感。我反感的是空泛地没有标的地讨论设计模式，或者说言必谈设计模式。 起因是和同事的一次讨论。讨论的过程不便多说，只说下我的观点：只为学习设计模式而学习设计模式是没有意义的，这样无助于写出好的代码，反而容易写出晦涩的代码。那什么是好的代码呢？在我看来，好的代码起码得有三好：好用、好看、好维护。 好用，指的是写出的代码必须得能满足需求，不然再好的代码都是无意义的代码。 好看，是说代码最少得看起来顺眼，需要遵循普遍约定的格式，类和方法需要有必要的文档（是的我是一名光荣的java程序员），复杂的逻辑处需要有注释。这一点可以参考一些大公司的编码规范，比如Google编码规范或阿里巴巴编码规范（这个真的是良心之作，有详细的pdf文档，还有eclipse和idea插件）。 好维护，这个说起来很容易就话长了。说下我的看法吧：以一个普通的合格的实习生为例，这个实习生理解并做到可以修改你的代码所用的时间，这个时间需要和代码实现的需求的复杂度成正比。注意，这里说和时间成正比的不是代码的复杂度，而是业务需求的复杂度。也许只是写一个“Hello World!”你就用到了十三种设计模式，你的代码精巧无比，但是没有毛用，这个程序本来最多只需要4行代码一分钟的时间就能完成，理解它本应该也不超过一秒钟。当然，能把简单的事情搞复杂也是人才，自然也有他们的用武之地。 我这里说的“三好”代码和设计模式没有必然的关系。有人也许会问：代码不按设计模式来写那按什么来写呢？ 我的答案很简单：按需求来写啊。不过在实现需求以后还得多想想你的代码是不是好理解好维护，有冗余的地方就删掉，有复杂的地方就尝试进行简化，简化不了就写上注释，总之尽量把事情搞得简单些，越简单才越见功夫。没看见么，小李飞刀也就那么简简单单的一刀。这样写出代码也许没有遵循任何一种现成的设计模式，但是绝对是最符合需求的模式。 当然，在一开始我就提过了，我并不反感或反对设计模式。我反感的是空谈设计模式，或者将设计模式作为金科玉律。设计模式当前有用，毕竟是前辈们作出的总结，学习一下还是很有必要的。观千剑而后识器，胸中有锦绣才能做出文章。但是将之作为规范就没有必要了。 我见识过一个方法有几百上千行的代码，也见识过因为开发者野心太大而将一个简单需求搞得复杂无比的代码，也见识过为了使用一些新的特性或功能而将整体结构搞得一团糟的代码…林林总总的，大体上都是为了赶上deadline或满足开发者一时的快意而写出的糟糕的代码。对于这些，我只是希望能够在需求没有那么紧张的时候抽时间做些优化，或者在写代码的时候想想以后接收接手你的代码的人是不是会很窝心。 不写了不写了。话早就说尽了，现在已经有些唠叨了。就这样吧。