设计模式中的七大原则（代码 + 图解）

最新推荐文章于 2022-05-19 15:25:18 发布

Forlogen

最新推荐文章于 2022-05-19 15:25:18 发布

阅读量1.2k

点赞数 3

分类专栏：设计模式

本文链接：https://blog.csdn.net/Forlogen/article/details/106154676

版权

设计模式专栏收录该内容

8 篇文章 0 订阅

订阅专栏

文中涉及的代码：链接：提取码：tqjq

文章目录

- 设计模式

设计模式

1. 目的

对于某个具体的任务来说，如果要你编码实现它所要求的功能，不同的人会给不同的实现方式。可能写代码的人觉得自己的代码没有问题，但代码的重用性、可扩展性和可维护性等特性可能就很差。

因此，为了使软件可以很好的应对耦合性、内聚性、可维护性、重用性、灵活性和可阅读性等多方面的挑战，我们就需要使得编写的软件遵从某些原则和要求，而这就是设计模式需要完成的事情。

设计模型的目的是使得软件在上述的各种特性上具有更好的表现，具体来说：

重用性：相同的功能，不必重写编写；相似的功能，只需修改很少的部分
可读性：即编程的规范性，所写代码应该容易被其他人阅读和理解
可扩展性：可以很方法的在原有基础上添加或删除某些功能
可靠性：对软件某些部分的更新不会影响整体的性能
高内聚、低耦合

2. 分类

常用的设计模型总共有23种，它们大致可以分为创建型模式（Creational Patterns）、结构型模式（Structural Pattern）和行为型模式（Behavioral Pattern）。

在这里插入图片描述

3. 原则

在具体学习设计模式之前，我们需要先了解每种设计模式都需要遵循的原则。总的来说，设计模式中常用的七大原则如下所示：

单一职责原则
接口隔离原则
依赖倒转原则
里氏替换原则
开闭原则
迪米特法则
合成复用原则

3.1单一职责原则

单一职责原则(Single Responsibility Principle, SRP)指出：软件模块应该只有一个被修改的理由。简单来说，即一个类应该只负责一项职责。如果每个模块负责的职责有多个，那么修改该模块的原因可能就有很多，从而导致在修改该模块的同时还要考虑他它的修改是否会影响其他模块的正常运行。

其中类的职责可以分为两类：

数据职责：通过成员变量表示
行为职责：通过成员方法表示

单一职责原则的根本目的在于实现高内聚、低耦合。下面我们通过一个例子来感受一下单一职责原则指的是什么，以及为什么需要遵从。假设此时定义一个Person类，如下所示：

public class Person {
    private String name;

    public Person(String name) {
        this.name = name;
    }

    public void run(String subject){
        System.out.println(this.name + " is studying " + subject + " ...");
    }
}

类中只有一个run()，方法接收一个字符串，输出信息指示某类人正在学习什么。例如：

public class Demo {
    public static void main(String[] args) {
        Person p = new Person("Student");
        p.run("CS");
    }
}

输出为Student is studying CS ...。如果构造函数中传入Teacher、Farmer、Police等任何职业，输出永远表示的是在学习某个课，这显然是不太合理。究其原因是因为run()负责的工作太多了，更好的方式是为不同的职业分别创建不同的类，然后在各个类中分别创建自己的run()。

public class Student {
    public void run(String subject){
        System.out.println("Student is studying " + subject + " ...");
    }
}

public class Teacher {
    public void run(String subject){
        System.out.println("Teacher is teaching " + subject + " ...");
    }
}

分别创建了Student类和Teacher类之后，在使用时只需要根据具体的职业实例化相应的类对象，最后使用run()即可。

public class Demo {
    public static void main(String[] args) {
        new Student().run("CS");
        new Teacher().run("CS");
    }
}

此时的输出为：

Student is studying CS ...
Teacher is teaching CS ...

这样就在类级别上遵从了单一职责原则。从另一个角度出发，另一个选择是应该为不同的职业创建不同的方法，从而在方法级别上遵从单一职责原则。

