写负责任的代码————读《设计模式解析》有感

  ——yuchenl

在读到这本书之前，我对于程序设计的理解，就像是设计一台复杂的仪器，将代码封装成各种形状的零件，然后用组合或者继承的规则将这些零件拼装起来。这大概算一个菜鸟程序员普遍的认识。

推荐给我这本书的人，告诉我这本书给他最大的启发，是“关注变化”。可能是在看这本书之前，我的起点更低，《设计模式解析》给我的振动，也更接近代码设计最基础的层次。这本书给我最大的教育，竟然不是设计模式本身的思考，而是书中对对象的看法：它不是具有某个功能的模块，而是一个负责任的个体！

这种对于对象理解的区别，对于整体的程序设计造成的影响，是颠覆性的。如果将对象仅仅设计为一个实现某功能的模块，那么接下来要做的，将是建立一个庞大的无微不至规则体系将这些模块契合起来。而如果对象都是负责任的个人，那么之后要处理的是规定这些对象对谁负责。显然前一种情况的维护成本要高得多，也不符合开闭原则——功能的增加或修改，极有可能触碰到规则体系，结果牵一发而动全身。

在明确了对象的定义之后，设计模式的精神就清晰了很多——不是设计如何拼装零件，而是如何经营个体之间的关系。从这个角度上看，facade模式，adapter模式都是为了个体能够简单地与另一个体交流；birdge模式是为了拆分设计团队和施工团队；observer模式处理两个人之间的触发联系；template method模式就像是团队的主程，他已定义了程序的骨架，由具体的手下来实现细枝末节；一个有趣的现象是，singleton的对象被普遍命名为manager，而一个“经理”手下确实要管理很多人。

运用设计模式的思想经营对象，确实是一件简单而愉快的事情，但是一个尴尬的事实是：当一个项目开始的时候，各个对象并不是显而易见地就可以建立，选择合适的设计模式，也不是那么简单。书中提到了多个分析问题的方法：共性可变性分析，从背景设计，我印象最深刻的是按责任分解问题域。作者在分析问题是奉行的一条原则是：抛开实现的细节不谈，仅关注两点：

1.需要有什么样责任的对象

2.如何创建和管理这些对象

（我想这也从某种角度上体现了《设计模式》一书中为什么把设计模式分为三类：1对应的行为型设计模式，2对应的创建 型设计模式，以及连接1和1，1和2的结构型设计模式）

除了遵循这两点之外，一些基本的设计原则也直接影响到将来代码的维护成本。

“一次且仅一次”原则：最近工作中深刻体会到，最难以修复的bug都是复制粘贴出来的。。。。。。

“依赖倒置原则”：代码的设计应完全依赖于抽象，不能依赖于某具体的关系。

对象的管理与使用的代码要分离。

另外作者特别提到的是，继承应该被看作一种将变化概念化的方法，而不是创建特殊的对象。

作者在书中多次提到自己在不知情的情况下推导出某个设计模式的情形，并在书的最后重申模式本身并不重要——真正重要的是模式中所描述的关系和约束。如果在分析问题时正确地自然地处理这种关系和约束，模式的出现将是水到渠成的事情。