设计模式7大原则详解

本文结合demo，总结下设计模式的几个原则，掌握设计模式的原则，才能真正理解各种设计模式存在的真正意义。

一、单一职责

单一职责，顾名思义，要求一个接口或者一个方法，它的功能是单一的某一类别，不能把不同功能类别的代码都放在一个接口或者一个方法中。

下面以交通工具为例，解释下单一职责原则。

1. 错误示例：

public class SingleResponsibility1 {

    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.run("摩托车");
        vehicle.run("汽车");
        vehicle.run("飞机");
    }
}
//交通工具类
class Vehicle {
	//交通工具的run方法
    public void run(String vehicle) {
        System.out.println(vehicle + "在公路上运行。。。");
    }
}

打印输出：

摩托车在公路上运行。。。
汽车在公路上运行。。。
飞机在公路上运行。。。

上述代码问题：
违反了单一职责原则，因为run()方法的职责，并不是单一的，既负责了地上跑的，又负责了天上飞的，从而也产生了问题，让飞机在地上跑了。

2. 正确示例一：
针对上述错误示例，给出正确示例：

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 + "在天上运行。。。");
    }
}

打印输出：

摩托车在公路上运行。。。
汽车在公路上运行。。。
飞机在天上运行。。。

上述示例中，我们写了两个交通工具类，分别是地上跑的和天上飞的，分别包含一个run（）方法。这样相当于把run（）方法的职责给单一化了，符合单一职责原则。

3. 正确示例二：

上述示例中，把run（）方法拆分到了两个不同的类中，一个类负责一个职责；

实际上，单一职责的具体粒度大小，要看具体的业务，有时需要做到接口（类）级别的单一职责，有时（比如业务很简单）做到方法级别的单一职责就可以了。比如我们的demo比较简单，实际上也可以把不同的run()方法写到一个交通工具类中：

public class SingleResponsibility3 {

    public static void main(String[] args) {
        Vehicle2 vehicle2 = new Vehicle2();
        vehicle2.run("摩托车");
        vehicle2.run("汽车");
        vehicle2.runAir("飞机");
    }
}


class Vehicle2 {
    public void run(String vehicle) {
        System.out.println(vehicle + "在公路上运行。。。");
    }

    public void runAir(String vehicle) {
        System.out.println(vehicle + "在天上运行。。。");
    }
}

打印输出：

摩托车在公路上运行。。。
汽车在公路上运行。。。
飞机在天上运行。。。

此示例在方法级别上做到了单一职责原则。

二、接口隔离（Interface Segregation）

接口隔离原则，就是我们依赖的接口，需要功能是最小粒度的，不要依赖自己不需要的内容。如果依赖的接口有不需要的方法，那么需要拆分接口。

有如下类图：
类B和D实现了接口方法。A想通过接口依赖B中的123方法；C想通过接口依赖D中的145方法。

出现的问题：
A只需要B的123方法，但是通过上述方式，B不得不实现所有接口方法，实际上本应该只需要实现123方法；
C只需要D的145方法，但是通过上述方式，D不得不实现所有接口方法，实际上本应该只需要实现145方法；

正确方式：

将接口拆分为3个，
A只需要C的123，那么C就只实现接口1和2；
B只需要D的145，那么D就只实现接口1和3；

这就是接口隔离原则。就是我们依赖的接口，需要功能是最小粒度的，不要依赖自己不需要的内容。

三、依赖倒转（Dependence Inversion）

原则要点：

• 高层模块不应该依赖低层模块，二者都应该依赖其抽象；
• 抽象不应该依赖细节，细节应该依赖抽象；
• 依赖倒转原则的核心思想是面向接口（抽象类）编程；

Demo：
写一个Person类，接受电子邮件等类型的消息。

1. 违反依赖倒转原则的示例：

public class DependencyInversion1 {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());
    }
}

class Email {
    public String getInfo() {
        return "接收电子邮件：helloWorld";
    }
}

//Person接收消息
class Person {
    public void receive(Email email) {
        System.out.println(email.getInfo());
    }
}

上述代码，只能接受邮件类型的消息，如果我们想增加weixin等其他类型的消息，则需要改动Person类，同时客户端层（main方法）也需要修改，不利于扩展。

2. 遵守依赖倒转原则的示例：

public class DependencyInversion2 {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());
        person.receive(new WeiXin());
    }
}

class Email implements IReceiver {

    @Override
    public String getInfo() {
        return "接收电子邮件：helloWorld";
    }
}

class WeiXin implements IReceiver {

    @Override
    public String getInfo() {
        return "接收微信消息：hello";
    }
}

//Person接收，依赖接口，增加消息类型时，这里不需要改动。
class Person {

    public void receive(IReceiver iReceiver) {
        System.out.println(iReceiver.getInfo());
    }
}

上述代码中，增加了接口，Person依赖接口，而不是直接依赖具体的Email或者WeiXin，这就是依赖倒转。在我们增加其他消息类型时，不需要改动Person；客户端也不用改动，只需修改入参即可。

