10

オーバーインターフェースは可能ですか？今システムを設計するときは、インターフェイスから始めて、適切に機能するパターンができるまで、インターフェイスに沿って単体テストを段階的に記述します.いくつかの具象クラスの記述に移り、これらに対して単体テストを設定します..

現在、私はインターフェースを愛する人です。一般的に、コードを制御するときに、プリミティブまたはインターフェースを渡す/返すだけになります..これまでのところ、これが理想的であることがわかりました.一般的にシステムを簡単に適応させて強化することができます.依存システムに影響を与えることなく。

インターフェイスを使用する理由を売り込む必要はないことは明らかですが、すべてをインターフェイスするのはやり過ぎなのかと思っています。次のようなクレイジーなもののように、空のインターフェイスについて話しているのではありません。

interface IStringCollection : ICollection<string>
{
}

私はもっ​​と次のような話をしています：

interface ISomethingProvider
{
  ISomething Provide(ISomethingOptions options);
}

これは本当にやり過ぎですか？私の推論は、どのタイプもある時点でインターフェイスから利益を得る可能性があるということです..そして私が抱えていた唯一の本当の問題は、クラスを設計するためのより良い方法であると私が考えるものを学ばなければならなかったことです.インタラクションと「ハッキング」が進行中です。

これが時限爆弾であるかどうか、またインターフェースを使用するかどうかについてのフィードバックをお待ちしています..

ps-これは、インターフェイスの書き方についてはあまり重要ではありません。

4

10 に答える 10

5

インターフェイスは、動作のコントラクトを記述します。動作パターンに従ってオブジェクトのセットに対処する必要がある場合は、インターフェイスが役立ちますが、オブジェクトの構造を単純に説明している場合はそれほど役に立ちません。動作に関連するオブジェクトを作成するファクトリを使用したり、ライブラリの一部の動作コントラクトを確立したりするなど、それらを使用する正当な理由が必要だと思います。インターフェイスを意図せずに使用すると、ライブラリの読み取り/理解/保守が困難になる可能性があります。

于 2008-09-21T22:43:39.210 に答える
5

要するに、プロジェクトをオーバーインターフェースすることは可能です。状況が実際に抽象基本クラスとインターフェースを必要とする場合を考慮してください。どちらも似ていますが、両方を使用することには明確な利点がありますここを参照. 通常、私は、実際には抽象基本クラスを使用する必要があるときに、人々がインターフェイスを使用していることに気付きました。オブジェクト指向の観点からすると、インターフェイスは、非常に異なるクラスにまたがる可能性のある共通の動作をリストするために使用する必要があります。たとえば、Move() というメソッドを持つ IMove インターフェイスがあるとします。飛行機、車、人、昆虫のクラスがあるとします。Airplane と Car は抽象 Vehicle クラスから継承する場合がありますが、それでも IMove を使用する必要があり、Insect と Person も同様ですが、Move の実装はすべて異なります。私自身も含めて、人々はインターフェイスを使用してクラスを「グループ化」する傾向があることに気付きましたが、実際には基本クラスで処理する必要があります。

于 2008-09-21T22:59:27.643 に答える
4

他のものと同様に、適度に、必要に応じて使用します。「必要ですか？」と自問してみてください。

于 2008-09-21T22:39:42.150 に答える
3

オーバーインターフェースする可能性があります。私が働いているルールは、アプリケーションにインターフェースがある場合、それを実装するクラスが少なくとも2つ必要であるということです（または、近い将来、実装クラスを追加することを合理的に期待しています）。

テスト用のモックオブジェクトを作成する必要がある場合は、モッククラスと実際のクラスに共通のインターフェイスを実装させることが、インターフェイスを使用する正当な理由です。

アプリケーションのすべてにインターフェースを自動的に使用することはお勧めしません。特に、必要に応じて1つのクラスをインターフェースに簡単にリファクタリングできるためです。

于 2008-09-21T23:28:31.317 に答える
2

誰かがこれを言っているのを見たり聞いたりするたびに

インターフェイスは動作の契約を記述します

インターフェイスを理解していない人を見つけたことは知っています。

インターフェイスはそれを行うことができません。それは無理だ。インターフェイスは、動作を規定したり、強制したり、何らかの方法で制約したりすることはありません。

インターフェースはインターフェースのコントラクトを記述するため、名前が付けられました。彼らには行動がありません。

インターフェイスのメソッドに付ける名前が、それを実装する人にとって必要な動作を暗示していることを期待するかもしれませんが、そうしなければならないという要件はありません。行動の契約はありませんし、存在することもできません。

特定の種類の動作が必要な場合は、クラスを使用してそれを強制する必要があります (たとえば、テンプレート パターンを使用) - それがすべての動作です。

インターフェースは設計構造として定期的に悪用されていますが、その理由の 1 つは、この誤謬が広く信じられているためです。

于 2009-08-14T10:25:33.503 に答える
1

どこにでもインターフェイスがある場合は、デバッガーを使用する前に、最終的な呼び出しスタックを理解するのは非常に困難です。私は次の場合にのみインターフェースを好む傾向があります。

  1. チームメンバーは、コーディングを開始する前に誰が何をすべきかについて合意する必要があります。インターフェースは、境界を正確に文書化します。
  2. 問題を解決するために実際にインターフェースが必要な場合、相互に拡張しない少なくとも2つの実装
  3. ケース2を期待します
于 2008-09-21T22:37:19.007 に答える
1

特に他の人があなたのものに共同作業するために、インターフェースはデザインを複雑にしていることがわかりました。誤解しないでください。インターフェースは多くのことに最適ですが、ほとんどの場合、2つ以上のクラスで共通のインターフェースを共有する必要があります。

突然インターフェースが必要になった場合は、Resharperなどのツールを使用したリファクタリングが簡単です:)

于 2008-09-21T22:37:19.317 に答える
1

これは.NETだけではなく、Javaでも同じ問題が頻繁に発生します。

完全に明白な要件でない限り、私はインターフェースを使用せず、必要性が明らかになったときに単にリファクタリングすることに投票します。

実用的なアプローチは、おそらく機能する可能性のある最も単純なことを実行し、建築の宇宙工学に巻き込まれないようにすることを意味します。

于 2008-09-21T22:50:02.110 に答える
1

私は、テスト目的であまり多くのインターフェースを使用しない傾向があります。私はむしろ、私が必要としていたものを最終的に実行する他のオブジェクトとテストを構築するまで、構築とテスト中にプライベート値を公開し、クラスや一時メソッドを開封したいと思います。変更をそのようにラックするのは面倒なこともありますが、何かを変更するのを忘れたときにテストが教えてくれます。

于 2008-09-21T23:06:27.563 に答える
0

ISwissArmyKnife！

これを参照してください：

http://thedailywtf.com/Articles/Classic-WTF-Implements-ISwissArmyKnife.aspx

于 2008-09-21T22:36:35.560 に答える