SOLID原则：构建稳健软件的五大支柱
Published in：2017-04-30 | Category： 设计模式
Words: 1.9k | Reading time: 7min | Reading：

在软件开发领域，SOLID原则是一组设计原则，旨在提高代码的可维护性、可读性和可扩展性。

SOLID Principles
SOLID Principles

这五个原则分别是
单一职责原则（Single Responsibility Principle，简称SRP）
开放封闭原则（Open/Closed Principle，简称OCP）
里氏替换原则（Liskov Substitution Principle，简称LSP）
接口隔离原则（Interface Segregation Principle，简称ISP）
依赖反转原则（Dependency Inversion Principle，简称DIP）
本文将详细解释每个原则，并通过实际例子说明它们的应用。

1. 单一职责原则（SRP）

单一职责原则指一个类应该只有一个引起变化的原因。换句话说，一个类应该只负责一个功能领域。这有助于降低类的复杂性，使其更容易理解和维护。

例子： 假设有一个负责处理用户信息的类，包括验证用户、存储用户信息、发送邮件等功能。如果将这些功能拆分成独立的类，比如一个负责验证，一个负责存储，一个负责邮件发送，就能更好地遵循单一职责原则。

不遵循单一职责原则的设计
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 不遵循单一职责原则
class UserManager {
    public void authenticateUser(String username, String password) {
        // 验证用户
    }

    public void saveUser(User user) {
        // 保存用户信息
    }

    public void sendEmail(User user, String message) {
        // 发送邮件
    }
}
遵循单一职责原则的改进
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// 遵循单一职责原则的改进
class Authenticator {
    public void authenticateUser(String username, String password) {
        // 验证用户
    }
}

class UserManager {
    public void saveUser(User user) {
        // 保存用户信息
    }
}

class EmailSender {
    public void sendEmail(User user, String message) {
        // 发送邮件
    }

2. 开放封闭原则（OCP）

开放封闭原则要求软件实体（类、模块、函数等）应该对扩展是开放的，对修改是封闭的。这意味着我们应该通过添加新代码而不是修改现有代码来引入新功能。

例子： 考虑一个负责绘制图形的类，最初只支持矩形的绘制。遵循开放封闭原则，我们可以通过创建新的子类（例如，圆形绘制类）来扩展功能，而不是修改原有的绘制类。

不遵循开放封闭原则的设计
1
2
3
4
5
6
7
8
9
10
// 不遵循开放封闭原则的类
class ShapeDrawer {
    public void draw(Shape shape) {
        if (shape.getType().equals("rectangle")) {
            // 绘制矩形
        } else if (shape.getType().equals("circle")) {
            // 绘制圆形
        }
    }
}
遵循开放封闭原则的改进
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// 遵循开放封闭原则的改进
interface Shape {
    void draw();
}

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

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

class ShapeDrawer {
    public void draw(Shape shape) {
        shape.draw();
    }
}

3. 里氏替换原则（LSP）

里氏替换原则规定，子类应该能够替换其基类而不改变程序的正确性。如果一个软件实体使用基类，那么替换为其子类也不应该导致程序出错。

例子： 假设有一个处理图形面积的类，可以接受任何继承自图形基类的对象。如果一个子类（如矩形）的面积计算不正确，那么它违反了里氏替换原则。

违反里氏替换原则的设计
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// 违反里氏替换原则的设计
class Shape {
    public double calculateArea() {
        return 0; // 默认实现，可以在子类中覆盖
    }
}

class Rectangle extends Shape {
    private double width;
    private double height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }

    @Override
    public double calculateArea() {
        // 这里故意错误地将宽度和高度相加而不是相乘
        return width + height; // 错误的面积计算
    }
}

遵循里氏替换原则的改进
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
class Shape {
    // 基类，所有图形都应该继承自它
    public double calculateArea() {
        return 0; // 默认实现，可以在子类中覆盖
    }
}

class Rectangle extends Shape {
    private double width;
    private double height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }

    @Override
    public double calculateArea() {
        return width * height; // 矩形的面积计算
    }
}