四、里氏替换原则

里氏替换原则：任何父类出现的地方，都可以使用其子类去替换。

里氏替换原则，强调的是继承关系。也就是，在我们继承一个类时需要注意的问题。

继承包含这样一层含义，凡是父类中已经定义实现好的方法，实际上是在设计规范和契约，不希望子类去修改这些规范和契约，虽然在编码语法上可能对这种契约没有限制。

比如，父类中有了a方法，那么实际上子类在继承的时候，是不应该去重写这个方法的，否则就违反了里氏替换原则。

错误示例：

class A {
    //实现两个数相减
    public int func1(int num1, int num2) {
        return num1 - num2;
    }
}

上述A类中，有一个方法func1，实现了两个参数相减。

然后下面B类继承了A类，写代码的人没注意，重写了func1方法，功能是两个参数相加：

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

同样的方法，父类和子类的功能是不一样的，这种不一样有时候时很难察觉的；我们在使用a.func1()方法时，有可能就是想用父类方法，完成两个数相减，但实际上会得到相加的结果，导致错误。

正确示例：
如果在B中真的需要func1方法，那么就不要继承A，而是通过继承抽象类或者接口，使用多态实现。

五、开闭原则（Open Close PrincIple）

开闭原则是编程中最基础和最重要的原则。要求对扩展开放（服务提供方），对修改关闭（服务使用方）。当软件需求变化时或者功能需要扩展时，可以通过增加新的类实现，而不是修改原有的类代码。使用其他设计原则，最终目的都是为了实现这个效果。

错误示例：

public class Ocp {
    public static void main(String[] args) {
        GraphicEditor graphicEditor = new GraphicEditor();
        graphicEditor.drawShap(new Rectangle());
        graphicEditor.drawShap(new Circle());
    }
}

//绘制图形，相当于客户端
class GraphicEditor {
    public void drawShap(Shape shape) {
        if (shape.type == 1) {
            drawRectangle(shape);
        } else if (shape.type == 2) {
            drawCircle(shape);
        }
    }

    public void drawRectangle(Shape shape) {
        System.out.println("矩形");
    }

    public void drawCircle(Shape shape) {
        System.out.println("圆形");
    }
}

class Shape {
    int type;
}

class Rectangle extends Shape {
    Rectangle() {
        super.type = 1;
    }
}

class Circle extends Shape {
    Circle() {
        super.type = 2;
    }
}

上述代码功能是画不同的图形，具体有矩形，圆形。具体动作是在GraphicEditor类中，这个相当于是客户端，也就是服务的使用方。
问题是，如果我们增加一种新的画图功能，比如画三角形，就需要修改客户端的代码。这违反了开闭原则。

正确示例：

如果要满足开闭原则，那么新增画图方法时，就不能修改客户端的代码。

public class Ocp {
    public static void main(String[] args) {
        GraphicEditor graphicEditor = new GraphicEditor();
        graphicEditor.drawShap(new Rectangle());
        graphicEditor.drawShap(new Circle());
    }
}

//绘制图形，相当于客户端
class GraphicEditor {
    public void drawShap(Shape shape) {
        shape.drawShape();
    }
}

abstract class Shape {
    abstract void drawShape();
}

class Rectangle extends Shape {

    @Override
    void drawShape() {
        System.out.println("矩形");
    }
}

class Circle extends Shape {

    @Override
    void drawShape() {
        System.out.println("圆形");
    }
}

改进后，如果新增一个画图方法，不用动GraphicEditor；这总该法，实际上和上面的依赖倒转原则是一致的。

六、迪米特法则（Demeter Principle）

迪米特法则又叫 最少知道原则。目的是降低类之间的耦合，但是并不要求完全没有依赖关系。

基本介绍：

• 一个对象，应该保持对其他对象保持最少的了解；
• 类与类的 关系越密切，耦合度越强；
• 一个类对自己所依赖的类，知道的越少越好，被依赖的类，不关内部逻辑有多复杂，都应该尽量封装在类的内部，对外提供public方法访问。

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

直接朋友：
只要两个对象之间存在耦合，我们就说这两个对象之间是朋友关系。耦合的方式很多，包括依赖，关联，组合，聚合等。其中，我们认为出现在 成员变量，方法参数，方法返回值 中的类，为直接朋友；而出现在局部变量中的类，不是直接朋友。也就是说，陌生的类，最好不要以局部变量的形式出现在类的内部。

七、合成复用原则（Composite Reuse Principle）

原则是尽量使用合成/聚合的方式，而不是使用继承。

如下图就是错误的继承：

B类想使用A类中的方法，我们可能会象到使用继承，让B去继承A。但是这样带来的问题是，如果B只是想用A中方法1，如果使用继承，那么不想要的方法2和方法3也会被继承过来，这样就增加了A和B类的耦合程度。

正常的方式应该是让A去组合B：

class A {
    public B b = new B();
    //其他使用B的业务
}