10

私は現在、いくつかの API 設計作業を行っており、後でさまざまな具体的なクラスによって実装される抽象化としての多数のインターフェイスの仕様が含まれます。

たまたま私は Java を使用していますが、この質問は、同様のインターフェイスの概念をサポートする言語に関係があると思います。

多くの場合、次のオプションがあることに気付きました。

  • さまざまなメソッドを備えた大規模なインターフェイスを作成する
  • それぞれが全範囲のメソッドのサブセットを含む複数のインターフェイスを作成する (単一の具体的なクラスは、おそらくこれらのインターフェイスのいくつかまたはすべてを実装する必要があります)

各アプローチの長所/短所は何ですか?

4

7 に答える 7

4

アンチパターンに関して言えば、インターフェイスが多すぎると、いわゆるヨーヨー問題が発生する可能性があります。

http://en.wikipedia.org/wiki/ヨーヨーの問題

そして、すべてを単一のインターフェイスに配置すると、神オブジェクトが作成される場合があります。

http://en.wikipedia.org/wiki/God_object

あなたはその間のどこかにあなたの場所を見つけるべきです:)

幸運を！

于 2011-01-21T14:40:23.647 に答える
4

インターフェースを分割する利点は、メソッドを一緒にする意味のある責任のグループに分割できることです。短所は、インターフェイスが、1 つのクラスが実装している可能性のある一連の小さなインターフェイスに分割されていることです。

インターフェースを読みやすくするために分割することをお勧めします。10 個のインターフェイスを実装している 1 つのクラスがある場合、それらのインターフェイスを 1 つに結合する必要があるか、またはおそらくそのクラスが多くの責任を負い、実際には 2 つ以上のクラスにする必要があります。

于 2011-01-21T14:34:05.787 に答える
4

まだ言及されていない問題が 1 つあります。アイテムをコレクションに入れるインターフェイスは、アイテムを取り出すインターフェイスとは別にする必要があります。結合されたインターフェースは両方から継承する必要があります。このようにインターフェイスを分離すると、共分散と反分散が可能になります。たとえば、 ReadableBunch(Of ToyotaPrius) は、 ReadableBunch(Of Car) を期待するルーチンに安全に渡すことができます [ToyotaPrius のインスタンスを提供するオブジェクトは、そうすることで Car のインスタンスを提供するため] と、 WritableQueue(Of Car ) は、WriteableQueue(Of HondaCivic) を期待するルーチンに安全に渡すことができます [Car を受け入れることができるオブジェクトは、定義により HondaCivic を受け入れるため]。

このタイプの共分散と反分散が Java で何かを意味するかどうかはわかりませんが、質問に言語に依存しないというタグが付けられているため、共分散と反分散をサポートするプラットフォーム (.net など) のコーディングを行う人は、この問題を考慮する必要があります。

于 2011-01-24T18:10:24.763 に答える
2

クラスと同様に、メソッドが多すぎるインターフェイスも推奨しません。そのようなインターフェイスまたは派生クラスを使用する必要があるプログラマーは、それらがどのように関連しているかを理解するのに苦労するでしょう。さらに、それらが何であるか、いつ使用するかを覚えようとすることは、あまりにも多くのボールをジャグリングするようなものです.

私にとって、一般的に、1 つのモジュールに 1000 行を超える行は多すぎます。メソッドでも100行以上。クラスまたはインターフェースにも15個以上のメソッドがあります。もちろん例外もあるかもしれませんが、私はそれらを避けるようにしています。

どのメソッドがそれらに入るかを考える前に、どのインターフェイスを持っているかを定義します。システム内の各抽象エンティティの「アトミック ビヘイビア」とは何かを検討し、必要に応じて継承を組み合わせて、各エンティティをインターフェイスにします。次に、メソッドを決定します。その後、各インターフェイスにはおそらく多くはありません。

于 2011-01-21T14:33:03.523 に答える
2

それぞれが全範囲のメソッドのサブセットを含む複数のインターフェイスを作成する

このアプローチは、「継承よりも構成を優先する」という設計原則でうまく機能する傾向があります。これは、個別のクラスがそれぞれ 1 つ (またはいくつか) のインターフェイスを実装できるためです。

于 2011-01-21T14:38:59.100 に答える
2

あなたの質問に対する適切な答えはありません。API の設計はちょっとした芸術です。大規模な設計作業を行っている場合は、NetBeans で有名な Jaroslav Tulach によるPractical API Designのコピーを入手することをお勧めします。

彼はあまりにも多くのメソッドに対して推奨すると思いますが、そのうちのいくつかは単なるヘルパーメソッドかもしれません. API を操作するために最低限必要なものを公開する必要があります。冗長であるほど良いです。

于 2011-01-21T15:39:51.793 に答える
2

インターフェイス内のメソッドの数は、既知の (または予想される) 使用方法によってのみ決定する必要があります。呼び出し元が通常、インターフェイスの 6 つのメンバーのうち 3 つの異なる (ただし重複する) メンバーを使用する場合、それは 6 つです!

多くの場合、メソッドの数が多いということはまとまりが悪いことを示しており、オブジェクトを適切に設計する場合は、とにかくその数に自然な制限を設ける必要があります。ただし、含まれるメソッドの数を減らすためだけにインターフェイスを分割するべきではありません。

于 2011-01-21T15:56:27.300 に答える