public class Person {
    private String name;

    public Person(String name) {
        this.name = name;
    }

    public void study(String subject){
        System.out.println(this.name + " is studying " + subject + " ...");
    }

    public void teach(String subject){
        System.out.println(this.name + " is teaching " + subject + " ...");
    }
}

然后在使用时根据不同的职业调用不同的方法：

public class Demo {
    public static void main(String[] args) {
        new Person("Student").study("CS");
        new Person("Teacher").teach("CS");
    }
}

此时输出为：

Student is studying CS ...
Teacher is teaching CS ...

将上面提到的类级别和方法级别上遵从单一原则表示到UML类图上，如下所示：
在这里插入图片描述

总结：通过遵从单一职责原则，程序可以降低类的复杂度，使得一个类只负责一项职责。从而提高了类的可读性和可扩展性。虽然上面的例子中从类和方法两个级别分别遵从单一职责原则，但实际中只有在类中方法足够少，方法逻辑足够简单才使用方法上的单一职责。否则，尽量都在类级别上遵从单一职责原则。

3.2 接口隔离原则

客户端不应该依赖于它所不需要的接口。

接口隔离原则(Interface Segregation Principle, ISP)指的是一旦一个接口中的方法过多，就需要将其划分为一些更细小的接口，从而使得接口的实现类（客户端）只知道它所想使用的方法即可。简单来说就是，每个接口应该只代表一类角色，它只包含所代表的角色所需的方法，而不应该包含此外其他方法。此外满足接口隔离原则时，接口首先必须满足职责单一原则，在满足高内聚的同时，接口中的方法应该尽量少。

例如，现在有一个ICar接口，接口中包含方法sell()、repair()和drive()。如果此时创建接口的实现类Seller，那么就需要实现接口中全部的三个方法，而显然ISeller并不关心repair()和drive()。同理，如果现在创建实现类IDriver，它并不关心sell()、repair()。此时，程序就不满足接口隔离原则。为了使程序满足接口隔离原则，应该将接口进行更细的划分为ISellable、IRepairable和IDrivable，三个接口分别包含sell()、repair()和drive()。

interface ISellable{
    void sell();
}

interface IRepairable{
    void repair();
}
interface IDrivable{
    void drive();
}

class Seller implements ISellable{
    @Override
    public void sell() {
        System.out.println("Selling ...");
    }
}

class Mechanic implements IRepairable{
    @Override
    public void repair() {
        System.out.println("repairing ...");
    }
}

class Driver implements IDrivable{
    @Override
    public void drive() {
        System.out.println("driving ...");
    }
}

public class Demo {
    public static void main(String[] args) {
        new Seller().sell();
        new Mechanic().repair();
        new Driver().drive();
    }
}

此时程序的输出为：

Selling ...
repairing ...
driving ...

如果将上面的过程表现在UML类图上，大致可以表示为：
在这里插入图片描述

3.3 依赖倒转原则

高级模块不应该依赖低级模块，两者都应该依赖抽象。

抽象不应该依赖细节，细节应该依赖抽象。

依赖倒转原则(Dependency Inversion Principle, DIP)指的是代码应该依赖于抽象的类，而不要依赖于具体的类；要面向接口或抽象类编程，而不是针对具体的类编程。其实仔细对照我们实际的编程过程也好理解，虽然OOP已经将所有的东西都抽象为类，但是在此基础上还应该进行进一步的抽象。找到某些类中更加共性的东西，构建构建抽象的接口和抽象类，而在具体的实现类中实现细节。

假设此时定义Person类，类中的方法receive表示从何处接收信息，并调用参数代表的对象中的方法输出相应的信息。

class Email{
    public void show(){
        System.out.println("Email --- hello world...");
    }
}
class Person{
    public void receive(Email email){
        email.show();
    }
}
public class Demo {
    public static void main(String[] args) {
        Person p = new Person();
        p.receive(new Email());
    }
}

