七大原则：

1. 单一职责原则；
2. 接口隔离原则；
3. 依赖倒转原则；
4. 里氏替换原则；
5. 开闭原则ocp；
6. 迪米特法则；
7. 合成复用原则。

设计模式其实包含了面向对象的精髓，封装、继承、多态。

一、单一职责原则

对于类来说，一个类应该只负责一项职责。

假设A负责两个不同的职责1和2，如果1的内容需要改变，影响了2，那可能2会执行错误，所以需要将A分为两个类。

1.1 示例

public class SingleResponsibility1 {
    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.run("汽车");
        vehicle.run("摩托车");
        vehicle.run("飞机");
    }
}

class Vehicle{
    public void run(String vehicle){
        System.out.println(vehicle+"在地上跑");
    }
}

对于一个完成交通工具的类Vehicle来说，显然对不同的对象、汽车和飞机，提供的服务不应该都是在地上跑，并且修改之后，肯定会影响到其中一类对象的功能，所以按照单一职责，那就应该拆开，成两个类。

1.2 改进版本 1

public class SingleResponsibility2 {
    public static void main(String[] args) {
        RoadVehicle roadVehicle = new RoadVehicle();
        roadVehicle.run("摩托车");
        roadVehicle.run("汽车");
        AirVehicle airVehicle = new AirVehicle();
        airVehicle.run("飞机");
    }
}

class RoadVehicle{
    public void run(String vehicle){
        System.out.println(vehicle+"在地上跑");
    }
}
class AirVehicle{
    public void run(String vehicle){
        System.out.println(vehicle+"在天上飞");
    }
}

但是这么写又有了新的问题：那就是类分解的时候，客户端代码也要改，调用方式改了。因此可以直接更改本来的Vehicle类，变成我们的第三种写法.

1.3 改进版本 2

public class SingleResponsibility3 {
    public static void main(String[] args) {
        Vehicle2 vehicle2 = new Vehicle2();
        vehicle2.runRoad("汽车");
        vehicle2.runWater("轮船");
        vehicle2.runAir("飞机");
    }
}

class Vehicle2{
    public void runRoad(String vehicle){
        System.out.println(vehicle+"在公路上跑");
    }
    public void runAir(String vehicle){
        System.out.println(vehicle+"在天上飞");
    }
    public void runWater(String vehicle){
        System.out.println(vehicle+"在水里游");
    }
}

这种写法，显然更加方便，相比第一种，没有更改类的声明方式，只是在类内部增加了方法的各司其职，可以看出来，虽然没有在类级别上严格遵循单一职责原则，但是在方法级别上严格遵循了单一职责原则，相比之下比方法2更合适。

1.4 总结单一职责原则

1. 降低类的复杂度，一个类只负责一项职责（上面的例子因为过于简单，所以看起来第三个写法更有效）；
2. 提高类的可读性、可维护性，降低变更带来的风险；
3. 通常情况下，我们应该遵守这个职责，只有在逻辑足够简单的时候，才可以在代码级别违反这个原则，也就是上面的，改为在方法级别保持单一职责原则。

二、接口隔离原则

接口隔离（Interface Segregation Principle）

意思是说，如果某一个类对另一个类的依赖通过的是接口，那么这个类对另一个类的依赖应该建立在最小的接口上，如果不是最小接口，则需要拆。

2.1 示例

例如如下的用例图：

image.png

A 和 B 是 Interface1 的实现类，所以必须实现它的 4 个方法，C 和 D 分别依赖于这个接口，使用 A 和 B 里面对应的方法，但不是全部，C 使用前三个方法，D 使用后三个方法，如果按照类图实现，代码会如下所示：

interface Interface1{
    void fuc1();
    void fuc2();
    void fuc3();
    void fuc4();
}

class A implements Interface1{
    public void fuc1() {System.out.println("A实现了fuc1");}
    public void fuc2() {System.out.println("A实现了fuc2");}
    public void fuc3() {System.out.println("A实现了fuc3");}
    public void fuc4() {System.out.println("A实现了fuc4");}
}

