JAVA 设计模式遵循的六大基本准则

一、单一职责原则：（Single Responsibility Pinciple）

　　一个类只负责一项职责。当超过一项职责需要负责时，需要增加新的类来负责新的职责，而不是在类中个性代码。

　　如果一个类承担的职责太多，就是高度地职责耦合，非常不利于扩展功能。这是非常脆弱的设计。容易发生修改一个地方而影响其他地方的情况。

遵循单一职责原则的优点：

降低类的复杂度
提高类的可读性，提高系统的可维护性
变更引起的风险降低

二、里氏代换原则：（Liskov Substitution Principle,简称LSP）子类可以扩展父类的功能，但不能改变父类原有的功能

里氏代换原则(Liskov Substitution Principle, LSP)：所有引用基类（父类）的地方必须能透明地使用其子类的对象。

里氏代换原则告诉我们，在一个软件系统中，子类应该可以替换任何基类能够出现的地方，并且经过替换以后，代码还能正常工作。子类也能够在基类的基础上增加新的行为。

例如有两个类，一个类为BaseClass，另一个是SubClass类，并且SubClass类是BaseClass类的子类，那么一个方法如果可以接受一个BaseClass类型的基类对象base的话，如：method1(base)，那么它必然可以接受一个BaseClass类型的子类对象sub，method1(sub)能够正常运行。反过来的代换不成立，如一个方法method2接受BaseClass类型的子类对象sub为参数：method2(sub)，那么一般而言不可以有method2(base)，除非是重载方法。

里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

包含4层含义：

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
子类中可以增加自己特有的方法。
当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

不遵循里氏代换原则的后果是，写代码出错的机率会大大增加。

三、依赖倒置原则（Dependence Inversion Principle,简称DIP）

　　定义：1.高层模块不应该依赖低层模块，二者都应该依赖其抽象； 2.抽象不应该依赖细节；细节应该依赖抽象。

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

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

依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

　　传递依赖的三种写法：

1.构造函数传递依赖对象
2.Setter方法传递依赖对象
3.接口声明传递依赖对象

深入了解可以看：轻松学，浅析依赖倒置（DIP）、控制反转(IOC)和依赖注入(DI)

四、接口隔离原则（Interface Segregation Principle,简称ISP）

核心思想：类间的依赖关系应该建立在最小的接口上
通俗来讲：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

　举例

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

　　举例来说明接口隔离原则：

（图1 未遵循接口隔离原则的设计）

这个图的意思是：类A依赖接口I中的方法1、方法2、方法3，类B是对类A依赖的实现。类C依赖接口I中的方法1、方法4、方法5，类D是对类C依赖的实现。对于类B和类D来说，虽然他们都存在着用不到的方法（也就是图中红色字体标记的方法），但由于实现了接口I，所以也必须要实现这些用不到的方法。

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

　　可以看到，如果接口过于臃肿，只要接口中出现的方法，不管对依赖于它的类有没有用处，实现类中都必须去实现这些方法，这显然不是好的设计。如果将这个设计修改为符合接口隔离原则，就必须对接口I进行拆分。在这里我们将原有的接口I拆分为三个接口，拆分后的设计如图2所示：

（图2 遵循接口隔离原则的设计）

需注意：
接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度
提高内聚，低耦合=减少对外交互。每个模块尽可能独立完成自己的功能，不依赖于模块外部的代码。内聚和耦合是密切相关的，同其他模块存在高耦合的模块意味着低内聚，而高内聚的模块意味着该模块同其他模块之间是低耦合。在进行软件设计时，应力争做到高内聚，低耦合。
为依赖接口的类定制服务。只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。

五、迪米特法则（Law of Demeter,简称LoD）

　　迪米特法则有很多种说法，比如：一个类应该应该对其他类尽可能了解得最少；类只与直接的朋友通信等等。但是其最终目的只有一个，就是让类间解耦。

　　定义

　　　　迪米特法则：Law Of Demeter，LoD。
　　　　也被称为最少知识原则，Least Knowledge Principle，LKP。

　　就是说一个对象应该对其他对象保持最少的了解。正如最少知识原则这个定义一样，一个类应该对其耦合的其他类或所调用的类知道得最少。所耦合的类内部无论如何复杂，怎么实现的我都不需要知道，我只调用你public出来的这些方法，其他都不用知道。

　　参考文档-迪米特法则

六、开放封闭原则（Open Close Principle,简称OCP）

　　所谓开放封闭原则就是软件实体应该对扩展开放，而对修改封闭（不需要修改接口，就能实现新的需求）。开放封闭原则是所有面向对象原则的核心。软件设计本身所追求的目标就是封装变化，降低耦合，而开放封闭原则正是对这一目标的最直接体现。

　　开放封闭原则主要体现在两个方面：

对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展（根据接口添加新的实现类），以适应新的情况。
对修改封闭，意味着类一旦设计完成，就可以独立其工作，而不要对类尽任何修改也能满足新的需求。

　　为什么要用到开放封闭原则呢？

　　　　软件需求总是变化的，世界上没有一个软件的是不变的，因此对软件设计人员来说，必须在不需要对原有系统进行修改的情况下，实现灵活的系统扩展。

　　如何做到对扩展开放，对修改封闭呢？

实现开放封闭的核心思想就是对抽象编程，而不对具体编程，因为抽象相对稳定。让类依赖于固定的抽象，所以对(抽象类)修改就是封闭的；而通过面向对象的继承和多态机制，可以实现对抽象体的继承，通过覆盖其方法来改变固有行为，实现新的扩展方法，所以对于扩展就是开放的（即对接口添加新的实现类来满足新的需求）。

对于违反这一原则的类，必须通过重构来进行改善。常用于实现的设计模式主要有Template Method模式和Strategy 模式。而封装变化，是实现这一原则的重要手段，将经常变化的状态封装为一个类。

代码参考例子：以银行业务员为例

总结：

单一职责原则告诉我们实现类要职责单一；
里氏替换原则告诉我们不要破坏继承体系；
依赖倒置原则告诉我们要面向接口编程；
接口隔离原则告诉我们在设计接口的时候要精简单一；
迪米特法则告诉我们要降低耦合。而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。