在开发中体验设计模式
—————记于一个新开始之前
我一直推崇（admire）设计模式，但是我也不赞成滥用（abuse）设计模式。之于设计模式，我经常遇到的有两种误导（mislead）：一种是将设计模式蒙上一层高深的神秘色彩，认为设计模式是一门非常高深的技术（或思想），在一般的开发和设计中无足轻重，也不会用到，可以置身事外、得享清净。另外一种则对设计模式嗤之以鼻，认为设计模式不过如此，我们很多的设计和开发中根本就没有去考虑什么设计模式，系统已然work，项目已然收工，不必用到，又何必劳神伤时、自讨苦吃。
既然我称之为误导（mislead），自然是有一些感想和思考的。之于前者，我的观点依旧是“道不远人”，设计模式就是面向对象分析和设计OOA/D中的“道”。设计模式的最终体现应该是一种思想，一种指导。而这种思想，这种指导，则正是我们在OO系统开发中所必需的。设计模式之所以会被人认为高深，很大的一个原因在于设计模式是一种设计层面上的技术（思想），而设计在目前很多的企业和公司经常被忽视或者轻视了。在我看来，设计模式中描述的各类模式，实在和面向对象的基本思想（封装、继承、多态）是如出一辙，只不过设计模式很多情况下会强调怎样通过OO中的多态、继承获得更大的工业级的复用、维护和扩展。原因也很简单，两者都是OO的一部分，不曾冲突，而是相得益彰。一个单纯的编码人员需不需要学习掌握设计模式？我们是否可以得享清净？在我看来，每个从事OO系统开发和设计的从业人员，都应该学习掌握设计模式，不过可能侧重点可能可以不一样：设计人员或更高抽象层次可以更多关注设计模式的使用场景和应用效益，而编码实现人员则需要更多关注设计模式的实现方法。设计模式的学习过程是一个非常痛苦并且不会短暂（至少我这样认为）的过程，但是这是必需的。而这个过程中获得最多的正是对于OO设计的一种潜移默化，这种潜移默化的效果则会直接体现在我们以后的面向对象系统的分析和设计中去。
之于后者，后者这种观点的存在是很有实际基础的。诚然，在我们身边，甚至是自己身上、自己正在经历的项目开发中，唯一的目标就是系统的运行（work）。我们会给开发的目标按照优先级派一个顺序：1）可工作（work）；2）稳定（robust）；3）性能（performance）；4）扩展（expansibility）；5）复用（reuse）。而设计模式更多关注的正是扩展性和复用，似乎更多的时候我们可以完全不必考虑什么设计模式。但是有一点我们是忽略了，那就是用户的需求变更，而这一点在我们身边的、自己身上、或是正在体验着的就是用户无休止的需求变化。小的变更，可能我们可以充当救火队长，四处打补丁完事，然而很多情况下用户简单的一个需求变化要引起我们设计的变化，那就不是简单补丁可以完事了。死亡（death）、税收（tax）和需求变更（requirement variation）被称之为程序员的3大罩门，因此在系统的设计之初作一些必需的扩展性考虑以及适当的需求变更策略是很有必要的，很多事情并不是像我们第一眼想象的那么简单。然而过度设计也是在开发中的一个非常忌讳的事情，本来就很复杂的东西，何必要复杂之中让它更加复杂，滥用技术是不可取的，这个度的控制则真正是很深的学问和经验了。说了这么多，只是说明设计模式是必要的，即使在小的系统开发之中也是有价值存在的。我手头正在进行和技术负责的一个不是很大的项目中，不同的模块没有能够很好统一（原因同道中人自然了然于心：）），更多的都是一个类搞定一切。似乎一切也都OK，但是我使用Bridge模式将抽象和实现解耦，通过Decorator模式动态添加需求，模块设计简约合理，并且我可以保证在一般的用户变更可以从容应付。而这一切也不是说要很高深的技术，只是需要一个合理的思想来指导。因此也在另外一个角度说明，设计模式的思想是值得我们去采用的。
然而，说总是让人觉得煞有介事，但是却让人觉得不着实际。之前曾用C++将GoF描述的23种设计模式写一遍（共享了源码和解析，可以下载PDF文档参考），也对设计模式进行了研习和思考的探索，并在经历的一些项目和开发中使用了其中的一些具体的模式或者思想，因此准备将这些经历和经验也记录下来。再加上分析经典系统源码的经验，名字叫做《在开发中体验设计模式》，也算是给自己的一个任务和要求，我希望自己能够有足够的时间和精力来完成。
在开发中体验设计模式，Enjoy R&D，Enjoy Life。
k_eckel