class B implements Interface1{
    public void fuc1() {System.out.println("B实现了fuc1");}
    public void fuc2() {System.out.println("B实现了fuc2");}
    public void fuc3() {System.out.println("B实现了fuc3");}
    public void fuc4() {System.out.println("B实现了fuc4");}
}
//C通过接口Interface1依赖，使用A这个实现类，但是只用A的前两个方法
class C {
    public void depend1(Interface1 i){
        i.fuc1();
    }
    public void depend2(Interface1 i){
        i.fuc2();
    }
    public void depend3(Interface1 i){
        i.fuc3();
    }
}
//D通过接口Interface1依赖，使用B这个实现类，但是只用B的后两个方法
class D {
    public void depend2(Interface1 i){
        i.fuc2();
    }
    public void depend3(Interface1 i){
        i.fuc3();
    }
    public void depend4(Interface1 i){
        i.fuc4();
    }
}

显然，A 和 B 两个实现类都做了多余的工作，也就是 C 和 D 依赖的这个接口有些方法是他们不需要的，这个接口写的不好。

2.2 改进

根据接口隔离原则，我们应该将其拆成满足最小接口的类型，也就是说多余的我们全都不应要，所以接口 Interface1 应该拆分为三个接口，接口 1 里面有方法 1 ，接口 2 里面有方法 23，接口 3 里面有方法 4，这样实现的时候A和B两个类就更加清晰，修改后的类图如下：

image

3|0三、依赖倒转原则

interface Interface11{
    void fuc1();
}
interface Interface12{
    void fuc2();
    void fuc3();
}
interface Interface13{
    void fuc4();
}
class A1 implements Interface11,Interface12{
    public void fuc1() {System.out.println("A实现了接口1的fuc1");}
    public void fuc2() {System.out.println("A实现了接口2的fuc2");}
    public void fuc3() {System.out.println("A实现了接口2的fuc3");}
}
class B1 implements Interface12,Interface13{
    public void fuc2() {System.out.println("B实现了接口2的fuc2");}
    public void fuc3() {System.out.println("B实现了接口2的fuc3");}
    public void fuc4() {System.out.println("B实现了接口3的fuc4");}
}
class C1{
    public void depend1(Interface11 i){
        i.fuc1();
    }
    public void depend2(Interface12 i){
        i.fuc2();
    }
    public void depend3(Interface12 i){
        i.fuc3();
    }
}
class D1{
    public void depend2(Interface12 i){
        i.fuc2();
    }
    public void depend3(Interface12 i){
        i.fuc3();
    }
    public void depend4(Interface13 i){
        i.fuc4();
    }
}

这种写法就是遵循了接口隔离原则

客户端使用的时候：

    C1 c = new C1();
    c.depend1(new A1());//C类通过接口依赖（使用）的是A类
    c.depend2(new A1());
    c.depend3(new A1());
    D1 d = new D1();
    d.depend2(new B1());//D类通过接口依赖（使用）的是B类
    d.depend3(new B1());
    d.depend4(new B1());

三、依赖倒转原则

依赖倒转原则 ( Dependence Inversion Principle ) 指的是：

1. 高层模块不应该依赖低层模块，二者都应该依赖其抽象；
2. 抽象不应该依赖细节，细节应该依赖抽象；
3. 依赖倒转的核心思想是面向接口编程。

为什么要有依赖倒转原则：主要是因为，相对于细节的多变，抽象的东西要稳定的多，以抽象为基础搭建的架构比以细节为基础的架构稳定的多，在java种，抽象指的就是接口或者抽象类，细节就是具体的实现类，抽象类制定好规范，展现细节的任务交给实现类去做。

依赖倒转原则需要注意：

1. 底层模块尽量都要有抽象类或接口，或者两者都有，程序的稳定性会更好；
2. 变量的声明类型尽量是抽象类或接口，这样我们的变量引用和实际对象之间，就存在一个缓冲层，利于程序扩展和优化；
3. 继承时遵循里氏替换原则。

