为何DDD认为JavaBean是缺血模型

前端之家收集整理的这篇文章主要介绍了为何DDD认为JavaBean是缺血模型前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

JavaBean被称为anemic domain model的原因是JavaBean或者POJO完全沦为了properties bag(可以类比到C/C++里的struct)。

DDD的争论认为一个POJO然后加上一堆setter和getter根本称不上为一个Object(对象),对象是真实世界业务对象的反应。

回想刚学Java的的时候,经典的Java书籍里是不是会让你写一个CatDog类,然后继承Animal接口,他们有eatbarkshitpee等行为。

对象的意义在于封装并提供行为,而POJO的settergetter破坏了封装。
而且更糟糕的是,只提供settergetter的POJO在面对真实业务对象的时候就会显得弊端重重。

还是拿Cat做例子,比如你喂它食物,猫会的happy指数会提高,饥饿感会下降,对主人的忠诚度也会提高,在DDD里,我们只要这样写就OK了:cat.Feed(food),如果是POJO的话就会变成:

cat.setHappiness(..);
cat.setLoyalty(..);
cat.setHunger(..)

而且POJO是违反SRP原则的(如果要修改一个类,那么指应该是它的职责发生变化,而不应该是其他)。

如果项目经理某天告诉你,猫被喂食后还要增加毛色的光泽度,如果是DDD设计的,我们只需要修改Cat.Feed的实现就行了。

而如果是POJO的话,那么我们要在所有原来cat.setHappiness(..),cat.setLoyalty(..),cat.setHunger(..)的地方添加一个cat.set毛色光泽度(..)

你可能会争论,我可以把Feed的业务逻辑写在Service里嘛,但是这就违反了OOD(对象是数据的封装和行为的组合),

而且因为你已经暴露了settergetter,那么程序员必定会绕过你的Service,这样对系统来说也就增加了混乱。

可以看Martin Fowler的这篇文章 AnemicDomainModel

原文链接:https://www.f2er.com/javaschema/283760.html

猜你在找的设计模式相关文章