4

在锻炼你的 DDD 技能时，假设你有这样的对象：

class Person {
    Set<Address> addresses = new HashSet<Address>();
}

允许正常/完全访问集合是否更合适：

Set<Address> getAddresses() {
    return addresses;
}

这将允许调用者添加/删除他们认为合适的地址，或者，在这种情况下让调用者通过 Person 对象更好：

Set<Address> getAddresses() {
    return Collections.unmodifiableSet(addresses);
}

void addAddress(Address address) {
    addresses.add(address);
}

void removeAddress(Address address) {
    addresses.remove(address);
}

第一种情况使我们免于创建额外的方法；第二种情况允许 Person 对象知道其地址的更改（以防它出于某种原因关心）。

这里有最佳实践吗？

4

5 回答 5

3

我更喜欢第二种方法，但我相信不可修改的集合除了给客户带来不受欢迎的惊喜外，几乎不会给你带来什么好处。

如果您希望向客户端传达此集合是不可变的，那么您应该使用在其 API（而不是其实现）中保留可变性的集合类型。也就是说，调用一个声明存在的方法并捕获 UnsupportedOperationException 就像在与您第一次约会的女人身上找到一个单位。

我爱乔什·布洛赫，但我认为他在这件事上搞砸了。

于 2012-07-27T20:13:33.210 回答
1

我会说，总的来说，第二种方法更稳健。使用不可修改的集合作为返回值可以防止外人改变Person类的内部状态。如果Person类在逻辑上拥有它们的地址，那么其他人不应该通过Person类方法来进行更改。

于 2012-07-23T03:24:15.237 回答
0

我看不出这两种方法的好坏。这完全取决于您的班级愿意提供什么功能。

于 2012-07-23T03:23:11.460 回答
0

这一切都取决于您的要求。如果有充分的理由让底层集合远离类的客户，那么你就这样做。否则，提供 set/get 方法通常没有缺点。

于 2012-07-23T03:25:24.237 回答
0

无论哪种方式都可以，但为了清楚起见，我会根据返回的集合是否可变来命名这些方法：

Set<Address> getAddresses() {
    return Collections.unmodifiableSet(addresses);
}

Set<Address> addresses() {
    return addresses;
}
于 2012-07-23T03:30:20.180 回答