例如：有一个功能，一个Person类，要有一个接收消息的功能。

3.1 示例

public class DependencyInversion1 {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());
    }
}
class Email{
    public String getInfo(){
        return "电子邮件信息";
    }
}
class Person{
    public void receive(Email email){
        System.out.println(email.getInfo());
    }
}

因为Person类需要的接受是一个功能，消息应该是另一个类，所以还有一个Email类。那么这种写法，显然直接犯在Person类里依赖了Email类，也就是上面所说的”高层模块依赖底层模块“。

那么这么写可能会带来哪些问题呢？

对于Person类，接受的这个动作可以扩展，如果要接受的不仅仅是Email，是很多短信、微信等信息，那么在新增短信、微信类的同时，Person类里要新增对应的方法，改动基本是所有的都改动。

按照依赖倒转原则，对于Email、短信这些不同的类，应该将他们抽象出一个接口，然后他们实现接口，这样的话，对于Person类，他的接受方法，就是对这个抽象接口的依赖，而不是直接依赖这些不同的实现类。

3.2 改进

public class Dependency1 {
    public static void main(String[] args) {
        Person1 person1 = new Person1();
        person1.receive(new Email1());
    }
}
interface IReceiver{
    public String getInfo();
}
class Email1 implements IReceiver{
    public String getInfo() {
        return "电子邮件信息:";
    }
}
class Person1{
    public void receive(IReceiver receiver){
        System.out.println(receiver.getInfo());
    }
}

在客户端的调用方式也是几乎一样的，运行结果是一样的，同时，因为Person依赖的是抽象的接口而不是具体的Email。

当我们想要增加一个接受的类的时候，平行增加，同时都去实现接口里面的方法就可以，Person类不用做改变，那么调用的时候传入参数去变成具体的实现类就可以。

//扩展
class Wechat implements IReceiver{
    public String getInfo() {
        return "微信消息：";
    }
}

那么main方法的客户端只需要：

person1.receive(new Wechat());

就可以。

3.3 扩展：依赖关系传递的三种方式

依赖关系的传递一般有三种方式：

1. 接口传递；
2. 构造方法传递；
3. setter方法传递。

第一种：

//方式1：通过接口传递依赖
interface IOpenandClose{
    public void open(ITV itv);
}
interface ITV{
    public void play();
}
class OpenandClose implements IOpenandClose{
    public void open(ITV itv) {
        itv.play();
    }
}

可以看到，因为第一个接口依赖于第二个接口，那么实现第一个接口的时候，就需要实现对应的方法，把接口作为参数，实现了依赖的传递。

第二种：

//方式2，通过构造方法传递依赖
interface IOpenandClose2{
    public void open();
}
interface ITV2{
    public void play();
}
class OpenandClose2 implements IOpenandClose2{
    public ITV2 itv2;
    public OpenandClose2(ITV2 itv2){
        this.itv2 = itv2;
    }
    public void open() {
        this.itv2.play();
    }
}

通第一个接口和第二个接口虽然没有直接写明依赖，但是依赖体现在实现类里，实现类里通过构造方法传入一个参数，才能进行open方法的实现，所以在构造方法的部分体现了依赖关系。

第三种：

//方式3，通过set方法传递依赖
interface IOpenandClose3{
    public void open();
    public void setTV(ITV3 itv3);
}
interface ITV3{
    public void play();
}
class OpenandClose3 implements IOpenandClose3{
    private ITV3 itv3;
    public void setTV(ITV3 itv3) {
        this.itv3 = itv3;
    }
    public void open() {
        this.itv3.play();
    }
}

其实和第一种类似，不过没有在open的地方直接依赖，而是分成两个步骤，先给声明的ITV初始化，再进行使用，这样依赖也就传递成功了。

使用三种示例的方法，我们都用到一个ITV的实现类，实现一个play方法，然后调用开关这个类，体现开关接口的依赖性。比如第一种是

