设计模式的原则

综述

为什么要提倡"Design Pattern"呢？根本原因是为了代码复用，增加可维护性。那么怎么才能实现代码复用呢？面向对象有几个原则：开闭原则(Open
Closed Principal，OCP)、里氏代换原则（Liskov Substitution Principle，LSP）、依赖倒转原则（Dependency
Inversion Principle，DIP）、单一职责（Single Responsibility Principle ，SRP）、合成/聚合复用原则（Composite/AggregateReuse
Principle，CARP）、最小知识原则（Principle of LeastKnowledge，PLK，也叫迪米特法则）。开闭原则具有理想主义的色彩，它是面向对象设计的终极目标。其他几条，则可以看做是开闭原则的实现方法。

设计模式就是实现了这些原则，从而达到了代码复用、增加可维护性的目的。

单一职责

新手机功能固然强大，功能五花八门的，但是当我们需要某一功能而且这个功能发挥的作用要很好的时候。这部手机就没有单一的电子产品的设备强了。

所以一件产品简单一些，职责单一一些，或许也是更好的选择

单一原则，就一个类而言，应该仅有一个引起它变化的原因。

软件设计真正要做的许多内容，就是发现职责并把职责相互分离。如果想到多余一个的动机去改变一个类，那么这个类就具有多余一个的职责。

这样代码才能做到容易维护，易扩展，易复用，灵活多样。

这里说到了一个方块游戏的问题

方块游戏的界面变化和游戏逻辑应该分离

开放封闭原则

是说软件实体（类，模块，函数等），应该可以扩展，但是不可以修改

两个特征。对于扩展是开放的。对于更改是封闭的。

怎样的设计模式才能面对需求的改变却可以保持相对稳定。从而使得系统在第一个版本以后不断推出新版本呢。开放----封闭原则给我们答案。

多扩展，少修改是维护软件的最好处理办法。

这里有个很好的实例，如上班迟到的问题。

如果你是老板，规定九点上班，不允许迟到，但是有几个骨干，老是迟到，你怎样做呢。

严格执行考勤制度，迟到扣钱？这个是够狠的，但实际情况是，有的员工离家远，交通一堵车就不得不迟到了。

允许他们迟到。这个弹劾容易呢。别的不迟到员工就不答应了。

那怎么解决呢。老是迟到的却不好，但不让迟到也不现实呢。其实迟到不是主要问题，每天保证8小时工作量度是老板需要的，甚至8小时工作也不是i主要问题，业绩目标完成才是重要指标，于是应该变管理方式，比如弹性上班工作制度，早到早下班，晚到晚下班。或者每人每月允许迟到3次，迟到者当天下班补时间等等。这其实是对于工作时间的修改关闭，而对时间制度扩展是开放的。

何时应对变化

设计时，时刻哟啊考虑，尽量让这个让这个类是足够好，写好后就不要去修改了。如果新需求来，增加一些类就完事了。原来的代码能不动就不动

迪米特法则

如果两个类不必直接通信，而具体办法就是引入一个外观对象，他为子系统间提供一个单一而简单的屏障。

里氏代换原则

一个软件实体如果使用的是一个父类，那么一定适用于其子类，而且它察觉不出父类的对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。

里氏代换原则：子类型必须能够替换掉它们的符类型

只有当子类可以替换掉父类，软件单位的功能不受影响时，父类才过真正被复用，而子类也能够在父类的基础上增加新的行为。

里氏代换原则是由"BarbaraLiskov"提出的。如果调用的是父类的话，那么换成子类也完全可以运行。比

可以说：里氏代换原则是继承复用的一个基础。

依赖倒转原则

抽象不应该依赖于细节，细节应当依赖于抽象。

要针对接口编程，而不是针对实现编程。

传递参数，或者在组合聚合关系中，尽量引用层次高的类。

主要是在构造对象时可以动态的创建各种具体对象，当然如果一些具体类比较稳定，就不必在弄一个抽象类做它的父类，这样有画蛇添足的感觉

合成/聚合复用原则

合成/聚合复用原则(Composite/Aggregate Reuse Principle ,CARP)经常又叫做合成复用原则。合成/聚合复用原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。它的设计原则是；要尽量使用合成/聚合，尽量不要使用继承。

就是说要少用继承，多用合成关系来实现。我曾经这样写过程序：有几个类要与数据库打交道，就写了一个数据库操作的类，然后别的跟数据库打交道的类都继承这个。结果后来，我修改了数据库操作类的一个方法，各个类都需要改动。"牵一发而动全身"!面向对象是要把波动限制在尽量小的范围。