theme: v-green

六大设计原则

评价代码的质量，一般都是从代码是否可维护，是否简单易读，可拓展性，灵活性，简洁性等方面来评价。设计模式是代码设计经验的总结，学习设计模式可以有效提高程序员的coding能力，让你写出质量上乘的代码。设计模式一共有23种，虽然数量不少，但是它们基本上都是这六大设计原则的实现方式。可以说，这六大设计原则就是23种设计模式的基本设计思想。本文简要介绍六种设计原则，并通过实际代码示例加以说明。

1. 单一职责原则（Single Responsibility Principle）

定义：一个类应该只有一个引起它变化的原因，即一个类只负责完成一个职责或者功能。

设计要点：避免设计大而全的类，要设计功能单一，粒度适中的类。

判断标准

• 类中代码行数过多，代码功能职责不清晰；
• 类中包含过多的函数和属性，导致代码维护困难；
• 类的依赖过多，导致程序耦合度过高；
• 类的私有方法过多且这些方法集中操作少数属性。

重构建议

当类变得庞大且功能不单一时，应该把它拆分成多个职责单一的小类。

代码示例

违反单一职责原则的类

// User类同时处理用户信息和用户数据存储
public class User {
   
    private String name;
    private String email;

    // 获取用户名称
    public String getName() {
   
        return name;
    }

    // 设置用户名称
    public void setName(String name) {
   
        this.name = name;
    }

    // 获取用户邮箱
    public String getEmail() {
   
        return email;
    }

    // 设置用户邮箱
    public void setEmail(String email) {
   
        this.email = email;
    }

    // 保存用户到数据库
    public void save() {
   
        // 代码实现保存用户到数据库
    }
}

遵循单一职责原则的类

// 仅负责用户信息的User类
public class User {
   
    private String name;
    private String email;

    // 获取用户名称
    public String getName() {
   
        return name;
    }

    // 设置用户名称
    public void setName(String name) {
   
        this.name = name;
    }

    // 获取用户邮箱
    public String getEmail() {
   
        return email;
    }

    // 设置用户邮箱
    public void setEmail(String email) {
   
        this.email = email;
    }
}

// 负责用户数据存储的UserRepository类
public class UserRepository {
   
    // 保存用户到数据库
    public void save(User user) {
   
        // 代码实现保存用户到数据库
    }
}

说明：通过将用户信息和数据存储职责分离，User类仅关注用户数据，而UserRepository类负责数据的持久化操作，提高了代码的可维护性和可扩展性。

2. 开闭原则（Open-Closed Principle）

定义：软件实体（类，模块，函数等）应对拓展开放，对修改封闭。

核心思想

• 对拓展开放：允许通过拓展来增加新的功能。
• 对修改封闭：在需求变化时，不通过直接修改已有功能代码，而是通过增加拓展模块来实现新的功能。

实现方法

使用抽象类或接口来定义稳定的结构，具体功能的拓展通过实现这些抽象类或接口来实现。

重要性

• 符合开闭原则的软件可以更好地适应变化，维护成本更低；
• 所有的设计模式都追求这一原则，以确保系统开发和维护的可靠性。

代码示例

违反开闭原则的类

public class GraphicEditor {
   
    public void drawShape(Shape shape) {
   
        if (shape.type == 1) {
   
            drawCircle((Circle) shape);
        } else if (shape.type == 2) {
   
            drawRectangle((Rectangle) shape);
        }
        // 如果新增形状，需要修改此方法
    }

    private void drawCircle(Circle circle) {
   
        // 绘制圆形的代码
    }

    private void drawRectangle(Rectangle rectangle) {
   
        // 绘制矩形的代码
    }
}

public class Shape {
   
    int type;
}

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

public class Rectangle extends Shape {
   
    public Rectangle() {
   
        type = 2;
    }
}

遵循开闭原则的类

// 抽象类Shape，定义绘制方法
public abstract class Shape {
   
