设计模式的分类

实现源码

• 1 创建型模式
  这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。

  • 工厂模式（Factory Pattern）
  • 抽象工厂模式（Abstract Factory Pattern）
  • 单例模式（Singleton Pattern）
  • 建造者模式（Builder Pattern）
  • 原型模式（Prototype Pattern）

• 2 结构型模式
  结构型设计模式关注类和对象的组合。继承则作为手段来组合接口和定义组合对象获得新功能的方式。

  • 适配器模式（Adapter Pattern）
  • 桥接模式（Bridge Pattern）
  • 过滤器模式（Filter、Criteria Pattern）
  • 组合模式（Composite Pattern）
  • 装饰器模式（Decorator Pattern）
  • 外观模式（Facade Pattern）
  • 享元模式（Flyweight Pattern）
  • 代理模式（Proxy Pattern）

• 3 行为型模式
  这些设计模式特别关注对象之间的通信。

  • 责任链模式（Chain of Responsibility Pattern）
  • 命令模式（Command Pattern）
  • 解释器模式（Interpreter Pattern）
  • 迭代器模式（Iterator Pattern）
  • 中介者模式（Mediator Pattern）
  • 备忘录模式（Memento Pattern）
  • 观察者模式（Observer Pattern）
  • 状态模式（State Pattern）
  • 空对象模式（Null Object Pattern）
  • 策略模式（Strategy Pattern）
  • 模板模式（Template Pattern）
  • 访问者模式（Visitor Pattern）

• 4.J2EE 模式
  这些设计模式特别关注表示层。这些模式是由 Sun Java Center 鉴定的。

  • MVC 模式（MVC Pattern）
  • 业务代表模式（Business Delegate Pattern）
  • 组合实体模式（Composite Entity Pattern）
  • 数据访问对象模式（Data Access Object Pattern）
  • 前端控制器模式（Front Controller Pattern）
  • 拦截过滤器模式（Intercepting Filter Pattern）
  • 服务定位器模式（Service Locator Pattern）
  • 传输对象模式（Transfer Object Pattern）

SOLID基本原则

• 单一责任原则
  一个类只能因为一个理由被修改。

A class should have one, and only one, reason to change.

一个类应该只为一个目标服务。并不是说每个类都只能有一个方法，但它们都应该与类的责任有直接关系。所有的方法和属性都应该努力做好同一类事情。当一个类具有多个目标或职责时，就应该创建一个新的类出来。

我们来看一下这段代码：

public class OrdersReportService {
    
    
    public List<OrderVO> getOrdersInfo(Date startDate, Date endDate) {
    
    
        List<OrderDO> orders = queryDBForOrders(startDate, endDate);
        return transform(orders);
    }
    private List<OrderDO> queryDBForOrders(Date startDate, Date endDate) {
    
    
        // select * from order where date >= startDate and date < endDate;
    }
    private List<OrderVO> transform(List<OrderDO> orderDOList) {
    
    
        //transform DO to VO
    }
}

这段代码就违反了单一责任原则。为什么会在这个类中执行sql语句？这样的操作应该放到持久化层，持久化层负责处理数据的持久化的相关操作，包括从数据库中存储或查询数据。所以这个职责不应该属于这个类。

transform方法同样不应该属于这个类，因为我们可能需要很多种类型的转换。

因此我们需要对代码进行重构，重构之后的代码如下（为了节省篇幅）：

public class OrdersReportService {
    
    
    @Autowired
    private OrdersReportDao ordersReportDao;
    @Autowired
    private Formatter formatter;
    public List<OrderVO> getOrdersInfo(Date startDate, Date endDate) {
    
    
        List<OrderDO> orders = ordersReportDao.queryDBForOrders(startDate, endDate);
        return formatter.transform(orders);
    }
}
public class OrdersReportDao {
    
    
    public List<OrderDO> queryDBForOrders(Date startDate, Date endDate) {
    
    }
}
public class Formatter {
    
    
    private List<OrderVO> transform(List<OrderDO> orderDOList) {
    
    }
}

• 开闭原则
  对扩展开放，对修改关闭。

Entities should be open for extension, but closed for modification.

软件实体（包括类、模块、函数等）都应该可扩展，而不用因为扩展而修改实体的内容。如果我们严格遵循这个原则，就可以做到修改代码行为时，不需要改动任何原始代码。

我们还是以一段代码为例：

class Rectangle extends Shape {
    
    
    private int width;
    private int height;
    public Rectangle(int width, int height) {
    
    
        this.width = width;
        this.height = height;
    }
}
class Circle extends Shape {
    
    
    private int radius;
    public Circle(int radius) {
    
    
        this.radius = radius;
    }
}
class CostManager {
    
    
    public double calculate(Shape shape) {
    
    
        double costPerUnit = 1.5;
        double area;
        if (shape instanceof Rectangle) {
    
    
            area = shape.getWidth() * shape.getHeight();
        } else {
    
    
            area = shape.getRadius() * shape.getRadius() * pi();
        }
        return costPerUnit * area;
    }
}

如果你想要计算正方形的面积，那么我们就需要修改calculate方法的代码。这就破坏了开闭原则。根据这个原则，我们不能修改原有代码，但是我们可以进行扩展。

所以我们可以把计算面积的方法放到Shape类中，再由每个继承它的子类自己去实现自己的计算方法。这样就不用修改原有的代码了。

• 里氏替换原则

里氏替换原则是由Barbara Liskov在1987年的“数据抽象“大会上提出的。Barbara Liskov和Jeannette Wing在1994年发表了论文对这一原则进行阐述：

