<分区>
在我的项目的业务逻辑中，我主要有“值对象” 和“经理”
值对象无处不在。它们可以是用户、汽车、照片、相册等。
管理者的存在是为了控制他们的值(value)对象。可以是UserManager、CarManager、PhotoManager、AlbumManager等。他们使用值对象创建/删除/getList 和其他操作。
现在我面临的问题是:我的值对象是否应该包含 setter？ 我的第一个意见是不，因为我认为值对象状态只由他的经理控制会更好。
但也有不好的一面 - 代码重复和明显的双重工作。
如果没有 setter，我的经理将拥有像 userManager.addPhoto(userToAddTo, photoToBeAdded) 这样的方法，它在内部调用 user.addPhoto(photo)(方法 addPhoto 存在于实现中，但不存在于接口(interface)中)。如果只有几个这样的方法还好，但是当它得到很多这样的“setter”方法时，管理器似乎有点难看，而且显然是双重工作。
那么，我是否应该在我的值对象中使用 setter？
最佳答案
我会说"is"，我也会避免像 userManager.addPhoto( userToAddTo, photoToBeAdded ) 这样的事情，而转向更丰富的域模型，如 user.addPhoto( photo )。
我认为大多数 OOD 设计社区都倾向于“继续为属性添加 setter 和 getter”。当然，有些纯粹主义者认为您应该一次只管理完整的状态，但这是不切实际的。
如果你看一下 C# 或 Groovy 这样的语言，它们已经使 getter 和 setter 的想法有些过时，依赖于各种机制来简单地处理直接可分配/可读的属性，并允许一些“底层”方法hood' 添加获取/设置逻辑:
class Person {
String name
String lastname
// for some dumb reason, always 'get' upper-cased last names
String getLastname() {
return this.lastname.toUpperCase()
}
}
总而言之，我赞成 OO 设计，其中对象代表状态业务逻辑，而不是像数据库表中的一行那样简单状态的贫血反射(reflect)。
我还会考虑问问自己，为什么一开始就使用简单/愚蠢的值对象。是否需要它们，例如通过电线跨越系统边界？
关于java - 面向对象的设计——我的值(value)对象应该只包含 setter/getter 吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20997235/