    public abstract void draw();
}

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

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

// 图形编辑器类，不需要修改即可支持新形状
public class GraphicEditor {
   
    public void drawShape(Shape shape) {
   
        shape.draw();
    }
}

说明：通过使用抽象类Shape，GraphicEditor类无需修改即可支持新的形状，只需新增继承自Shape的类，实现draw方法即可。

3. 里氏替换原则（Liskov Substitution Principle）

定义：子类对象可以替换父类对象的任何地方，并保证程序的逻辑行为不变。

理解方式

• 替换依赖于面向对象语言中的多态特性，子类对象应该可以在父类出现的任何地方替换父类对象。
• 子类的实现应该遵守接口或父类定义的方法规范，即方法的输入和输出保持一致（保证行为不变）。

代码示例

违反里氏替换原则的类

// 父类鸟
public class Bird {
   
    public void fly() {
   
        // 鸟类飞行的实现
    }
}

// 企鹅类继承自鸟，但企鹅不会飞
public class Penguin extends Bird {
   
    @Override
    public void fly() {
   
        throw new UnsupportedOperationException("企鹅不会飞");
    }
}

遵循里氏替换原则的类

// 抽象类动物
public abstract class Animal {
   
    // 一般动物的共同行为
}

// 可以飞行的动物接口
public interface Flyable {
   
    void fly();
}

// 鸟类实现Flyable接口
public class Bird extends Animal implements Flyable {
   
    @Override
    public void fly() {
   
        // 鸟类飞行的实现
    }
}

// 企鹅类不实现Flyable接口
public class Penguin extends Animal {
   
    // 企鹅的特有行为
}

说明：通过将会飞的行为抽象为Flyable接口，企鹅类不再继承不适用的fly方法，避免了因子类行为不一致导致的问题，符合里氏替换原则。

4. 接口隔离原则（Interface Segregation Principle）

定义：为各个类设计它们需要的专用接口，而不是设计一个庞大的通用接口供所有的类调用。

设计要点

• 避免创建“胖接口”，而是要根据具体需求将接口拆分成对应的多个专一的接口。
• 提高内聚性，降低耦合性，使类与接口之间的依赖关系更清晰。

与单一职责原则的区别：单一职责原则注重类的职责单一，接口隔离原则侧重于接口依赖的隔离。

代码示例

违反接口隔离原则的接口

public interface Worker {
   
    void work();
    void eat();
}

public class HumanWorker implements Worker {
   
    @Override
    public void work() {
   
        // 人类工作实现
    }

    @Override
    public void eat() {
   
        // 人类吃饭实现
    }
}

public class RobotWorker implements Worker {
   
    @Override
    public void work() {
   
        // 机器人工作实现
    }

    @Override
    public void eat() {
   
        // 机器人不需要吃饭，但必须实现该方法
        throw new UnsupportedOperationException("机器人不需要吃饭");
    }
}

遵循接口隔离原则的接口

// 工作接口
public interface Workable {
   
    void work();
}

// 吃饭接口
public interface Eatable {
   
    void eat();
}

public class HumanWorker implements Workable, Eatable {
   
    @Override
    public void work() {
   
        // 人类工作实现
    }

    @Override
    public void eat() {
   
        // 人类吃饭实现
    }
}

public class RobotWorker implements Workable {
   
    @Override
    public void work() {
   
        // 机器人工作实现
    }
}

说明：通过将Worker接口拆分为Workable和Eatable，机器人类不再需要实现与其不相关的eat方法，符合接口隔离原则。

5. 依赖倒置原则（Dependency Inversion Principle）

定义：高层模块不应该依赖于低层模块，两者都应该依赖于抽象。抽象不应该依赖细节，细节应该依赖抽象。

实现方式

• 面向接口编程，而不是面向具体实现。
• 通过依赖注入的方式，将低层模块的实现注入到高层模块的抽象中。

目的

降低模块之间的耦合度，提高系统的灵活性和可维护性。

