問題タブ [interface-segregation-principle]

SOLIDの「インターフェイス分離の原則」は「単一責任の原則」とどのように異なりますか？

SOLIDのウィキペディアのエントリには次のように書かれています

ISPは、非常に大きいインターフェイスをより小さく、より具体的なインターフェイスに分割するため、クライアントは関心のあるメソッドについてのみ知る必要があります。

ただし、私には、SRPをクラスだけでなくインターフェイスにも適用しているように聞こえます。結局のところ、インターフェースが1つの概念的なことだけを担当している場合、それをさらに分解することはできません。

私は何かが足りないのですか、それともISPはSRPと冗長なのですか？そうでない場合、ISPはSRPがそうではないことを何を意味しますか？

未使用のメソッドを持つクラスからの継承は、インターフェイス分離の原則に違反しますか?

例えば：

Concretemethod に依存しますBase.Receive(int n)が、決して使用しません。

UPD

私が使用する定義：

ISP は、クライアントが使用しない方法に依存することを強制されるべきではないと述べています。

思い出させるために（ウィキから）：

インターフェイス分離の原則(ISP) は、クライアントが使用しない方法に依存することを強制されるべきではないと述べています。

そして今、私の例を見てください。

これが私の可変エンティティです。どこかから編集され、読み取り専用インターフェイスを介して変更を通知できます。

そして、これを使用するトランスポート層のクラスを次に示します。インジェクションの 2 つのバリアント (Attach_1およびAttach_2) と、以下の私の仮定を見てください。

1. ISP は実際のオブジェクトに関するものです。着信パラメーターへの「過剰な」参照を使用してはなりません。
2. ISP はクラスに関するものです。クラスがすでにどこかで完全なインターフェースを使用している場合、特定のメソッドで参照型を制限する必要はありません。 ICounterこの例ではインターフェイスが過剰です。
3. このアーキテクチャは、SOLID 原則の観点からは完全に間違っています (では、なぜでしょうか?)。

java.awt.event パッケージでの Adapter パターンの使用法は、私にはわかりにくいようです。まず第一に、これは明らかに Interface Segregation Principle ( ISP ) に違反しているように見えます。

同様に、MouseMotionAdapter クラスは MouseMotionListener を実装しますが、オーバーライドされたメソッドの両方に「NIL」実装を提供します。

これこそまさに ISP 違反のすべてです。ISP によると、MouseMotionListener は、moseDragged と moveMoved の動作にそれぞれ 1 つずつ、2 つの別個のインターフェイスに分割されますか?

おそらく、このようにインターフェースを分割すると、インターフェースの数が急増し、各実装クラスが多数のインターフェースを実装する必要があるため、コーディングがより洗練されなくなります。

私の議論が正当化されているかどうかを明確にする必要がありますか?

この状況は何度も起こりましたが、解決方法がわかりません。

インターフェイス分離の原則は、一部のインターフェイス実装がその機能を使用しない状況を防ぐために作成されました-それは明らかです。インターフェースのリストがあり、それらを使って何かをしたいという状況がよくあります。ISP なしの例を見てみましょう:

そして、すべての人と走りたい。

今はみんなと一緒に食べたいです。

ISP を使用する場合は、コードを次のように変更する必要があります。

人のリストはどのように作成すればよいですか? Runable と Eatable の 2 つのリストを作成してオブジェクトを追加する必要がありますか (醜い)、または 2 番目のアプローチ - 1 つのリストを作成し、可能であればそれらをキャストする必要がありますか (醜い)? それを行うための最良の規則が何であるかはわかりません。

この例は、私が想像できる最良の例ではないかもしれませんが、私の言いたいことを理解していただければ幸いです。

編集: インターフェイスとクラス、およびプリンシパル名を変更しました。

Interface Segregation Principle と Open/Closed Principle の違いがわかりません。

私が理解しているのは、ISPはすべてをインターフェイスに依存させ、OCPをクラスに依存させる必要があるということです。どちらも同じ方法で実装できますが、インターフェイスを使用するものとクラスを使用するものがあります。

インターフェイスの分離と単一の責任の原則に従おうとしていますが、すべてをまとめる方法について混乱しています。

ここでは、いくつかのインターフェイスをより小さく、より直接的なインターフェイスに分割した例を示します。

少し簡略化しました (where読みやすさを妨げる条項がいくつかありました)。

現在、私はSQLiteを使用していますが、このパターンの利点は、たとえばAzureなどの別のデータ ストレージ方法を選択した場合に、変更に適応する機会が得られることです。

これで、これらの各インターフェイスの実装ができました。それぞれの簡単な例を次に示します。

今、私はそれをすべてまとめるのに問題があります。一般的な考え方は、クラス (実際の実装) ではなくインターフェイスDatabaseを使用するクラスを作成することだと確信しています。だから、私はこのようなものを思いついた：

ここでの質問は、、、、およびインターフェイスをクライアントIDataReadにどのように公開する必要があるかということです。インターフェイスにリダイレクトするようにメソッドを書き直す必要がありますか? このような：IDataWriteIDataDelete

私のコメントを強調すると、これは少しばかげているように見えます。クラスを適切に分離された実装に分離するために多くの苦労をしましたが、今ではすべてを 1 つのメガクラスにまとめています。

次のように、インターフェイスをプロパティとして公開できます。

これは少し気分が良くなりますが、クライアントは、使用する必要があるインターフェイスを決定するという面倒を経験する必要はありません.

ここでポイントを完全に見逃していますか？ヘルプ！