域驱动设计 – DDD和Getters and Setters的使用

前端之家收集整理的这篇文章主要介绍了域驱动设计 – DDD和Getters and Setters的使用前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我已经阅读了一些关于Getters和Setter使用的文章/帖子,以及它们如何帮助破解域模型对象中封装的目的.我理解不使用setter的逻辑 – 你允许客户端代码在对象业务规则和不变量的上下文之外操纵该对象的属性.

现在这位校长仍然困惑我.例如,如果我需要更改对象的成员变量的值,会发生什么?例如,如果某个人的姓名发生变化,我该如何在模型中反映出来?起初我想,为什么没有一个名为’ChangeName’的函数,让我传入新名称,然后它可以改变内部’name’变量.嗯….这只是一个二传手不是它!

我需要澄清的是 – 如果我要完全消除setter,那么在上述情况下,我应该完全依赖构造函数参数吗?我应该通过构造函数传递新的属性值来代替旧的属性值,之后我可以通过将对象传递给我拥有的任何持久性基础架构来持久化更改吗?

这两篇文章在这个讨论中很有用:

> http://kellabyte.com/tag/ddd/
> http://typicalprogrammer.com/?p=23

嗯,这是一个经典的讨论. Stack Overflow中还有其他一些关于此的线程.

但.获取/设置(自动属性?)并不全是坏事.但它们倾向于使您将实体构建为“死”数据容器,只有prop而不是方法.这种情况通常被称为贫血领域 – 而且行为很少.我的建议是:

>尝试尽可能少地使用道具.
>尝试查找属于一起的数据组,应该是
像前一样.名字中间名和姓氏.另一个例子
是Zipcode,City,Street.这些数据最好通过a设置
方法.它可以最大限度地减少您的实体无效的可能性.
>通常,属于一起的数据可以归为一个值
宾语.
>更多Value对象倾向于带出更多描述性方法
你的实体是“动词”,而不是你通常的“名词”
实体.
>还可以使用更多方法为您的值对象添加更多内容
行为,也许减少你的“胖”服务(也许你没有
有太多泄露的业务逻辑的服务…).

这里还有更多要说的……但简短的回答.关于在构造函数中设置数据:如果没有该数据,此实体无法“生存”/存在,我只会这样做.对于实体人我会说Name可能不是那么重要.但社会安全号码可能是构造函数数据的候选者.或者实体员工必须在构造函数中拥有公司,仅仅因为员工必须属于公司.

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

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