class Sumsang implements ITV{
    public void play() {
        System.out.println("三星电视开机啦");
    }
}

然后在主方法里调用就是：

OpenandClose close = new OpenandClose();
close.open(new Sumsang());

因为使用开关机的时候，这个方法就是通过接口参数才能调用，所以这是第一种接口传递。

第二种就只用：

OpenandClose2 close2 = new OpenandClose2(new Sony());
close2.open();

虽然open没有参数，但是依赖是通过构造方法传递的。

第三种情况：

OpenandClose3 close3 = new OpenandClose3();
close3.setTV(new Xiaomi());//如果不先set，就会报空指针close3.open();

四、里氏替换原则

面向对象中继承的问题：

1. 父类实现好的方法，实际上设定了规范，虽然不强制要求子类都要遵守，到那时如果子类对这些方法进行了修改，会对整个继承体系造成破坏；
2. 如果使用继承会给程序带来入侵性，使得移植性降低，增加对象之间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，会影响所有子类；
3. 那么，如何在编程中正确使用继承呢？=> 里氏替换原则

里氏替换：

1. 里氏替换原则：如果每个类型 T1 的对象 o1 ，都有类型 T2 的对象 o2，使得以 T1 定义的所有程序 P 在所有的对象 o1 都换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型，也就是说，引用基类（父类）的地方必须能透明的使用其子类（派生类）的对象。
2. 使用继承的时候，遵循里氏替换原则，也就是尽量不要重写父类的方法；
3. 这个原则告诉我们，继承让两个类的耦合性增强了，适当情况下，可以通过聚合、组合、依赖来解决问题。

如何理解这个原则呢，假如一个父类是 A，B extends A，结果把 A 类的所有方法都重写了，那肯定A类的对象所有行为都变化了，另一方面，B 还要继承 A 类纯属有病。适当的，A 和 B 更适合于，继承同一个更加基础的类 C，重新整理，这样解决这个问题会比较合适。

4.1 示例

例如：

class A{
    public int func1(int a, int b){
        return a - b;
    }
}
class B extends A{
    public int func1(int a, int b){
        return a + b;
    }
    public int func2(int a, int b){
        return func1(a, b)+9;
    }
}

不管是无意还是有意，B 继承 A 的时候把 func1 重写了。

显然，这样 B 以为被正常调用的时候，求a-b的 func1 ，却输出了和调用 a 的 func 1不一样的结果。（可能例子不是很恰当，但是如果更复杂的情况下，调用一个子类的某一个方法，方法名是一样的，肯定会认为功能是一样的）

实际开发过程中，就是因为一些重写父类方法来完成新功能的操作，让整个继承体系的复用性变差，特别是用到多态比较多的时候。

通用的做法就是：原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合、组合等关系来替代。

4.2 改进

//更加基础的类
class Base{

}
class A1 extends Base{
    public int func1(int a, int b){
        return a - b;
    }
}
class B1 extends Base{
    public int func1(int a, int b){
        return a + b;
    }
    public int func2(int a, int b){
        return func1(a, b)+9;
    }
    //如果b要使用到A的方法，使用组合的关系
    private A1 a1 = new A1();
    //仍然使用A的方法
    public int func3(int a, int b){
        return this.a1.func1(a, b);
    }
}

那么，这样的话A和B已经没有耦合的依赖关系了，那么调用的时候，想要减法的方法就可以调用fuc3，使用加法可以调用fuc1，此时不会和A的fuc1打架或者覆盖。

五、开闭原则ocp

开闭原则（Open Closed Principle）是编程中最基础、最重要的设计原则。

1. 一个软件实体、如类，模块和函数应该对扩展开放（对提供方），对修改关闭（对使用方）。用抽象构建框架，用实现扩展细节；
2. 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过已有代码实现变化；
3. 编程中遵循其他原则的目的就是遵循开闭原则。

5.1 示例

