设计模式六大原则

如果说编码是筋骨皮，那么思想就是一口气，就是内功。内功深厚决定你功力的大小。刚刚读完了设计模式那本书。随着项目业务的复杂，越发的感觉到设计模式的重要性。在此参考CSDN、伯乐在线和开源中国社区，优秀的博文，以此总结。开始新的起点。

一、开闭原则

定义

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

问题由来

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

解决方案

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

表达

用抽象构建框架，用实现扩展细节。因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。当然前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性才行。

二、单一职责原则

定义

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

问题由来

类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。

解决方案

遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

表达

不要让责任扩散

三、里氏替换原则

定义

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

问题由来

有一功能P由类A完成，现在要扩展P,其中P由类A的子类B完成，则子类在完成的同时，可能会导致原来功能故障

解决方案

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

表达

使用继承的时候，不要随便修改父类中已经实现的方法

四、依赖倒置原则

定义

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

问题由来

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

解决方案

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

表达

如果A依赖B，现在要改为依赖C，如果直接修改A有风险，可以让A去依赖一个接口，BC都实现这个接口，也就是策略模式

五、接口隔离原则

定义

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

问题由来

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

解决方案

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

表达

防止去实现不需要的接口方法，可以按接口拆分，避免臃肿。

六、迪米特法则

定义

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

问题由来

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

解决方案

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

表达

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