如果此时不只使用Email，还有WeChat、Facebook、Twitter……当前的方法就无法满足要求了。因此，根据依赖倒转原则，应该从不同的媒体中抽象出一个接口，接口中只包含show()。然后，通过接口不同的实现类来表示不同的媒体。最后使用时，Person的receive()中只需要接收接口的实例即可。它会根据传入的不同的接口实现类对象，输出相应的信息。

interface Receiver{
    void show();
}

class Email implements Receiver{
    @Override
    public void show() {
        System.out.println("Email --- hello world...");
    }
}

class WeChat implements Receiver{
    @Override
    public void show() {
        System.out.println("WeChat --- hello world...");
    }
}

class Person{
    public void receive(Receiver receiver){
        receiver.show();
    }
}

public class NewDemo {
    public static void main(String[] args) {
        new Person().receive(new Email());
        new Person().receive(new WeChat());
    }
}

将其表现在UML类图上如下所示：
在这里插入图片描述

3.4 里氏替换原则

里氏替换原则(Liskov Substitution Principle, LSP)指的是所有引用基类的地方必须能透明的使用其子类对象，而且使用子类对象进行替换后，程序不会出现任何的错误和异常，反之不成立。根据里氏替换原则，程序中进行使用基类类型进行对象的定义，在运行时确定子类类型，并用子类对象进行替换。

使用继承时，为了遵从里氏替换原则，程序应注意：

子类必须实现父类中声明的所有方法
子类进行不要重写父类中的方法
尽量把基类设计为抽象类或接口，子类为对应的实现类

通过让程序遵从里氏替换原则，使得程序可以更好的使用继承。假设此时定义一个Father类，类中有一个方法method()实现传入的两个参数相加，并返回相加的结果。同时涉及一个Son类，类中重写method()。

class Father{
    public int method(int x, int y){
        return x + y;
    }
}

class Son extends Father{
    @Override
    public int method(int x, int y) {
        return x - y;
    }
}
public class Demo {
    public static void main(String[] args) {
        System.out.println(new Father().method(3, 1));
        System.out.println(new Son().method(3, 1));
    }
}

此时的程序就不满足里氏替换原则。为了遵从里氏替换原则，应该将基类抽象为一个抽象类，抽象类中包含方法method()，然后根据不同的运算分别创建接口的实现类，并重写抽象类中的方法。

abstract class Method{
    public abstract int method(int x, int y);
}

class Add extends Method{
    @Override
    public int method(int x, int y) {
        return x + y;
    }
}

class Sub extends Method{
    @Override
    public int method(int x, int y) {
        return x -y;
    }
}

public class NewDemo {
    public static void main(String[] args) {
        Method m = new Add();
        System.out.println(m.method(3, 1));
        Method m1 = new Sub();
        System.out.println(m1.method(3, 1));
    }
}

同样的，我们将其表示到UML类图中，如下所示：

在这里插入图片描述

3.5 开闭原则

开闭原则(Open-Closed Principle, OCP)指的是一个软件实体应当对扩展开放，对修改关闭。也就是说在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，即实现在不修改源代码的情况下改变这个模块的行为。

假设现在有一个GraphicEditor类，类中有一个方法drawShape()来根据不同的参数画不同的图。

class Shape{
    int type;
}

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

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

class GraphicEditor{
    public void drawShape(Shape s){
        if (s.type == 1){
            drawCircle();
        } else if (s.type == 2){
            drawTriangle();
        }
    }

    private void drawTriangle() {
        System.out.println("drawing triangle...");
    }

    private void drawCircle() {
        System.out.println("drawing circle...");
    }


}
public class Demo {
    public static void main(String[] args) {
        GraphicEditor g = new GraphicEditor();
        g.drawShape(new Circle());
        g.drawShape(new Triangle());
    }
}

如果想要画其他的图形呢？我们只能创建新类，并同时更改GraphicEditor类中drawShape()的逻辑。而这明显破坏了开闭原则，对于要实现的新功能，我们应该使用扩展的方式，而不是修改类的实现代码。

