0

クラスA（空でない場合、リストを出力するもの）：

private List<int> _myList = new List<int>
public List<int> MyList {get{return _myList;} set{_myList = value;}}

クラス B:

public bool MyClassBMethod(stuff)
{
     //stuff
     try{
          something
     }
     catch(Exception){
         ClassA.MyList.Add(stuff);
         return false;
     }
     return true;
}

リストの編集はこの悪い習慣のようですか? それとも大丈夫ですか？

編集：メソッドが何か他のもの（bool、object、stringなど）を返す必要がある場合にのみ、リストに追加しています。

4

5 に答える 5

2

通常はそうすべきではありません。

クラスのクライアントに非常に大きなインターフェイスを公開しているため、すべての状況でクラスが機能することをテストすることが難しくなっています。予期しないときに誰かが値を削除した場合はどうなりますか? または、範囲外の値を追加するとどうなりますか? でメソッドを呼び出した時点で検証することはできないListため、後でクラスが突然壊れて、悪いデータの出所を追跡するのが困難になる可能性があります。

Addクラスにリストの を呼び出すメソッドをAdd用意し、リストを非公開にしておくことをお勧めします。次に、クライアントの動作を制御し、クライアントが使用する必要がある (およびテスト済みの) 機能のみを公開できます。

于 2012-05-22T20:43:43.820 に答える
2

一般に、クラスは自身の内部状態の管理を担当する必要があります。このようにメンバーに完全なパブリック アクセスを許可することで、基本的にはクラス A がその状態のその部分の責任を放棄していると言っています。_myList に何が含まれているかを推測することはできません。これは、誰でもいつでも変更できるためです。

それが良いかどうかはあなたの意図次第ですが、デカップリングとカプセル化の考え方に反することは確かです。繰り返しますが、デカップリングとカプセル化が必要かどうかはあなた次第です。

より良い質問は、クラス A と B の間のどのようなデカップリングが設計にとって最も有益であるかを判断することです。その後、どのメンバーをどのように公開するかを決定できます。

于 2012-05-22T20:47:31.557 に答える
0

これはかなり一般的な方法です。それほど一般的ではないのは、セットを公開することです。それを非公開にし、A コンストラクターのリストを初期化すれば、準備は完了です。

public ObservableCollection<int> MyPublicList {get; private set;}

WPF は、このような宣言でいっぱいです。

于 2012-05-22T20:43:35.433 に答える
0

いつものように、それは依存します。リストがクラス外で編集されることを意図しており (それはそのクラスのインターフェースの一部です)、通常のリスト操作がすべて許可されている場合は、問題ありません。操作のサブセットのみが許可されている場合は、このように使用しないでください。すべての制約を適用するカスタム リスト (またはリストのラッパー) を使用してください。たとえば、クラス外でリストを読み取り専用にする必要がある場合は、クラス外でReadOnlyCollectionラッパーを提供できます。それはすべて、データの整合性を強化することに帰着します。

于 2012-05-22T20:49:08.507 に答える
0

リストが公開されているかどうかを気にするかどうかによって異なります。public の具象型を公開してアクセスすることで、実装の詳細を公開し、クラスとそのコンシューマー間の結合を増やします。ClassAまた、実装の詳細が適切にカプセル化されていないため、データの一貫性を強制する の機会を制限しています。

これは完全に受け入れられる場合もあれば、そうでない場合もあります。

オブジェクト モデルがばかげている場合は、許容できると思います。ばかげて、それはただのデータを含んでいるということです。このような状況は、JSON / XML をオブジェクトに解析するときによく発生します。物事はデータをミラーリングするように構造化されており、データがほとんどないため、動作はそれほど重要ではありません。また、小さなコードベースをハッキングするだけである場合、および/または変更の範囲が限られている場合、または関連する動作がほとんどない場合にも、より受け入れられます。

普段は避けてますけどね。

まず、 のリストに追加するアイテムはClassA素数でなければならないと想像してください。メソッドを作成すれば、このチェックを簡単に実施できますがAddItem()、リストが公開されている場合は、効果的に行うのがはるかに難しくなります。

次に、リストを辞書に変更することにしたとします。以前ClassBはClassA. AddItem()代わりに、 for と呼ばれるandRemoveItem()または類似のメソッドを作成した場合、内部実装が Set、Dictionary、または List などであるかどうかは気にせず、変更が行われたときに壊れることもありませんClassA。ClassB

「物事に点を入れる」( のような) に関するガイドラインには、「デメテルの法則blah.List[3].GetProduct(3).Reviews.First()」という名前があります。

デメテルの法則の重要なポイントは次のとおりです。

基本的な概念は、特定のオブジェクトが他のもの (サブコンポーネントを含む) の構造またはプロパティについて可能な限り想定しないようにすることです。

より多くのコードを書かなければならないこともよくありますが、それは変更を防ぎます。

于 2012-05-22T20:53:15.187 に答える