具体例子说明为什么“贫血领域模型”如此重要被认为是反模式

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

想要改进这个问题吗？通过编辑这篇文章来更新问题，使其仅关注一个问题。

7 年前已关闭。

Answer 1

Martin Fowler 给这个行业带来的说法很多，但理解却很少。

当今的大多数应用程序（web/db）确实需要许多公开其属性的对象。

任何不赞成这种做法的权威（自称）都应该以身作则，向我们展示一个成功的现实世界应用，其中充满了他的奇妙原理的体现。

不然就闭嘴。令人作呕的是，我们这个行业存在如此多的热议。这是工程，不是戏剧俱乐部。

Answer 2

有关完整的答案，请查看我的博客，其中还包含源代码示例 [博客]：https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/

如果您查看这从面向对象的角度来看，贫血领域模型绝对是一种反模式，因为它是纯粹的过程编程。
它被称为反模式的原因是贫血领域模型没有涵盖主要的面向对象原则：

面向对象意味着：对象管理它的状态并保证它在任何时候都处于合法的状态。 （数据隐藏、封装）

因此，对象封装数据并管理数据的访问和解释。
与此相反，贫血模型并不能保证它在任何时候都处于合法状态。

包含订单项目的订单示例将有助于显示差异。
那么让我们看一下订单的贫乏模型。

贫血模型

 public class Order {
    private BigDecimal total = BigDecimal.ZERO;
    private List<OrderItem> items = new ArrayList<OrderItem>();

    public BigDecimal getTotal() {
        return total;
    }

    public void setTotal(BigDecimal total) {
        this.total = total;
    }

    public List<OrderItem> getItems() {
        return items;
    }

    public void setItems(List<OrderItem> items) {
        this.items = items;
    }
}

public class OrderItem {

    private BigDecimal price = BigDecimal.ZERO;
    private int quantity;
    private String name;
    
    public BigDecimal getPrice() {
        return price;
    }

    public void setPrice(BigDecimal price) {
        this.price = price;
    }

    public int getQuantity() {
        return quantity;
    }

    public void setQuantity(int quantity) {
        this.quantity = quantity;
    }
}

那么，解释订单和订单项以计算订单总额的逻辑在哪里呢？
此逻辑通常放置在名为 *Helper、*Util、*Manager 或简称为 *Service 的类中。
贫血模型中的订单服务如下所示：

public class OrderService {
    public void calculateTotal(Order order) {
        if (order == null) {
             throw new IllegalArgumentException("order must not be null");
        }

        BigDecimal total = BigDecimal.ZERO;
        List<OrderItem> items = order.getItems();

        for (OrderItem orderItem : items) {
            int quantity = orderItem.getQuantity();
            BigDecimal price = orderItem.getPrice();
            BigDecimal itemTotal = price.multiply(new BigDecimal(quantity));
            total = total.add(itemTotal);
        }
        order.setTotal(total);
    }
}

在贫血模型中，您调用一个方法并将贫血模型传递给它，以使贫血模型进入合法状态。因此，贫血模型的状态管理被置于贫血模型之外，这一事实使其从面向对象的角度来看是一种反模式。

有时您会看到稍微不同的服务实现，但它不会修改贫乏的模型。相反，它返回它计算的值。例如，

public BigDecimal calculateTotal(Order order); 

在本例中，Order 没有属性total。如果您现在使 Order 不可变，那么您就踏上了函数式编程的道路。但这是另一个我在这里无法发现的话题。

上述贫乏订单模型的问题是：

• 如果有人将 OrderItem 添加到 Order 中，只要 OrderService 没有重新计算，Order.getTotal() 值就是不正确的。在现实世界的应用程序中，找出谁添加了订单项以及为什么 OrderService 未被调用可能很麻烦。正如您可能已经认识到的那样，订单还打破了订单项目列表的封装。有人可以调用 order.getItems().add(orderItem) 来添加订单项。这可能会导致很难找到真正添加项目的代码（order.getItems() 引用可以通过整个应用程序传递）。
• OrderService 的 calculateTotal 方法负责计算所有 Order 对象的总计。因此它必须是无状态的。但无状态也意味着它不能缓存总值，只有在 Order 对象发生变化时才重新计算。因此，如果calculateTotal 方法需要很长时间，那么您还会遇到性能问题。尽管如此，您还是会遇到性能问题，因为客户可能不知道订单是否处于合法状态，因此即使不需要，也会预防性地调用 calculateTotal(..) 。

有时您还会看到服务不会更新贫血模型，而只是返回结果。例如

public class OrderService {
    public BigDecimal calculateTotal(Order order) {
        if (order == null) {
             throw new IllegalArgumentException("order must not be null");
        }

        BigDecimal total = BigDecimal.ZERO;
        List<OrderItem> items = order.getItems();

        for (OrderItem orderItem : items) {
            int quantity = orderItem.getQuantity();
            BigDecimal price = orderItem.getPrice();
            BigDecimal itemTotal = price.multiply(new BigDecimal(quantity));
            total = total.add(itemTotal);
        }
       return total;
    }
}

，在这种情况下，服务有时会解释贫血模型的状态，并且不会用结果更新贫血模型。这种方法的唯一好处是贫血模型不能包含无效的 total 状态，因为它没有 total 属性。但这也意味着每次需要时都必须计算total。通过删除 total 属性，您可以引导开发人员使用该服务，而不是依赖 total 的属性状态。但这并不能保证开发人员以某种方式缓存total值，因此他们也可能使用过时的值。每当一个属性从另一个属性派生时，就可以采用这种实现服务的方式。或者换句话说......当你解释基本数据时。例如int getAge(日期生日)。

