设计模式（四）几个设计原则

在设计模式的选择使用过程中，为使软件具有可拓展、可复用、高灵活、易维护的优点，我们需要了解几个设计原则。

1. 单一职责原则

软件编码过程中，如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计或遭受到意想不到的破坏。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。——《大话设计模式》

简单说，在前面简单工厂模式的例子中，最初级的计算器实现方法就是让一个类承担了所有的职责，包括接收、返回客户端参数，分支判断，逻辑运算，具有很高的耦合性，不论是扩展还是修改，成本都较大并且可能对既有的功能产生影响，而后来我们使用简单工厂模式或者是策略模式对其进行改进，就将负责各个职责的代码剥离了出来，降低了耦合度，减少了修改和扩展的成本。

又或者，我们在平时的开发过程中，一定有过对某些工具方法封装的经验，比如日期处理的方法，字符串处理的方法，加密方法等，封装成工具类以便于我们复用，这是不是也体现出了单一职责原则。

2. 开放-封闭原则

开放-封闭原则（开-闭原则）是说软件实体（类、模块、函数等等）应该可以扩展，但是不可以修改。即对扩展开放，对更改封闭。——《大话设计模式》

当然， 绝对的 ”对修改封闭“ 是不可能的，面对需求的变化，我们不可能完全保证原有的代码不做任何修改，只通过增加类的方式实现新的需求。无论模块多么的封闭，都会存在一些无法对之封闭的变化。既然不能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择，他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。

开放封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象设计技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。我们应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意的进行抽象同样不是一个好主意，拒绝不成熟的抽象和抽象本身一样重要。

其实策略模式就是一个很好的体现，我们将加减乘除操作分成子类，析取出来一个父类（当然也可以改成抽象类或者接口），如果要扩展一个操作，需要再增加一个子类复写父类的getResult()方法（对扩展开放），在OperationContext类中只需要增加一个case分支来获取新的操作类的对象即可（更接近于对修改封闭）。

3. 里氏代换原则

一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且察觉不出父类对象和子类对象的区别。也就是说在软件里面，把父类都替换成它的子类，程序的行为没有变化。简单地说，子类型必须能够替换掉它们的父类型。只有当子类可以替换掉父类，软件单位的功能不受影响时，父类才能真正被复用，而子类也能在父类的基础上增加新的行为。——《大话设计模式》

这段话其实很好理解，子类继承了父类的属性和方法，所以子类必须可以代替父类出现。这个原则也是下面的依赖倒转原则的一个前置条件。

4. 依赖倒转原则
我们知道，现代的PC电脑里的部件其实并不来自于同一个厂商，Intel的cpu，Nvidia的显卡，还有各种厂商生产的硬盘、内存等等，这些部件组装成了一台完整可用的计算机，那为什么出自于这么多不同的厂商部件，最终可以组合在一起呢，拿cpu来说，不管是哪家公司生产的，对外都必须设计成针脚式或触电式的标准接口，这样，主板生产商也只需要给cpu预留针脚的插槽就可以了，而不用在意大家的cpu内部都是怎么实现的，cpu的厂商也不用管主板是怎么做的（对应到之前说过的单一职责原则）。当电脑内存不够时，我只需要再插上一跟内存条，硬盘空间不够时可以插上移动硬盘，做这些扩展时并不会影响到其他的部件（开-闭原则）。

而依赖倒转原则，其实说的就是要针对接口编程，而不要针对实现编程，cpu，显卡，内存，硬盘都是针对接口去设计，如果针对实现去设计，那是不是不同的厂商生产的cpu都需要配套的主板来配合呢。这样显然没有大家都针对一套标准的接口来设计来的高明。

依赖倒转原则： A. 高层模块不应该依赖底层模块，两个都应该依赖抽象。 B. 抽象不应该依赖细节，细节应该依赖抽象。 ——《大话设计模式》