【读书笔记】设计模式中的几个原则

    最近正在学习项目，把平时不注意的设计模式好好看了下，当看到《大话设计模式》中小菜犯的种种错误时，我发现其中绝大多数都是自己有过的。不得不说平时我们所见到的一些例程很多都是随意的功能堆砌，如果你只是COPY&PASTE到项目里那必定会造成很大的困扰。设计模式就是这样一种东西，做好了会让你更轻松，让你更愿意做下去；做不好了会成为你的负担，让你丧失编码的热情。

    设计模式中有以下几个原则：

    1、单一职责原则（SRP）

    “就一个类而言，应该仅有一个引起它变化的原因。”（此处及以后打双引号的地方是摘抄了原书的内容）这里我有所体会的是游戏设计中图形界面逻辑和运算控制逻辑的分离，游戏引擎大多都会将这两者分开，因为如何显示和如何运算并没有关系，在游戏中显示什么是由运算控制部分的结果决定的，它并不参与运算的过程。如果你将两个互不相干部分的代码放到了一起，那么将会造成职责的混乱，你的代码就变得浑浊而难以维护，没有人会愿意面对一堆杂乱无章的代码。

    2、开闭原则（OCP）

    ”软件实体（类、模块、函数等）可以扩展，但不可修改。“这条看似是一种命令或者强迫，但我觉得它所表达的是面向对象设计的最理想状态。我们只需要继承以前的代码而不用做任何修改，这样一劳永逸的事情总是最诱惑人的。但实际中这样做并不容易，我们在一开始就必须留下足够的余地，让后人能够在我们的基础上添砖加瓦，而这正需要设计者用长远的眼光看待问题，不能只看到现在的需求。这样我们就得在最初的设计上下足功夫，将根本的事物抽象出来，便于具体延伸，但如何建立正确的抽象却是困难的事情，这正是我们需要认真研究的地方。

    3、依赖倒转原则（DIP）

    ”高层模块不应依赖低层模块，两个都应依赖于抽象；抽象不应依赖于细节，细节应该依赖于抽象“。这条从名字上来看似乎让人摸不着头脑，不过在书中阐释了什么叫做依赖：高层模块会利用低层模块的东西（例如函数），这样的话一旦低层模块不再适用，高层模块便会受到影响，这样的高层模块便不再具有重用性，也就失去了它的意义。书中举了个生动的例子：企鹅和普通的鸟都属于鸟类，但如果我们往鸟类这个高层类中加入会飞的方法，那么企鹅也会飞，显然不符合实际，这样的抽象就依赖了会飞的细节，而实际上会飞并不是鸟类的本质属性，这样的抽象就是不成功的。依赖倒转就是把这种高层依赖低层的情况转回来，不过为什么是转回来呢？难道本不应该如此吗？但一不小心我们便会陷入这样的陷阱。

    这里还需提到里氏代换原则（LSP），即”只有将父类全部替换成子类而程序不会受到影响时，这个父类才能真正被重用”。

    4、迪米特原则（LKP）

    ”如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。“这条原则又被称作最少知道原则，意思就是一个类对其他不产生直接联系的类要尽可能不暴露任何接口，即利用private阻止与它们的联系。这是防止不相干的类对其进行修改，也体现了面向对象的一大重要特性：封装。有时候看似简单的特性越能引发大的问题，尤其是面对后期扩展的未知性，一旦你所暴露的接口对该类有着重大的影响，那么简单的调用就有可能致使难以预料的错误。

    此外接口隔离原则（ISP）是迪米特原则的延伸，它要求尽可能使用专门的接口而不是总的接口，这也意味着不要把不必要的接口带进类里，造成接口的冗余。而接口集成的东西越多，其越显得“笨拙”，耦合也就越高。

    总的来说，这些原则无不体现面向对象设计的核心要求：高内聚低耦合，而要想做得够好还需要不断地实践和研究。以上是一个初窥设计模式的菜鸟的一己之言，有所误漏请多指教！