充血模型和贫血模型

Posted 2024-09-27 Updated 2024-09- 27

By 随风

12~16 min read

在软件设计中，充血模型（Rich Model）和贫血模型（Anemic Model）是两种关于对象模型设计的概念，主要与面向对象设计中业务逻辑和数据的分布有关。

1. 充血模型（Rich Model）

定义：

充血模型是一种领域驱动设计（DDD）的对象建模方式，在这种模型中，对象不仅包含数据，还包含与数据相关的业务逻辑。也就是说，类不仅仅存储属性，还包含行为（方法）来操作这些属性。

特点：

封装性强：对象的状态（属性）和行为（方法）被很好地封装在一起。
对象自治：对象可以自主执行与其状态相关的操作，业务逻辑与数据存储在同一个类中。
更符合面向对象的设计思想：将数据与操作数据的逻辑结合起来。

示例：

public class BankAccount {
    private double balance;

    public BankAccount(double initialBalance) {
        this.balance = initialBalance;
    }

    // 行为：存款
    public void deposit(double amount) {
        if (amount > 0) {
            this.balance += amount;
        } else {
            throw new IllegalArgumentException("Deposit amount must be positive");
        }
    }

    // 行为：取款
    public void withdraw(double amount) {
        if (amount > 0 && this.balance >= amount) {
            this.balance -= amount;
        } else {
            throw new IllegalArgumentException("Insufficient balance or invalid amount");
        }
    }

    public double getBalance() {
        return this.balance;
    }
}

在这个例子中，BankAccount 类不仅包含账户余额，还定义了存款和取款操作，将数据和业务逻辑封装在同一个类中。

优点：

高内聚：对象封装了与其相关的操作和状态，业务逻辑与数据紧密结合。
符合面向对象的原则：充血模型遵循面向对象设计的封装、继承和多态特性。
易维护：业务逻辑的修改集中在领域对象内部，便于维护和测试。
可扩展性强：对象能够根据需要扩展其行为和状态，便于代码的扩展和演化。

缺点：

复杂度增加：随着业务逻辑的增加，领域对象可能变得复杂，容易导致难以维护的大型类。
单一职责原则（SRP）问题：如果对象需要处理过多的业务逻辑，可能违反单一职责原则，变成“上帝对象”（God Object）。

2. 贫血模型（Anemic Model）

定义：

贫血模型是一种对象建模方式，在这种模型中，对象只包含数据（即属性），而不包含与数据相关的业务逻辑。所有的业务逻辑被放在服务层或其他专门的业务逻辑层中，这种模型的对象通常被称为领域对象或数据传输对象（DTO）。

特点：

数据与逻辑分离：对象只包含数据，业务逻辑由外部的服务类或业务逻辑类来处理。
行为外部化：操作数据的逻辑被外部类承担，领域对象本身没有行为。

示例：

public class BankAccount {
    private double balance;

    public BankAccount(double balance) {
        this.balance = balance;
    }

    public double getBalance() {
        return this.balance;
    }

    public void setBalance(double balance) {
        this.balance = balance;
    }
}

// 业务逻辑由服务类处理
public class BankAccountService {
    public void deposit(BankAccount account, double amount) {
        if (amount > 0) {
            account.setBalance(account.getBalance() + amount);
        } else {
            throw new IllegalArgumentException("Deposit amount must be positive");
        }
    }

    public void withdraw(BankAccount account, double amount) {
        if (amount > 0 && account.getBalance() >= amount) {
            account.setBalance(account.getBalance() - amount);
        } else {
            throw new IllegalArgumentException("Insufficient balance or invalid amount");
        }
    }
}

在这个例子中，BankAccount 只包含数据，而存款和取款操作则由 BankAccountService 类处理。

优点：

单一职责原则（SRP）：贫血模型中的对象只负责存储数据，业务逻辑被分离到服务层，符合单一职责原则。
清晰的业务逻辑分层：逻辑与数据分离，有助于建立更加明确的服务层，业务逻辑集中在服务类中，代码更具可读性。
简单易理解：贫血模型更为简单直观，容易理解和实现。

缺点：

面向对象原则的违背：贫血模型违反了面向对象设计的封装和自治原则，导致对象不再具有自主性。
逻辑分散：业务逻辑与数据对象分离，可能导致维护困难，尤其是在复杂系统中，服务类的逻辑可能变得冗长。
测试困难：业务逻辑与数据分离，使得单元测试可能更加困难，因为对象本身不包含行为，所有操作都依赖服务类。

3. 充血模型 vs 贫血模型：对比总结

4. 选择何种模型

充血模型 适合在领域驱动设计（DDD）中使用，特别是在复杂业务场景下，充血模型有助于将业务逻辑与数据封装在一起，保持业务的一致性和自治性。
贫血模型 更适合简单业务逻辑，或者需要清晰分层的系统设计。它通常出现在三层架构或服务导向架构（SOA）中。

综上，充血模型更符合面向对象的设计思想，但可能带来更复杂的实现；而贫血模型实现简单，但会将业务逻辑与数据分离，偏向于过程化编程的风格。选择使用哪种模型，应根据系统的复杂度、可维护性和业务需求综合考虑。

其他

License: CC BY 4.0