如果φ(x)是类型T的属性，并且S是T的子类型，那么φ(y)就是S的属性。

Let φ(x) be a property provable about objects x of type T. Then φ(y)
should be true for objects y of type S where S is a subtype of T.

Barbara Liskov给出了易于理解的版本，但是这一版本更依赖于类型系统：

1. Preconditions cannot be strengthened in a subtype.

2. Postconditions cannot be weakened in a subtype.

3. Invariants of the supertype must be preserved in a subtype.

Robert Martin在1996年提出了更加简洁、通顺的定义：

使用指向基类指针的函数也可以使用子类。

Functions that use pointers of references to base classes must be able
to use objects of derived classes without knowing it.

更简单一点讲就是子类可以替代父类。

根据里氏替换原则，我们可以在接受抽象类（接口）的任何地方用它的子类（实现类）来替代它们。基本上，我们应该注意在编程时不能只关注接口的输入参数，还需要保证接口实现类的返回值都是同一类型的。

下面这段代码就违反了里氏替换原则：

<?php
interface LessonRepositoryInterface
{
    
    
    /**
     * Fetch all records.
     *
     * @return array
     */
    public function getAll();
}
class FileLessonRepository implements LessonRepositoryInterface
{
    
    
    public function getAll()
    {
    
    
        // return through file system
        return [];
    }
}
class DbLessonRepository implements LessonRepositoryInterface
{
    
    
    public function getAll()
    {
    
    
        /*
            Violates LSP because:
              - the return type is different
              - the consumer of this subclass and FileLessonRepository won't work identically
         */
        // return Lesson::all();
        // to fix this
        return Lesson::all()->toArray();
    }
}

译者注：这里没想到Java应该怎么实现，因此直接用了作者的代码，大家理解就好

• 接口隔离原则
  不能强制客户端实现它不使用的接口。

A client should not be forced to implement an interface that it
doesn’t use.

这个规则告诉我们，应该把接口拆的尽可能小。这样才能更好的满足客户的确切需求。

与单一责任原则类似，接口隔离原则也是通过将软件拆分为多个独立的部分来最大程度的减少副作用和重复代码。

我们来看一个例子：

public interface WorkerInterface {
    
    
    void work();
    void sleep();
}
public class HumanWorker implements WorkerInterface {
    
    
    public void work() {
    
    
        System.out.println("work");
    }
    public void sleep() {
    
    
        System.out.println("sleep");
    }
}
public class RobotWorker implements WorkerInterface {
    
    
    public void work() {
    
    
        System.out.println("work");
    }
    public void sleep() {
    
    
        // No need
    }
}

在上面这段代码中，我们很容易发现问题所在，机器人不需要睡觉，但是由于实现了WorkerInterface接口，它不得不实现sleep方法。这就违背了接口隔离的原则，下面我们一起修复一下这段代码：

public interface WorkAbleInterface {
    
    
    void work();
}
public interface SleepAbleInterface {
    
    
    void sleep();
}
public class HumanWorker implements WorkAbleInterface, SleepAbleInterface {
    
    
    public void work() {
    
    
        System.out.println("work");
    }
    public void sleep() {
    
    
        System.out.println("sleep");
    }
}
public class RobotWorker implements WorkerInterface {
    
    
    public void work() {
    
    
        System.out.println("work");
    }
}

• 依赖倒置原则

高层模块不应该依赖于低层的模块，它们都应该依赖于抽象。

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

High-level modules should not depend on low-level modules. Both should
depend on abstractions.

Abstractions should not depend on details. Details should depend on
abstractions.

简单来讲就是：抽象不依赖于细节，而细节依赖于抽象。

通过应用依赖倒置模块，只需要修改依赖模块，其他模块就可以轻松得到修改。同时，低层模块的修改是不会影响到高层模块修改的。

我们来看这段代码：

public class MySQLConnection {
    
    
    public void connect() {
    
    
        System.out.println("MYSQL Connection");
    }
}
public class PasswordReminder {
    
    
    private MySQLConnection mySQLConnection;
    public PasswordReminder(MySQLConnection mySQLConnection) {
    
    
        this.mySQLConnection = mySQLConnection;
    }
}

有一种常见的误解是，依赖倒置只是依赖注入的另一种表达方式，实际上两者并不相同。

在上面这段代码中，尽管将MySQLConnection类注入了PasswordReminder类，但它依赖于MySQLConnection。而高层模块PasswordReminder是不应该依赖于低层模块MySQLConnection的。因此这不符合依赖倒置原则。

如果你想要把MySQLConnection改成MongoConnection，那就要在PasswordReminder中更改硬编码的构造函数注入。

要想符合依赖倒置原则，PasswordReminder就要依赖于抽象类（接口）而不是细节。那么应该怎么改这段代码呢？我们一起来看一下：

public interface ConnectionInterface {
    
    
    void connect();
}
public class MySQLConnection implements ConnectionInterface {
    
    
    public void connect() {
    
    
        System.out.println("MYSQL Connection");
    }
}
public class PasswordReminder {
    
    
    private ConnectionInterface connection;
    public PasswordReminder(ConnectionInterface connection) {
    
    
        this.connection = connection;
    }
}

修改后的代码中，如果我们想要将MySQLConnection改成MongoConnection，就不需要修改PasswordReminder类的构造函数注入，因为这里PasswordReminder类依赖于抽象而非细节。

------ 如果文章对你有用，感谢右上角 >>>点赞 | 收藏 <<<