现在看一下富域模型，看看其中的差异。

富域方法

public class Order {

    private BigDecimal total;
    private List<OrderItem> items = new ArrayList<OrderItem>();

    /**
      * The total is defined as the sum of all {@link OrderItem#getTotal()}.
      *
      * @return the total of this {@link Order}.
      */
    public BigDecimal getTotal() {
        if (total == null) {
           /*
            * we have to calculate the total and remember the result
            */
           BigDecimal orderItemTotal = BigDecimal.ZERO;
           List<OrderItem> items = getItems();

           for (OrderItem orderItem : items) {
               BigDecimal itemTotal = orderItem.getTotal();
               /*
                * add the total of an OrderItem to our total.
                */
               orderItemTotal = orderItemTotal.add(itemTotal);
           }

           this.total = orderItemTotal;
           }
        return total;
        }

   /**
    * Adds the {@link OrderItem} to this {@link Order}.
    *
    * @param orderItem
    *            the {@link OrderItem} to add. Must not be null.
    */
    public void addItem(OrderItem orderItem) {
        if (orderItem == null) {
            throw new IllegalArgumentException("orderItem must not be null");
        }
        if (this.items.add(orderItem)) {
           /*
            * the list of order items changed so we reset the total field to
            * let getTotal re-calculate the total.
            */ 
            this.total = null;
        }
    }

    /**
      *
      * @return the {@link OrderItem} that belong to this {@link Order}. Clients
      *         may not modify the returned {@link List}. Use
      *         {@link #addItem(OrderItem)} instead.
      */
    public List<OrderItem> getItems() {
       /*
        * we wrap our items to prevent clients from manipulating our internal
        * state.
        */
        return Collections.unmodifiableList(items);
    }

}

public class OrderItem {

    private BigDecimal price;

    private int quantity;

    private String name = "no name";

    public OrderItem(BigDecimal price, int quantity, String name) {
     if (price == null) {
      throw new IllegalArgumentException("price must not be null");
     }
     if (name == null) {
      throw new IllegalArgumentException("name must not be null");
     }
     if (price.compareTo(BigDecimal.ZERO) < 0) {
      throw new IllegalArgumentException(
        "price must be a positive big decimal");
     }
     if (quantity < 1) {
      throw new IllegalArgumentException("quantity must be 1 or greater");
     }
     this.price = price;
     this.quantity = quantity;
     this.name = name;
    }

    public BigDecimal getPrice() {
     return price;
    }

    public int getQuantity() {
     return quantity;
    }

    public String getName() {
     return name;
    }

    /**
      * The total is defined as the {@link #getPrice()} multiplied with the
      * {@link #getQuantity()}.
      *
      * @return
      */
    public BigDecimal getTotal() {
     int quantity = getQuantity();
      BigDecimal price = getPrice();
      BigDecimal total = price.multiply(new BigDecimal(quantity));
     return total;
    }
}

富域模型尊重面向对象的原则并保证它在任何时候都处于合法状态。

参考

• 博客：https://www .link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/
• 来源：https://github.com/link-intersystems/blog /tree/master/anemic-vs-rich-domain-model

Answer 3

出色地。你是对的，几乎所有的java代码都是这样写的。它是反模式的原因是面向对象设计的主要原则之一是将数据和对其进行操作的函数组合成单个对象。例如，当我编写旧式 C 代码时，我们会像这样模仿面向对象的设计：

struct SomeStruct {
    int x;
    float y;
};

void some_op_i(SomeStruct* s, int x) {
    // do something
}
void some_op_f(SomeStruct* s, float y) {
    // something else
}

也就是说，该语言不允许我们组合函数来对结构内部的 SomeStruct 进行操作，因此我们创建了一个组按照惯例，将 SomeStruct 作为第一个参数的自由函数。

当 C++ 出现时，结构体变成了类，并且它允许您将函数放入结构体（类）中。然后，结构体作为 this 指针隐式传递，因此您无需创建结构体并将其传递给函数，而是创建类并针对它调用方法。这样代码就更清晰，更容易理解。

然后我转到了java世界，大家把模型和服务分开了，也就是说模型是一个美化的结构体，而服务本身是无状态的，变成了操作模型的函数集合。对我来说，这听起来很像 ac 语言习语。这很有趣，因为在 c 中这样做是因为该语言没有提供更好的东西，而在 java 中这样做是因为程序员不知道更好的东西。

Answer 4

给定以下两个类：

class CalculatorBean  
{  
    //getters and setters  
}  

class CalculatorBeanService  
{  
   Number calculate(Number first, Number second);  
    {  
       //do calculation  
    }  
} 

如果我理解正确，Fowler 指出，因为您的 CalculatorBean 只是一堆 getter/setter，所以您不会从中获得任何实际价值，并且如果您将该对象移植到另一个系统它什么也不做。问题似乎是您的 CalculatorBeanService 包含了 CalculatorBean 应该负责的所有内容。这不是最好的，因为现在 CalculatorBean 将其所有责任委托给 CalculatorBeanService

Answer 5

它只是违反了“告诉，不要问”原则，该原则规定对象应该告诉客户端它们可以做什么或不能做什么，而不是公开属性并让客户端来确定对象是否处于特定状态以进行给定的操作。

Answer 6

与软件开发世界中的大多数事情一样，没有黑白分明。在某些情况下，贫血域模型是完美的选择。

但在很多情况下，开发人员尝试构建域模型（又名 DDD），但最终却陷入贫乏的域模式。我认为在这种情况下，贫血域模型被认为是一种反模式。

只要确保您使用最适合您的工作的工具即可，如果它适合您，则无需更换它。