设计模式，应该是很多ED心目中牛B的编程方式。

上回说到ED的好书POEE，实际上便是一本专门讲企业开发中使用的设计模式中的书。

设计模式，并不多，基本上看完GoF的这边《Design Pattern》便可以有足够了解了。

而实际开发中常用的设计模式更是屈指可数，Singleton，Factory，Facade，Active Record、Provider等等。

就那么几个，花花功夫，仔细了解一下这几个，然后在实际编码中应用一下，便可以算是掌握了。

设计模式，并不难。

它是开发中非常必要的知识，实际上，是非常基础的知识，并不牛B。

开发的时候，需要时刻明确自己的目标：解决问题。

解决问题才是最重要的。

设计模式的存在，是为了更好的维护、管理代码，或者是为了扩展性；绝对不可以为了设计模式而模式。

在Java程序中，为了模式而模式的现象蛮普遍的。

我猜想这是因为Java是一门工业语言，有大量的ED使用的缘故。

ED把设计模式的使用，当成是一种可以炫耀的编程技巧，或者说，他们遵从的编码规范中，要求他们去使用某某设计模式。

至于为什么要使用设计模式，最常见的理由便是：为了将来可以XX，或者YY。

程序开发中，有一句名言：“Pre-mature optimization is the root of all evil”。

过早优化，是万恶之源。

非常多的情况下，将来预想中的XX或者YY；并不会发生。大部分代码，写了之后就会被丢弃掉，再也不会有人去维护。

当XX或者YY发生的时候，往往，都是会推倒重来。

除非你很牛B，只有牛到一定程度，才有可能对将来可能发生的情况做好合理的预测，并预留出改善、调整的空间。

但非常讽刺的是，为将来做设计的最好方法就是：什么都不做。

只有空白，才能够留下最大的发挥空间。

现在为将来可能发生的情况，做了编码，任何一行编码，都是很可能是在为将来添加限制、制造麻烦。

现在写下去的代码，将来，都是要被删掉的；能够不写，就不写。

在任何时候，都应该保持代码简洁。

函数，尽可能的短；当一个函数的长度，超过一个屏幕的时候，便应该考虑重构、拆分。

牛B的程序，都应该是简单、易懂的；采用大量的设计模式，复杂得让人无法直接看懂，或许有它的意义以及应用场景，但这绝对不是编程功力牛B的表现。

打个比方，设计模式就是武术招式。

学徒，必然需要熟悉什么“有风来仪”或者“屁股朝后平沙落雁式”。

但更高的境界是：无招胜有招。

简单、直接的把代码搞定。

Python大牛沈崴有云：“得道的程序员，既不封装，也没有重复代码。”

作业：

1. 使用一种编译语言实现 Singleton 模式

2. 使用一种动态语言实现 Singleton 模式

3. 说说对 Provider 模式的理解。

男主角：Wuvist（），真名翁伟，自称胖程序员一个，幸好已婚。学习.NET出身，现常用Python做服务器端开发，曾任新加坡某创业公司主程。公司被Techcrunch blog过后，觉得新加坡生活太过安逸，终于在去年辞职只身回家乡汕头创业，活跃于珠三角技术沙龙，热衷于与其他技术宅分享。

本文作者：Wuvist

女主角：Katze，Wuvist的老婆，女程序员，在某跨国投行任Unix系统管理员，常被Wuvist嘲笑技术太差。

51CTO系列：

本文转自 Wuvist 51CTO博客，原文链接:http://blog.51cto.com/wuvist/847706