根据开闭原则，我们可以将Shape变为一个抽象类，类中包含抽象方法draw()，Circle和Triangle继承Shape，并实现draw()。GraphicEditor所做不再是根据对象的type值调用不同的方法，而是直接调用传入对象的draw()即可，程序会根据传入的具体对象调用相应的方法。

abstract class Shape{
    int type;
    public abstract void draw();
}

class Circle extends Shape {
    @Override
    public void draw() {
        System.out.println("drawing circle...");
    }
}

class Triangle extends Shape {
    @Override
    public void draw() {
        System.out.println("drawing triangle...");
    }
}

class Rectangle extends Shape{
    @Override
    public void draw() {
        System.out.println("drawing Rectangle...");
    }
}

class GraphicEditor{
    public void drawShape(Shape s){
        s.draw();
    }
}

public class NewDemo {
    public static void main(String[] args) {
        GraphicEditor g = new GraphicEditor();
        g.drawShape(new Circle());
        g.drawShape(new Triangle());
    }
}

这样对于使用者来说，它不必修改使用的代码；对于提供方法来说，每需要增加新功能，只需要在此基础上进行扩展，而不必修改类的代码。

将上面的例子表示到UML类图中为：
在这里插入图片描述

3.6 迪米特法则

迪米特法则(Law of Demeter, LoD)又称最少知道原则，它是指一个对象应该对其他的对象保持最少的了解，对象之间的关系越密切，耦合度越大。迪米特法则另一种说法是：只与直接朋友进行通信。直接朋友指的是出现在成员变量、方法参数、方法返回值中的类称为当前类的直接朋友，而出现在局部变量中的类称为陌生人。

因此，迪米特法则也可以定义为只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

例如明星由于全身心投入艺术，所以许多日常事务由经纪人负责处理，如与媒体公司的业务洽淡。这里的经纪人是明星的朋友，而媒体公司是陌生人，所以适合使用迪米特法则。

public class Star {
    String name;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

public class Company {
    String name;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

public class Agent {
    Star myStar;
    Company company;

    public Star getMyStar() {
        return myStar;
    }

    public void setMyStar(Star myStar) {
        this.myStar = myStar;
    }

    public Company getCompany() {
        return company;
    }

    public void setCompany(Company company) {
        this.company = company;
    }

    public void meeting(){
        System.out.println("meeting...");
    }

    public void business(){
        System.out.println("doing business...");
    }
}

将其表现在UML类图中为：
在这里插入图片描述

3.7 合成复用原则

合成复用原则(Composite Reuse Principle, CRP)又称为组合/聚合复用原则，它的核心思想是尽量使用聚合和组合的方式，而不是继承。也就是说，一个新的对象里通过关联关系（组合/聚合）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用其已有功能的目的。

假设此时有Car类，类中包含方法sell()和repair()，类Seller和Mechanic继承了Car。但对于Mechanic来说，它并不需要sell()；对于Seller来说，它不需要repair()。因此，使用继承来使用Car中的方法并不是一个好的选择。

class Car{
    public void sell(){
        System.out.println("selling...");
    }

    public void repair(){
        System.out.println("repairing...");
    }
}

class Seller extends Car{ }

class Mechanic extends Car{}

public class Demo {
    public static void main(String[] args) {
        new Seller().repair();
        new Mechanic().sell();
    }
}

因此，根据合成复用原则，可以将Car类对象当作Seller和Mechanic的直接朋友使用，从而用组合/聚合代替继承。

class Car{
    public void sell(){
        System.out.println("selling...");
    }

    public void repair(){
        System.out.println("repairing...");
    }
}

class Seller{
    public void sell(Car c){
        c.sell();
    }
}

class Mechanic{
    public void repair(Car c){
        c.repair();
    }
}

public class NewDemo {
    public static void main(String[] args) {
        new Seller().sell(new Car());
        new Mechanic().repair(new Car());
    }
}