//绘图类，根据接受的shape不同来绘制图形，【使用方】
class GraphicEidtor{
    public void drawShape(Shape s){
        if(s.type == 1) drawRec(s);
        if (s.type == 2) drawCir(s);
    }
    public void drawRec(Shape r){
        System.out.println("矩形");
    }
    public void drawCir(Shape c){
        System.out.println("圆形");
    }
}
//基类
class Shape{
    int type;
}
//【提供方】
class Rectangle extends Shape{
    Rectangle(){
        super.type = 1;
    }
}
class Circle extends Shape{
    Circle(){
        super.type = 2;
    }
}

调用的时候，给draw方法传入不同的参数，会根据类型画出不同的图形，我们调用一下：

GraphicEidtor graphicEidtor = new GraphicEidtor();
graphicEidtor.drawShape(new Rectangle());
graphicEidtor.drawShape(new Circle());

这种写法还是比较好理解的，但是这种写法很不好。

那么，这种写法的问题在哪里呢？

违反了设计模式的 OCP 开闭原则，也就是不满足对扩展开放，对修改关闭。这个原则希望当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码。

比如我们想加一个图形种类，那就要将这个图形多写一个类作为【提供方】，在画图类【使用方】里增加一个对应shape类型的调用，再增加一个方法。这就是违背原则了。

5.2 改进

思路就是：创建shape作为抽象类，提供一个抽线的draw方法，那么子类实现的时候去实现draw方法，这样的话，【使用方】就不用修改代码，满足了开闭原则。

（其实说白了就是面向对象的意思，这个对象自己本身需要向外提供方法，而不是让使用方去提供方法，同时，前面四个原则里也多多多少少有用到这个思路，就是让使用方不要改动）

class GraphicEidtor1{
    public void drawShape(Shape1 s){
        s.draw();
    }
}
abstract class Shape1{
    int type;
    public abstract void draw();
}
class Rectangle1 extends Shape1{
    Rectangle1(){
        super.type = 1;
    }
    public void draw(){
        System.out.println("矩形");
    }
}
class Circle1 extends Shape1{
    Circle1(){
        super.type = 2;
    }
    public void draw(){
        System.out.println("圆形");
    }
}

这样的话，调用的写法是没有任何改变的。

但是呢，如果我们要加一个新的形状，那么就让他自己去实现方法就可以了，对于【使用方】GraphicEidtor 是修改关闭的。

六、迪米特法则

Demeter Principle 迪米特法则，又叫最少知道原则：

即一个类对自己依赖的类知道的越少越好，也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装再类的内部。对外提供public方法，不对外泄露任何信息。

迪米特法则还有个更简单的定义：只与直接的朋友通信。

什么是直接朋友？每个对象都会和其他对象之间有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系，耦合的方式有很多，依赖、关联、组合、聚合等。
其中我们称出现在成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中 的类不是直接的朋友，也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。

比如A类里面直接有用到一个B b，或者某个方法有参数fuc1(B b)；或者返回值类型是B，那么这叫做B以直接朋友的形式出现在了A里面。

比如A类里面有个方法 fuc1，fuc1用到一个 B b = new B()；这样的局部变量形式让A里面出现了B，这就是陌生的类，而不是直接朋友。

6.1 示例

比如一个应用实例：

有一个学校，下属各个学院和总部，现在要求打印出学校总部的员工ID和学院员工的ID。
代码略长，但是逻辑很简单：