代码示例

违反依赖倒置原则的类

// 低层模块：数据库日志记录
public class DatabaseLogger {
   
    public void log(String message) {
   
        // 将日志记录到数据库
    }
}

// 高层模块：用户服务
public class UserService {
   
    private DatabaseLogger logger = new DatabaseLogger();

    public void createUser(String username) {
   
        // 创建用户的逻辑
        logger.log("User created: " + username);
    }
}

遵循依赖倒置原则的类

// 抽象日志记录接口
public interface Logger {
   
    void log(String message);
}

// 低层模块：数据库日志记录实现
public class DatabaseLogger implements Logger {
   
    @Override
    public void log(String message) {
   
        // 将日志记录到数据库
    }
}

// 低层模块：文件日志记录实现
public class FileLogger implements Logger {
   
    @Override
    public void log(String message) {
   
        // 将日志记录到文件
    }
}

// 高层模块：用户服务
public class UserService {
   
    private Logger logger;

    // 通过构造函数注入依赖
    public UserService(Logger logger) {
   
        this.logger = logger;
    }

    public void createUser(String username) {
   
        // 创建用户的逻辑
        logger.log("User created: " + username);
    }
}

使用示例

public class Main {
   
    public static void main(String[] args) {
   
        // 选择具体的日志记录实现
        Logger logger = new DatabaseLogger();
        // 或者使用文件日志记录
        // Logger logger = new FileLogger();

        // 通过依赖注入将Logger传递给UserService
        UserService userService = new UserService(logger);
        userService.createUser("JohnDoe");
    }
}

说明：高层模块UserService依赖于抽象Logger接口，而不是具体的DatabaseLogger或FileLogger，从而实现了依赖倒置，增强了系统的灵活性和可扩展性。

6. 迪米特法则（Law of Demeter）

定义：一个类应该尽量少地依赖其他的类，减少类之间的相互依赖关系。

设计要点

• 避免直接与不必要的类进行通信，减少类之间的直接依赖关系。
• 降低类之间的耦合度，提高模块的独立性和可维护性。

代码示例

违反迪米特法则的类

public class OrderService {
   
    private OrderRepository orderRepository = new OrderRepository();

    public void processOrder(int orderId) {
   
        Order order = orderRepository.getOrderById(orderId);
        Customer customer = order.getCustomer();
        Address address = customer.getAddress();
        // 直接访问Customer和Address的细节
        sendEmail(address.getEmail(), "Your order has been processed.");
    }

    private void sendEmail(String email, String message) {
   
        // 发送邮件的逻辑
    }
}

遵循迪米特法则的类

// Customer类增加发送邮件的方法
public class Customer {
   
    private Address address;

    public Address getAddress() {
   
        return address;
    }

    public void sendEmail(String message) {
   
        // 发送邮件的逻辑，内部获取地址信息
        String email = address.getEmail();
        // 发送邮件
    }
}

// Order类增加获取Customer的方法
public class Order {
   
    private Customer customer;

    public Customer getCustomer() {
   
        return customer;
    }
}

// OrderRepository类
public class OrderRepository {
   
    public Order getOrderById(int orderId) {
   
        // 获取订单的逻辑
        return new Order();
    }
}

// OrderService类遵循迪米特法则
public class OrderService {
   
    private OrderRepository orderRepository = new OrderRepository();

    public void processOrder(int orderId) {
   
        Order order = orderRepository.getOrderById(orderId);
        // 通过Order直接调用Customer的方法，而不需要了解Customer的内部结构
        order.getCustomer().sendEmail("Your order has been processed.");
    }
}

说明：通过将发送邮件的职责委托给Customer类，OrderService类不再需要了解Customer和Address的内部结构，减少了类之间的耦合，符合迪米特法则。

掌握这些设计原则，并在实际编码中灵活运用，将为后续学习23种设计模式打下坚实的基础，帮助你编写出高质量、可维护、可扩展的代码。