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);
}

最初のケースでは、余分なメソッドを作成する必要がありません。2番目のケースでは、Personオブジェクトがそのアドレスの変更を認識できます（何らかの理由で気にかけた場合）。

ここにベストプラクティスはありますか？

4

5 に答える 5

3

私は 2 番目のアプローチを好みますが、変更不可能なセットは、クライアントでの望ましくない驚き以外にはほとんどメリットがないと考えています。

このコレクションが不変であることをクライアントに伝えたい場合は、(実装ではなく) API で可変性を保留するコレクション型を使用する必要があります。つまり、存在することが宣言されているメソッドを呼び出して UnsupportedOperationException をキャッチすることは、最初のデートをした女性のユニットを見つけるようなものです。

私は Josh Bloch が大好きですが、彼はこれを台無しにしたと思います。

于 2012-07-27T20:13:33.210 に答える
1

一般に、2 番目のアプローチの方が堅牢であると言えます。戻り値として変更不可能なセットを使用すると、部外者がPersonクラスの内部状態を変更できなくなります。クラスが自分のアドレスを論理的に所有している場合、他のユーザーはクラス メソッドを使用Personしないと変更できないはずです。Person

于 2012-07-23T03:24:15.237 に答える
0

2つのアプローチについて、良いことも悪いこともわかりません。クラスが提供する機能がすべてです。

于 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 に答える