第2章

⚖️ 架构设计原则

掌握架构设计的核心原则，构建高质量、可维护的系统架构

学习目标

理解并掌握单一职责原则的应用
学会运用开闭原则设计可扩展的系统
掌握依赖倒置原则降低系统耦合
运用接口隔离原则优化接口设计
应用最小知识原则和DRY原则提高代码质量

架构设计原则概述

架构设计原则是指导我们进行系统架构设计的基本准则。这些原则经过长期的实践验证，能够帮助我们构建高质量、可维护、可扩展的软件系统。遵循这些原则不仅能提高代码质量，还能降低系统的复杂度和维护成本。

核心理念

好的架构设计原则应该促进系统的模块化、降低耦合度、提高内聚性，使系统更容易理解、修改和扩展。

平衡性

在不同的设计目标之间找到平衡点，如性能与可维护性、灵活性与简单性。

模块化

将复杂系统分解为独立的、可重用的模块，每个模块有明确的职责。

可扩展性

设计时考虑未来的变化和扩展需求，使系统能够适应业务发展。

单一职责原则

Single Responsibility Principle (SRP)

单一职责原则规定一个类或模块应该只有一个引起它变化的原因。换句话说，一个类应该只负责一项职责。这个原则有助于提高代码的内聚性，降低耦合度，使代码更容易理解和维护。

核心要点：

职责明确：每个类或模块都有明确、单一的职责
变化隔离：不同的变化原因被隔离在不同的模块中
高内聚：模块内部的元素紧密相关
易测试：单一职责使得单元测试更加简单

实践示例

违反SRP的设计：

class User {
    private String name;
    private String email;
    
    // 用户数据管理
    public void setName(String name) { this.name = name; }
    public String getName() { return name; }
    
    // 数据持久化 - 违反SRP
    public void saveToDatabase() {
        // 数据库保存逻辑
    }
    
    // 邮件发送 - 违反SRP
    public void sendEmail(String message) {
        // 邮件发送逻辑
    }
}

遵循SRP的设计：

// 用户数据模型
class User {
    private String name;
    private String email;
    // 只负责用户数据
}

// 用户数据访问
class UserRepository {
    public void save(User user) {
        // 数据库保存逻辑
    }
}

// 邮件服务
class EmailService {
    public void sendEmail(String email, String message) {
        // 邮件发送逻辑
    }
}

开闭原则

Open-Closed Principle (OCP)

开闭原则规定软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。这意味着当需要添加新功能时，应该通过扩展现有代码来实现，而不是修改现有代码。

实现策略：

抽象化：使用抽象类或接口定义稳定的抽象层
多态性：利用多态机制实现不同的具体实现
依赖注入：通过依赖注入降低模块间的耦合
策略模式：使用设计模式支持算法的动态切换

实践示例

遵循OCP的设计：

// 抽象的图形接口
interface Shape {
    double calculateArea();
}

// 具体实现 - 圆形
class Circle implements Shape {
    private double radius;
    
    public double calculateArea() {
        return Math.PI * radius * radius;
    }
}

// 具体实现 - 矩形
class Rectangle implements Shape {
    private double width, height;
    
    public double calculateArea() {
        return width * height;
    }
}

// 面积计算器 - 对扩展开放，对修改关闭
class AreaCalculator {
    public double calculateTotalArea(List<Shape> shapes) {
        return shapes.stream()
                    .mapToDouble(Shape::calculateArea)
                    .sum();
    }
}

依赖倒置原则

Dependency Inversion Principle (DIP)

依赖倒置原则规定高层模块不应该依赖低层模块，两者都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。这个原则有助于降低模块间的耦合度，提高系统的灵活性。

关键概念：

依赖抽象：依赖接口或抽象类，而不是具体实现
控制反转：将依赖关系的控制权交给外部容器
依赖注入：通过构造函数、setter或接口注入依赖
解耦合：减少模块间的直接依赖关系

实践示例

违反DIP的设计：

class OrderService {
    private MySQLDatabase database; // 直接依赖具体实现
    
    public OrderService() {
        this.database = new MySQLDatabase(); // 紧耦合
    }
    
    public void saveOrder(Order order) {
        database.save(order);
    }
}

遵循DIP的设计：

// 抽象接口
interface Database {
    void save(Order order);
}

// 具体实现
class MySQLDatabase implements Database {
    public void save(Order order) {
        // MySQL保存逻辑
    }
}

// 高层模块依赖抽象
class OrderService {
    private Database database;
    
    // 依赖注入
    public OrderService(Database database) {
        this.database = database;
    }
    
    public void saveOrder(Order order) {
        database.save(order);
    }
}

接口隔离原则

Interface Segregation Principle (ISP)

接口隔离原则规定客户端不应该被迫依赖它们不使用的接口。应该将大的接口拆分成更小、更具体的接口，使得客户端只需要知道它们感兴趣的方法。

