常见的面向对象设计原则

一、单一职责原则SRP（Single Responsibility Principle）

        每一个类应该专注于做一件事情。

二、开发-关闭原则OCP（Open-Closed Principle）

       面对扩展开放，面对修改关闭。

三、里氏替换原则LSP（Liskov Substitution Principle）

       超类出现的地方，子类一定可以出现。

四、依赖倒置原则DIP（Dependence Inversion Principle）

       依赖倒置原则即要依赖于对象，不要依赖于具体类

五、接口隔离原则ISP（Interface Segregation Principle）

       使用多个专门的接口代替一个统一的接口。

六、最少知识原则LKP（Least Knowledge Principle）

       最少知识原则即迪米特法则，一个软件实体应当尽可能少的与其他实体发生相互作用。

七、其他原则

       除了以上原则，还有一些大家熟知的原则：
<1>面向接口编程。
<2>优先使用组合或聚合，而非继承。
<3>一个类需要的数据应该隐藏在类的内部。
<4>类之间应该零耦合或者只有传到耦合。
<5>在水平方向上尽可能统一地分布系统功能。

详解：

单一职责原则
        单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。
       1. 可以降低类的复杂度，一个类或模块只负责一项职责；
       2. 可以增加类的可读性，提高系统的可维护性；
       注：这个原则很难实现，实际开发中职责的粒度大小、职责细化没有统一标准，所以实际开发中最容易违反。

开发-关闭原则
        所谓开闭原则，即一个类或模块应该对扩展开放，对修改关闭。开闭原则主要体现在对扩展开放，对修改关闭，意味着有新需求或需求变化时，可以在不修改的情况下进行扩展。

里氏替换原则
       里氏替换原则即在软件中基类可以出现的地方，子类一定可以出现，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。

注：子类的所有方法必须在父类中声明，或子类必须实现父类中声明的所有方法。尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法，运行时，子类实例替换父类实例，我们可以很方便地扩展系统的功能，同时无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。

依赖倒置原则
       依赖倒转原则即要依赖于抽象，不要依赖于具体。
        - 高层模块不应该依赖于底层模块，二者都应该依赖于抽象。
        - 抽象不应该依赖于具体，具体实现应该依赖于抽象。

依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，减少并行开发引起的风险，提高代码的可读性和可维护性。

接口隔离原则
       客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
       使用多个专门的接口比使用单一的总接口要好。
       一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。
       “不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。

最少知识原则
       最少知道原则（Least Knowledge Principle 简写LKP）又叫作迪米特法则（Law of Demeter），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。英文简写为: LoD.

-如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。