设计模式有六大基本原则，它们分别是什么？

八股文_设计模式面试题 0 9

参考回答

设计模式的六大基本原则是为帮助我们设计更加灵活、易于扩展和维护的系统。它们分别是：

单一职责原则（SRP, Single Responsibility Principle）：
- 每个类应该只有一个责任，也就是一个类应该只处理一种类型的任务或功能。这样有助于保持类的简洁和高内聚，易于理解和维护。
开放封闭原则（OCP, Open-Closed Principle）：
- 软件实体（类、模块、函数等）应该对扩展开放，对修改封闭。也就是说，当需求发生变化时，应通过添加新功能而不是修改现有代码来实现。
里氏替换原则（LSP, Liskov Substitution Principle）：
- 继承应该遵循里氏替换原则，即子类对象能够替换父类对象，并且程序的功能不受影响。子类应该扩展父类的功能，而不是改变父类的行为。
依赖倒转原则（DIP, Dependency Inversion Principle）：
- 高层模块不应该依赖低层模块，二者都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。这个原则强调通过依赖注入（DI）来实现模块之间的解耦。
接口隔离原则（ISP, Interface Segregation Principle）：
- 不要强迫客户端依赖它们不需要的接口。一个接口应该仅包含相关的功能，客户端只需要关心它所使用的接口。
迪米特法则（LoD, Law of Demeter）：
- 一个对象应该对其他对象有最少的了解。也就是说，尽量减少一个对象对其他对象的直接依赖，尤其是对链式调用的依赖。

详细讲解与拓展

1. 单一职责原则（SRP）

单一职责原则是指一个类应该只有一个原因引起它的变化，也就是说，一个类应该只负责一项功能或职责。如果一个类有多个职责，它就应该拆分成多个类，每个类专注于一项职责。

示例：
假设有一个类UserManager，它既负责用户注册、登录等操作，又负责用户的数据库操作。如果我们要修改用户登录逻辑，我们就不得不修改数据库操作的部分，违背了单一职责原则。正确的做法是将用户管理和数据库操作分开，创建两个类：UserService和UserRepository。

class UserService {
    public void register() {
        // 注册用户
    }

    public void login() {
        // 用户登录
    }
}

class UserRepository {
    public void saveUser(User user) {
        // 保存用户到数据库
    }
}

2. 开放封闭原则（OCP）

开放封闭原则要求系统应该能够在不修改现有代码的情况下，进行功能扩展。它通过继承或接口的方式实现，意味着我们可以通过新增类或模块来扩展功能，而不需要修改原有的代码。

示例：
假设我们有一个订单处理系统，它根据不同的支付方式进行支付处理。我们可以通过抽象支付方式的接口，扩展支付方式，而不修改现有的支付代码。

interface Payment {
    void processPayment();
}

class AlipayPayment implements Payment {
    public void processPayment() {
        // 支付宝支付逻辑
    }
}

class WechatPayment implements Payment {
    public void processPayment() {
        // 微信支付逻辑
    }
}

通过这种方式，支付方式的新增不需要修改订单处理系统的代码，从而遵循了开放封闭原则。

3. 里氏替换原则（LSP）

里氏替换原则强调子类可以替换父类，并且程序的功能不应受影响。也就是说，子类必须能够完全实现父类的功能，并且不改变父类的方法行为。如果子类改变了父类的行为，程序的正确性就会受到影响。

示例：
假设我们有一个父类Shape，它有一个方法draw()。如果子类Circle和Rectangle都继承自Shape并且正确实现了draw()方法，那么它们就遵循了里氏替换原则。

class Shape {
    public void draw() {
        // 绘制形状
    }
}

class Circle extends Shape {
    @Override
    public void draw() {
        // 绘制圆形
    }
}

class Rectangle extends Shape {
    @Override
    public void draw() {
        // 绘制矩形
    }
}

在这个例子中，我们可以替换Shape对象为Circle或Rectangle对象，程序依然能够正常工作。

4. 依赖倒转原则（DIP）

依赖倒转原则要求高层模块和低层模块都应依赖于抽象，而不是具体的实现。抽象不应依赖于细节，细节应该依赖于抽象。实现这一原则的方式之一是依赖注入（DI），它能有效地解耦系统中的模块。

示例：
假设我们有一个订单系统，它依赖于支付系统。我们可以使用接口来解耦，避免高层模块直接依赖具体的支付实现。

interface PaymentService {
    void pay();
}

class PayPalPayment implements PaymentService {
    public void pay() {
        // PayPal支付逻辑
    }
}

class Order {
    private PaymentService paymentService;

    public Order(PaymentService paymentService) {
        this.paymentService = paymentService;
    }

    public void placeOrder() {
        paymentService.pay();
    }
}

通过依赖注入，我们可以在不修改Order类的情况下，轻松切换支付实现。

5. 接口隔离原则（ISP）

接口隔离原则要求接口应该根据客户端需求来划分，不要强迫客户端依赖它们不需要的接口。换句话说，一个接口应该尽量小而专注，避免客户端依赖过多不相关的方法。

示例：
假设有一个多功能的打印机类，包含了打印、扫描和传真等功能。如果用户只需要打印功能，那么他应该只依赖打印接口，而不是依赖包含扫描和传真功能的接口。

interface Printer {
    void print();
}

interface Scanner {
    void scan();
}

class MultiFunctionPrinter implements Printer, Scanner {
    public void print() {
        // 打印功能
    }

    public void scan() {
        // 扫描功能
    }
}

这种设计使得不同的用户可以选择所需的功能接口，从而遵循了接口隔离原则。

6. 迪米特法则（LoD）

迪米特法则要求一个对象对其他对象的了解要尽量少，只与直接相关的对象进行交互。换句话说，一个对象不应该知道太多关于其他对象的细节，避免过多的依赖关系。

示例：
假设有一个Car类，它不应该直接访问Engine类的内部实现，而是通过Engine类提供的接口进行交互。

class Engine {
    public void start() {
        // 启动引擎
    }
}

class Car {
    private Engine engine;

    public Car(Engine engine) {
        this.engine = engine;
    }

    public void drive() {
        engine.start();
    }
}

在这个例子中，Car类通过Engine的接口与Engine类进行交互，避免了直接访问Engine类的内部实现，从而减少了依赖关系，遵循了迪米特法则。

总结

这六大基本原则是设计高质量软件的基石。遵循这些原则可以帮助我们设计出更加灵活、可维护且可扩展的系统。单一职责原则确保模块专注，开放封闭原则促进扩展，里氏替换原则保障继承关系的正确性，依赖倒转原则减轻模块间的依赖，接口隔离原则让接口更加简洁，迪米特法则则减少了模块间的耦合。通过合理应用这些原则，我们可以构建出更加稳定和高质量的软件系统。