public class Demeter1 {
    public static void main(String[] args) {
        CollegeManager collegeManager = new CollegeManager();
        collegeManager.printAllEmp(new SchoolManager());
    }
}
//学校总员工
class Employee{
    private String id;
    public void setId(String id){
        this.id = id;
    }
    public String getId(){
        return id;
    }
}
//学院员工
class SchoolEmployee{
    private String id;
    public String getId() {
        return id;
    }
    public void setId(String id) {
        this.id = id;
    }
}
//管理学院员工
class SchoolManager{
    //添加学院员工
    public List<SchoolEmployee> getAllEmployee(){
        List<SchoolEmployee> list = new ArrayList<>();
        for( int i=0; i<10; i++){
            SchoolEmployee employee = new SchoolEmployee();
            employee.setId("学院员工:"+i);
            list.add(employee);
        }
        return list;
    }
}
//学校管理类
//直接朋友类有：Employee、SchoolManager，第一个作为添加方法返回值，第二个作为输出方法的参数
//陌生类：SchoolEmployee，违背了迪米特法则
class CollegeManager{
    //添加学校员工，返回值参数Employee：直接朋友
    public List<Employee> getAllEmployee(){
        List<Employee> list = new ArrayList<>();
        for(int i=0; i<5; i++){
            Employee employee = new Employee();
            employee.setId("学校总部员工："+i);
            list.add(employee);
        }
        return list;
    }
    //输出所有员工信息
    //参数SchoolManager：直接朋友
    public void printAllEmp(SchoolManager sub){
        //SchoolEmployee：陌生朋友，局部变量的方式
        List<SchoolEmployee> list1 = sub.getAllEmployee();
        System.out.println("-----学院员工-----");
        for(SchoolEmployee e: list1){
            System.out.println(e.getId());
        }
        List<Employee> list2 = this.getAllEmployee();
        System.out.println("-----学校员工-----");
        for(Employee e: list2){
            System.out.println(e.getId());
        }
    }
}

这里面的问题，关于直接朋友和非直接朋友已经标注。

按照迪米特法则，上面出现了 SchoolEmployee 是陌生朋友，出现在了 SchoolManager 类里。这是非直接朋友关系的耦合，根据迪米特法则是应该避免的。

6.2 改进

其实例子写的有点故意，显然出问题的那一段，学校的输出信息部分，要输出学院的信息，没必要，解决起来把输出学院员工信息的那段，放到学院员工自己的类里面就可以了。也就是遵守了前面说的 " 尽量将逻辑封装在类的内部 "。

那么就可以把 SchoolManager 部分输出学院信息部分改成：

//学院员工
sub.printEmployee();

然后对应的输出方法，写去CollegeManager类里面，添加一个方法：

//输出学院所有员工的信息
public void printEmployee(){
    List<SchoolEmployee> list1 = this.getAllEmployee();//不用this也行
    System.out.println("-----学院员工-----");
    for(SchoolEmployee e: list1){
        System.out.println(e.getId());
    }
}

这样的话，逻辑在自己类内部，提供一个public方法供外部使用。

注意：每个类之间多多少少都会有耦合，迪米特法则只是要求降低耦合关系，而不是要求完全没有依赖关系。完全没有，就相当于每个对象干个啥都在自己类里写完，也用不着直接朋友了。

七、合成复用原则

合成复用原则：尽量使用组合/聚合的方式，而不要使用继承。

例如： A 类和 B 类，B 类想要使用 A 类的两个方法，第一个想到的是继承，但是这种做法耦合性很高，如果说仅仅是想要使用这两个方法，而没有别的根本上需要用到继承的必要性，那么可能会带来很多麻烦，比如还有别的类也继承了 A ，有必要修改 A 的时候还要考虑 B 会不会收影响。

所以尽量使用的做法就是聚合或者合成：

7.1 聚合

将 A 作为一个私有变量加入到 B 里面，在 B 里面写一个 set 方法将 A 实例化，然后去调用想要的方法，这就叫做聚合。类似于我们在前面第三个原则”依赖倒转原则“最后写的传递依赖的方式的setter方法。

7.2 组合

将 A 直接实例化在 B 里面，那么 B 创建的时候，A 就已经有了一个实例化的对象，然后调用方法，和前面的里氏替换法则后面的做法是一样的。

八、总结

其实上面的七个原则很多地方的解决方案和冲突都是有重复的部分，实际上我们总结一下核心思想就是：

1. 尽量把需要变化的部分独立出来，不要和不变的代码写在一起；
2. 如果对别的部分影响大，尽量写成接口；
3. 为了松耦合努力。（可以说七个原则这个理论本身就是非常松耦合……）