设计要点：

接口细分：将大接口拆分为多个小接口
职责专一：每个接口都有明确的职责
按需实现：客户端只实现需要的接口
降低耦合：减少不必要的依赖关系

实践示例

违反ISP的设计：

// 臃肿的接口
interface Worker {
    void work();
    void eat();
    void sleep();
    void program(); // 不是所有工人都会编程
    void design();  // 不是所有工人都会设计
}

遵循ISP的设计：

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

// 生活需求接口
interface Livable {
    void eat();
    void sleep();
}

// 编程技能接口
interface Programmable {
    void program();
}

// 设计技能接口
interface Designable {
    void design();
}

// 程序员实现相关接口
class Programmer implements Workable, Livable, Programmable {
    public void work() { /* 工作逻辑 */ }
    public void eat() { /* 吃饭逻辑 */ }
    public void sleep() { /* 睡觉逻辑 */ }
    public void program() { /* 编程逻辑 */ }
}

最小知识原则

Law of Demeter (LoD)

最小知识原则，也称为迪米特法则，规定一个对象应该对其他对象有最少的了解。一个类应该只与它的直接朋友通信，不应该与陌生人说话。这有助于降低系统的耦合度。

交互规则：

直接朋友：只与直接依赖的对象交互
避免链式调用：减少对象链式调用的深度
封装交互：通过中介者模式封装复杂交互
信息隐藏：隐藏不必要的实现细节

实践示例

违反LoD的设计：

class Customer {
    public void makePayment(Order order) {
        // 违反最小知识原则 - 过多的链式调用
        double amount = order.getItems().get(0).getPrice();
        order.getPayment().getProcessor().process(amount);
    }
}

遵循LoD的设计：

class Customer {
    public void makePayment(Order order) {
        // 通过Order对象封装复杂操作
        order.processPayment();
    }
}

class Order {
    private List<Item> items;
    private Payment payment;
    
    public void processPayment() {
        double totalAmount = calculateTotal();
        payment.process(totalAmount);
    }
    
    private double calculateTotal() {
        return items.stream()
                   .mapToDouble(Item::getPrice)
                   .sum();
    }
}

DRY原则

Don't Repeat Yourself

DRY原则规定系统中的每一项知识都必须有单一、明确、权威的表示。避免重复代码不仅能减少维护成本，还能提高代码的一致性和可靠性。

实现方法：

提取公共方法：将重复的代码提取为公共方法
使用配置：将重复的配置信息集中管理
模板方法：使用模板方法模式处理相似流程
继承和组合：通过继承或组合复用代码

实践示例

违反DRY的设计：

class UserService {
    public void createUser(User user) {
        // 验证逻辑重复
        if (user.getName() == null || user.getName().isEmpty()) {
            throw new IllegalArgumentException("Name cannot be empty");
        }
        if (user.getEmail() == null || !user.getEmail().contains("@")) {
            throw new IllegalArgumentException("Invalid email");
        }
        // 保存用户
    }
    
    public void updateUser(User user) {
        // 相同的验证逻辑重复
        if (user.getName() == null || user.getName().isEmpty()) {
            throw new IllegalArgumentException("Name cannot be empty");
        }
        if (user.getEmail() == null || !user.getEmail().contains("@")) {
            throw new IllegalArgumentException("Invalid email");
        }
        // 更新用户
    }
}

遵循DRY的设计：

class UserService {
    private UserValidator validator = new UserValidator();
    
    public void createUser(User user) {
        validator.validate(user); // 复用验证逻辑
        // 保存用户
    }
    
    public void updateUser(User user) {
        validator.validate(user); // 复用验证逻辑
        // 更新用户
    }
}

class UserValidator {
    public void validate(User user) {
        validateName(user.getName());
        validateEmail(user.getEmail());
    }
    
    private void validateName(String name) {
        if (name == null || name.isEmpty()) {
            throw new IllegalArgumentException("Name cannot be empty");
        }
    }
    
    private void validateEmail(String email) {
        if (email == null || !email.contains("@")) {
            throw new IllegalArgumentException("Invalid email");
        }
    }
}

原则应用总结

这些架构设计原则不是孤立存在的，它们相互关联、相互支撑。在实际应用中，我们需要根据具体情况灵活运用这些原则，找到最适合的设计方案。

实践建议

从简单开始，逐步重构
重视代码审查和团队讨论
使用设计模式支持原则实施
持续学习和改进

平衡考虑

避免过度设计
考虑性能影响
权衡复杂度和灵活性
结合业务实际需求

持续改进

定期重构代码
监控系统质量指标
收集团队反馈
学习最佳实践

关键要点

架构设计原则是指导思想，不是绝对的规则。在实际应用中，要根据项目的具体情况、团队的技术水平和业务需求来灵活运用这些原则，追求的是整体的平衡和最优解。