软件设计七大原则

声明：本篇文章除部分引用外，均为原创内容，如有雷同纯属巧合，引用转载请附上原文链接与声明。
注:本文若包含部分下载内容，本着一站式阅读的想法，本站提供其对应软件的直接下载方式，但是由于带宽原因下载缓慢是必然的，建议读者去相关官网进行下载，若某些软件禁止三方传播，请在主页上通过联系作者的方式将相关项目进行取消。

文章大纲

• 开闭原则
• 依赖倒置原则
• 单一职责原则
• 接口隔离原则
• 迪米特法则(最少知道原则)
• 里氏替换原则
• 合成/复用原则(不做介绍)

一.开闭原则

定义:一个软件实体如类，模块，函数应该对扩展开放，对修改关闭。
重点:框架设计构建在抽象上，用实现去扩展细节，该原则是大部分设计模式的基础原则。
优点:提升软件系统的可复用性和可维护性。

二.依赖倒置原则

定义:高层模块不应该依赖于底层模块，二者都应该依赖于抽象。
重点:抽象不依赖于细节，细节依赖于抽象。
优点:可以减少类之间的耦合性，提高系统的稳定性， 提高代码的可维护性和易读性，降低修改程序所造成的风险。
体现:针对接口编程，而不是面向实现编程(面向接口编程)。

三.单一职责原则

定义:不要存在多于一个导致类变更的原因。
重点:一个类/一个模块/一个方法只负责一项职责(可以理解为一种业务)。
优点:降低类的复杂度，提高类的可读性，提高可维护性，降低变更所引起的风险。

四.接口隔离原则

定义:用多个专门的接口，而不使用单一的汇总接口，使调用方(客户端)不依赖于不需要的接口
重点:
1. 一个类需要实现功能时，应该建立在粒度最小的接口上
2. 建立单一的接口，而不是建立庞大臃肿的接口，使同一种业务功能定义在同一个接口中
3. 尽量细化接口，使接口中的方法尽量少(看实际情况而定，一般情况下分解接口的粒度到所负责业务模块即可)
优点:是高内聚低耦合的设计原则，提高模块的可读性，可扩展和可维护性。

五.迪米特法则(最少知道原则)

定义:一个对象(模块)其他对象(模块)保持最少的了解(最小依赖)。
重点:尽量降低对象与对象间，模块与模块间的耦合性。
优点:降低耦合性。
体现:在类设计中，成员变量/方法/尽量private,不要公开太多的public方法以及public变量。

六.里氏替换原则

定义:任何基类可以出现的地方，子类一定可以出现。
重点:只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
体现:继承必须确保超类所拥有的性质在子类中仍然成立。也就是说，当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系,即满足里氏替换原则。
优点:主张使用抽象(Abstraction)和多态(Polymorphism)将设计中的静态结构改为动态结构，维持设计的封闭性。