设计模式——六大原则

       经过一段时间的设计模式的学习，下面来看看设计模式中的六大原则吧。

设计模式六大原则（1）：单一职责原则：

定义：

       不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。

原理：

       如果一个类承担的职责过多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或者一直这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。而如果想要避免这种现象的发生，就要尽可能的遵守单一职责原则。此原则的核心就是解耦和增强内聚性。

问题由来：

        之所以会出现单一职责原则就是因为在软件设计时会出现以下类似场景：

        T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。也就是说职责P1和P2被耦合在了一起。

产生原因：

        没有任何的程序设计人员不清楚应该写出高内聚低耦合的程序，但是很多耦合常常发生在不经意之间，其原因就是：

        职责扩散：因为某种原因，某一职责被分化为颗粒度更细的多个职责了。

解决办法：

        遵守单一职责原则，将不同的职责封装到不同的类或模块中。

 

设计模式六大原则（2）：依赖倒转原则

定义：

       高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。                         

问题由来：

       类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

解决方案：

       将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

 

设计模式六大原则（3）：里氏替换原则

定义1：

       如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。

定义2：

       所有引用基类的地方必须能透明地使用其子类的对象。

问题由来：

       有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。

解决方案：

        当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。

 

设计模式六大原则（4）：迪米特法则

定义：

       一个对象应该对其他对象保持最少的了解。

问题由来：

        类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

解决方案：

        尽量降低类与类之间的耦合。

 

设计模式六大原则（5）：接口隔离原则

定义：

       客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。                           
问题由来：

       类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。

解决方案：

       将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。

 

设计模式六大原则（6）：开放—封闭原则

定义：

       一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

问题由来：

       在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。

解决方案：

        当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

 

       总得来说，设计模式的这几种原则的使用就是为了达到面向对象的根本目的：可维护，可扩展，可复用，灵活性好。达到高内聚低耦合的终态。