设计模式的几种原则

设计模式的几种原则

一. 里氏代换原则

定义：

子类型必须能够替换它们的父类型。[DH]

解释：
也就是说，在软件里面，把父类都替换成子类，程序的行为没有变化。也只有这样父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。这个原则是对继承的一个约束，也就是说，继承中子类严格满足"is-a"的关系。

所以，当你看到一个继承的时候，要习惯性的把他的父类和子类看成一个整体，这样会有助于你去理解各个类之间的关系。

由于里氏代换的原则，才使得开放－封闭成为了可能。正是由于子类型的可替换性才使得父类类型的模块在无需修改的情况下就可以扩展。

例如：

这个继承关系就不满足里氏代换原则。

二. 单一职责原则

定义：

就一个类而言，应该仅有一个引起他变化的原因。[DH]

解释：

也就是说，不要把变化原因各不相同的职责放在一起，因为不同的变化会影响到不相干的职责。

再通俗一点地说就是，不该你管的事情你不要管， 管好自己的事情就可以了，多管闲事害了自己也害了别人。

这个就是说，一个类尽量做到了功能单一，比如在mvc中，判断数据的类和添加数据库的类一定要分开。单一职能不是说职能多了我们实现不了，是为了后期的测试维护，每个类的很单一，我们找错误的时候就可以一步到位，添加新的功能的时候，也不用牵扯到很多的类。

三. "开放-封闭"原则

定义：

是说软件实体(类，模块，函数等)应该可以扩展，但是不可以修改。 [DH]

解释：

意思是，在一个系统中，对于扩展是开放的，对于修改是关闭的，一个好的系统是在不修改源代码的情况下，可以扩展你的功能。

而实现开闭原则的关键就是抽象化。

在"开放－封闭"原则中，不允许修改的是抽象的类或者接口，允许扩展的是具体的实现类，抽象类和接口在"开放－封闭"原则中扮演着极其重要的角色，即要预知可能变化的需求，又预见所有可能已知的扩展，所以在这里"抽象化"是关键！

当然对于修改，我们不可能完全避免，也不可能完全预知到未来的变化，所以我们要做到尽量去不要修改，或者少的修改就能达到我们的目标。一旦要修改，就要充分的考虑出以后要发生的变化，然后构造抽象来隔离这些变化。

最后 不要刻意地进行抽象，拒绝不成熟的抽象也是很重要的。

四. 依赖倒转原则

案例：

比如，我们做的项目大多要访问数据库，所以我们就把访问数据库的代码写成了函数，每次做新项目时就去调用这些函数。这就叫做高层模块依赖低层模块。

问题：

当客户希望使用不同的数据库时，就会出现麻烦。因为当我们希望再次利用这些高层模块，但高层模块都与低层的访问数据库绑定在一起的，也就没有办法复用这些高层模块了。

总结：

如果不管高层模块还是低层模块，它们都依赖于抽象，具体一点就是接口或抽象类，只要接口是稳定的，那么任何一个的更改都不用担心其它受到影响，这就使得无论高层模块还是低层模块都可以很容易地被复用。

定义：

A：高层模块不应该依赖底层模块,两个者应该依赖抽象。

B：抽象不应该依赖细节，细节应该依赖抽象。[DH]

解释：

也就是说， 要针对接口或抽象进行编程，不要对实现编程。
通俗的说就是，谁也不要依靠谁，除了约定的接口或抽象类。只有抽象的东西才是最稳定的，也就是说，我们依赖的是它的稳定。如果将来“抽象”也不稳定了，那么谁稳定我跟谁！

五. 最后总结一下：

1. "开放－封闭"原则是设计模式的核心目标。

2. 依赖倒转原则是到达"开放－封闭"原则的手段。

3. 里氏代换原则使得"开放－封闭"成为了可能。