class Square extends Shape {
    private double side;

    public Square(double side) {
        this.side = side;
    }

    @Override
    public double calculateArea() {
        return side * side; // 正方形的面积计算
    }
}

class Circle extends Shape {
    private double radius;

    public Circle(double radius) {
        this.radius = radius;
    }

    @Override
    public double calculateArea() {
        return Math.PI * radius * radius; // 圆形的面积计算
    }
}

4. 接口隔离原则（ISP）

接口隔离原则要求一个类不应该被强迫实现它用不到的接口。换句话说，一个类应该只依赖于它需要的接口。

例子： 假设有一个处理飞行器的类，如果将飞机和潜艇的功能都放在同一个接口中，那么某些类可能会被迫实现它们用不到的方法。通过拆分接口，每个类只需实现其需要的接口，从而遵循接口隔离原则。

不遵循接口隔离原则的设计
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// 违反接口隔离原则的设计
interface Aircraft {
    void fly();
    void dive();
}

class Airplane implements Aircraft {
    @Override
    public void fly() {
        System.out.println("Airplane is flying.");
    }

    @Override
    public void dive() {
        // Airplane doesn't dive, so this method is not meaningful.
    }
}

class Submarine implements Aircraft {
    @Override
    public void fly() {
        // Submarine can't fly, so this method is not meaningful.
    }

    @Override
    public void dive() {
        System.out.println("Submarine is diving.");
    }
}

遵循接口隔离原则的改进
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// 接口隔离原则改进后的设计
interface FlyingAircraft {
    void fly();
}

interface DivingAircraft {
    void dive();
}

class Airplane implements FlyingAircraft {
    @Override
    public void fly() {
        System.out.println("Airplane is flying.");
    }
}

class Submarine implements DivingAircraft {
    @Override
    public void dive() {
        System.out.println("Submarine is diving.");
    }
}

5. 依赖反转原则（DIP）

依赖反转原则要求高层模块不应该依赖于底层模块，而是应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。

例子： 考虑一个购物车类，最初可能直接依赖于具体的支付方式，如信用卡支付类。通过引入一个支付接口并让具体支付类实现它，购物车类就可以依赖于抽象而不是具体的实现，符合依赖反转原则。

不遵循依赖反转原则的设计
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// 不符合依赖反转原则的设计
class CreditCardPayment {
    public void processPayment() {
        System.out.println("Processing payment using Credit Card.");
    }
}

class ShoppingCart {
    private CreditCardPayment paymentMethod;

    public ShoppingCart(CreditCardPayment paymentMethod) {
        this.paymentMethod = paymentMethod;
    }

    public void checkout() {
        System.out.println("Checkout process initiated.");
        paymentMethod.processPayment();
    }
}

遵循依赖反转原则的改进
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// 符合依赖反转原则的设计
// 支付接口
interface Payment {
    void processPayment();
}

// 具体的信用卡支付类实现了支付接口
class CreditCardPayment implements Payment {
    @Override
    public void processPayment() {
        System.out.println("Processing payment using Credit Card.");
    }
}

// 购物车类依赖于支付接口
class ShoppingCart {
    private Payment paymentMethod;  // 依赖抽象

    public ShoppingCart(Payment paymentMethod) {
        this.paymentMethod = paymentMethod;
    }

    public void checkout() {
        System.out.println("Checkout process initiated.");
        paymentMethod.processPayment();  // 通过接口调用支付方法
    }
}

总结

在软件开发中，SOLID原则提供了一种设计良好且易于维护的架构。遵循这些原则有助于降低代码的复杂性，提高可读性，并使代码更容易扩展和维护。通过深入理解和实践这些原则，开发人员可以构建出更为健壮、可维护的软件系统。

SOLID
Prev:
设计模式之单例模式详解与应用
Next:
聊聊前端优化手段防抖

    • Copyright © 2013 - 2022 Andrewsy

    Total visits： times |