面向对象六大原则

1. 单一职责原则（SRP）

单一职责原则的核心思想是：系统中的每一个对象都应该只有一个单独的职责，而对象所关注的就是自身职责的完成。也就是说，每一个类应该只有一个职责，对外只提供一种功能，而引起类变化的原因也应该只有一个， 单一职责也就是单一变化的原因 。

通常，一个类的职责越多，导致其变化的因素也就越多，因为每个职责都可能是一个变化的轴线。

一般情况下，我们在设计一个类的时候会把与该类相关的操作都组合到这个类中，这样做的后果就有可能将多个职责“耦合”到一块，当这个类的某个职责发生变化时，很难避免类的其他部分不受影响，这就导致了程序的“脆弱”和“僵硬”。

其实我们所写的类是现实概念模型的抽象没有错，也很符合现实的概念模型。但是我们所写的类往往缺乏抽象层次，低层次与高层次概念混杂，这正是问题的所在。

类只有一个变化的原因 >> 一个变化只影响一个类 >> 变化只影响其相应层 次的类

优点：A.消除耦合，避免程序的"脆弱"和"僵化"

    B.提高类的可读性，提高系统的可维护性。

注意：只有实际情况中职责确实发生变化的时候，该原则才有意义，如果一个类组合了多个职责，但实际中这些职责根本没有发生改变时，那就没有必要费劲心机去应用该原则。

比如将用户的属性和行为分开，定义为两个接口，这样当修改用户属性时，就只需要对用户属性的接口进行修改，而不会影响其他类。

2.里氏替换原则(LSP)

里氏替换原则的核心思想是：在任何父类出现的地方都可以用它的子类代替

通俗的定义：子类可以扩展父类的功能，但不能改变父类原有的功能。

理解：只要父类能出现的地方，子类就可以出现，并且替换成子类也不会产生任何错误或异常，使用者可能根本不知道是父类还是子类，反之，未要求。

里氏替换原则定义所包含的四层意思:

A.子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

B.子类可以有自己的方法和属性。

C.覆盖或者实现父类的方法时输入的参数可以被放大( 放大的实质为重载，因为参数不同；为什么只能放大？因为父类方法的参数类型相对较小，所以当传入父类方法的参数类型（或更窄类型）时，重载时，将优先匹配父类的方法，因此子类重载的方法并不会对此参数类型被执行，因此保证了LSP，且不会引起想不到的业务逻辑混乱)

D .当子类实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格

原因还是里氏替换原则：在任何父类出现的地方都可以用它的子类代替

父类返回HashMap类型，你返回Map类型，你告诉我你怎么替换它？我返回TreeMap也可以啊

里氏替换原则的关键点在于不能覆盖父类的非抽象方法，父类中凡是已近实现的方法，实际是已经设定一系列的规范和契约，虽然它不强制所有的子类必须遵从这些规则，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。而里氏替换原则就是表达一层的含义。它关注的是怎样良好的使用继承。

3.依赖注入原则（DIP）

依赖注入原则的核心思想：要依赖于抽象，不要依赖于具体的实现

通俗的理解：在应用程序中，所有的类如果使用或依赖于其他的类，则都应该依赖于这些其他类的抽象类，而不是这些其他类的具体实现类。抽象层次应该不依赖于具体的实现细节，这样才能保证系统的可复用性和可维护性。为了实现这一原则，就要求开发人员在编程时针对接口编程，而不是针对实现编程。

依赖注入原则说明：

A.高层模块不应该依赖低层模块，两者都应该依赖于抽象。

B.抽象不应该依赖于细节

C.细节（具体实现类）应该依赖抽象

依赖注入原则的本质其实就是通过抽象（抽象类或者接口）使各个类或模块的实现彼此独立，不相互影响，实现模块间的松耦合。

依赖注入原则用如下三种方式实现

(1)通过构造函数传递依赖对象

(2)通过setter方法传递依赖对象

(3)接口声明实现依赖对象

4.接口分离原则（ISP）

接口分离原则的核心思想就是:不应该强迫客户程序依赖它们不需要使用的方法，一个类对接口的 依赖应该建立在最小接口上。

通俗的说：一个接口不需要提供太多的行为，一个接口应该只提供一种对外的功能，不应该把所有的操作都封装到一个接口中。否则一个类就要实现很多接口中的实际自己不需要的功能（方法）

 接口隔离原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。在程序设计中，依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。

         说到这里，很多人会觉的接口隔离原则跟之前的单一职责原则很相似，其实不然。其一，单一职责原则原注重的是职责；而接口隔离原则注重对接口依赖的隔离。其二，单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口，主要针对抽象，针对程序整体框架的构建。

         采用接口隔离原则对接口进行约束时，要注意以下几点：

• 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不争的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
• 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
• 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

运用接口隔离原则，一定要适度，接口设计的过大或过小都不好。设计接口的时候，只有多花些时间去思考和筹划，才能准确地实践这一原则。

5.迪米特原则 (LOD)

迪米特原则的核心思想是：一个对象应当对其他对象尽可能少的了解。意思就是降低各个对象之间的耦合，在模块之间，应该只通过接口来通信，而不理会模块内部的工作原理，使各个模块之间的耦合降到最低。

迪米特法则的  初衷 在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

迪米特法则不希望类之间建立直接的联系。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。

在应用迪米特法则的时候应该注意以下：

（1）在类的划分上，应该创建有弱耦合的类

（2）在类的设计上，每个类都应当尽量降低成员的访问权限

（3）在对其他类的引用上，一个对象对其他对象的引用应该降到最低

（4）尽可能降低类的访问权限

（5）谨慎使用序列化功能

（6）优先考虑一个类设计为不变类

6.开闭原则（OCP）

开闭原则的核心思想是：对修改关闭，对扩展开放