2

プログラマーのチームが、新しいユーティリティ クラス用に提案された API を検討しています。いくつかの議論の後、機能を失うことなく API のメソッドの数を減らすことができることに気付きました。新しい設計を実装する場合、どの 2 つの OO 原則を推進しますか?

A. Looser coupling
B. Tighter coupling
C. Lower cohesion
D. Higher cohesion
E. Weaker encapsulation
F. Stronger encapsulation

誰か答えを教えてくれませんか？

4

2 に答える 2

3

私の答えは

より疎結合と より高い結束

次の質問はなぜですか？次に、この記事を読むことをお勧めします。

http://blog.sanaulla.info/2008/06/26/cohesion-and-coupling-two-oo-design-principles/

于 2011-04-12T12:19:36.837 に答える
1

まず、より強力なカプセル化です。API に存在しなくなったメソッドの 1 つ (つまり、プライベート化または削除されたメソッド) が、残りの「高レベル」メソッドを介して引き続きアクセスできる「低レベル」機能を提供するとします。それがあなたが想定すべきことだと思います。その場合、メソッドへの引数の数と型、メソッドの名前、およびその戻り値の型を自由に変更したり、メソッドを完全に削除してその機能を呼び出し元に折りたたんだりできるため、カプセル化が改善されました。 、API のクライアントに影響を与えません。

すみません、どの2つですか？クラスとそのクライアントの間の結合点が少なくなり、さまざまな方法で物事を壊す機会が少なくなるため、より疎結合も促進されます。

于 2011-04-12T12:18:43.667 に答える