インターフェイス分離原則の背後にある理由は何ですか?

StackOverflow https://stackoverflow.com/questions/58988

質問

インターフェイス分離原則 (ISP) では、多くのクライアント固有のインターフェイスが 1 つの汎用インターフェイスよりも優れていると述べています。何でこれが大切ですか？

役に立ちましたか？

解決

ISP は次のように述べています。

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

ISP は重要な特性に関連します - 凝集 そして カップリング.
理想的には、コンポーネントは高度にカスタマイズされている必要があります。コードの堅牢性と保守性が向上します。

ISP を強制すると、次のようなボーナスが得られます。

  • 高い 凝集 - 分かりやすさ、堅牢性の向上
  • 低い カップリング - 保守性の向上、変更に対する高い耐性

ソフトウェアデザインの原則についてもっと知りたい場合は、のコピーを入手してください アジャイル ソフトウェア開発、原則、パターン、実践 本。

他のヒント

インターフェース分離は SOLID 原則の「I」です。前者について深く掘り下げる前に、後者が何を意味するのか説明しましょう。

SOLID は、アプリケーションの設計方法において信頼できる基盤を提供するために、専門家によって作成された (つまり、以前に証明されている) 一連のベスト プラクティスと推奨事項と考えることができます。これらの実践により、アプリケーションの保守、拡張、適応、拡張が容易になるように努めています。

SOLID プログラミングに注意を払う必要があるのはなぜですか?

まず第一に、今いる場所に永遠に留まるわけではないことを認識する必要があります。標準とよく知られたアーキテクチャを使用すれば、後続の他の開発者によるコードの保守が容易になることは間違いありません。また、保守が困難なコードを修正するという作業に取り組みたくなくなるはずです。理解するのが非常に難しいため、既知の方法論は適用しませんでした。

インターフェース分離の原則。

SOLID 原則が何であるかがわかったので、インターフェイス分離の原則についてさらに詳しく説明しますが、インターフェイス分離とは正確には何を意味するのでしょうか?

「クライアントは、使用しない不要な方法を実装することを余儀なくされるべきではありません」

これは、場合によっては、多くのメソッドを含むインターフェイスを作成する傾向があることを意味します。これはある程度は良いことですが、これは簡単に悪用される可能性があり、空のメソッドや役に立たないメソッドを実装するクラスが作成される可能性があり、当然、追加のコードと負担が追加されます。私たちのアプリに。単一のインターフェースで多数のメソッドを宣言していると想像してください。インターフェースを実装しているが実際にはいくつかのメソッドを必要とするクラスを視覚的に補助したい場合は、次のようになります。

enter image description here

一方、インターフェイスの分離を適切に適用し、インターフェイスをより小さなサブセットに分割すれば、必要なものだけを確実に実装できます。

enter image description here

見る！はるかに優れています!この原則を強制すると、結合度が低くなり、保守性が向上し、変更に対する高い耐性が得られます。したがって、本当に必要なときに、インターフェイスの使用とメソッドの実装を最大限に活用できます。ここで、それほど抽象的ではない例を見てみましょう。Reportable というインターフェイスを宣言したとします。

public interface Reportable {

        void printPDF();
        void printWord();
        void printExcel();
        void printPPT();
        void printHTML();


}

一部のデータを Excel 形式でエクスポートするだけのクライアントがある場合、インターフェイスを実装できますが、実装する必要があるのは Excel メソッドだけでしょうか?答えは「いいえ」です。メソッドを使用しない場合でも、すべてのメソッドの実装をコーディングする必要があります。これにより、大量のジャンク コードが発生する可能性があり、コードの保守が困難になります。

シンプルに保ち、同じことを繰り返さないようにしてください。そうすれば、知らず知らずのうちにこの原則をすでに使用していることに気づくでしょう。

これにより、クライアントが使用するインターフェイスが簡素化され、インターフェイスの不要な部分で発生する可能性のある依存関係が削除されます。

理由の 1 つは、インターフェイスごとに最小限の量のメソッドを備えた多数のインターフェイスを用意すると、各インターフェイスの実装と正しく実装することが容易になるためです。大規模なインターフェイスは手に負えない場合があります。また、シナリオで焦点を絞ったインターフェイスを使用すると、オブジェクトのどの面が使用されているかがわかるため、コードの保守が容易になります (たとえば、IComparable インターフェイスを使用すると、オブジェクトが特定のシナリオでの比較にのみ使用されていることを知ることができます)。

この原則は主に 2 つの目的に役立ちます

  • コードをより読みやすく、管理しやすくするため。

  • クラスに対する単一の責任を促進します (高い凝集性)。もちろん、なぜ動作に影響を与えないメソッドをクラスに持たせる必要があるのでしょうか?それを削除しないのはなぜですか。それが ISP の目的です

設計者が ISP に対して尋ねなければならない質問はほとんどありません。

  • ISP で何を達成できるのか
  • 既存のコードを分析して ISP 違反を見つける方法

この議論をさらに進めるために、この原則は厳密な意味での「原則」ではないことも付け加えなければなりません。特定の状況下では、可読性を高める代わりに設計に ISP を適用すると、オブジェクト構造が判読不能になり、オブジェクトが乱雑になる可能性があるためです。不要なコード。これは java.awt.event パッケージで確認できると思います。

詳細は私のブログで: http://design-principle-pattern.blogspot.in/2013/12/interface-segregation-principle.html

ISP は重要。

ISPの基本的な考え方：クライアントは、使用しないメソッドに強制的に依存すべきではありません。

この原則はより論理的であるように思えます。理想的には、クライアントは、クライアントによって使用されないメソッドを実装すべきではありません。

コード例については、以下の SE の質問を参照してください。

インターフェイス分離の原則 - インターフェイスへのプログラム

利点:

  1. 柔軟性 :ISP が存在しない場合、1 つの汎用 FAT インターフェイスとそれを実装する多数のクラスが存在します。1 つのインターフェイスと 50 のクラスがあると仮定します。インターフェースに変更がある場合、50 クラスすべての実装を変更する必要があります。

    ISP を使用すると、汎用 FAT インターフェイスを細かい粒度の小さなインターフェイスに分割します。小さな粒度のインターフェイスに変更があった場合、そのインターフェイスを実装しているクラスのみが影響を受けます。

  2. メンテナンス性と使いやすさ:変更は汎用の FACT インターフェイスではなく、きめ細かいインターフェイスに限定されるため、コードのメンテナンスが容易になります。関連のないコードは実装クラスの一部ではなくなりました。

1 つのクライアント固有または 1 つの動作固有の変更だけが発生する場合の回帰作業を回避するため。すべての動作メソッドを 1 つの大きなインターフェイスにまとめた場合、たとえ小さな変更しか発生しなかったとしても、そのインターフェイスだけを参照したコードのすべての部分を最終的にどのようにテストすることになるかを考えてください。

より詳細な説明については、を参照してください。 インターフェース分離原則に関する記事

ロバート・マーティンの論文 この件については、あまり言及されていない説明があります。

クライアントによってインターフェースに加えられる逆方向の力。

2 つのクラスが 3 番目のクラスの 2 つの異なるメソッドに直接依存している場合、最初の 2 つのクラスのいずれかに対する変更が他方に影響を与える可能性が高くなります。

3 つのクラスがあるとします。 Red, Green, 、 そして Blue.

Red そして Green どちらも依存する Blue, しかし、それぞれは異なる方法に依存します。つまり、 Red ～の1つの方法に依存します Blue ただし、他の方法は使用しません。同じく、 Green に依存します Blue, ただし、一方の方法のみを使用し、もう一方の方法は使用しません。

原則違反となるのは、 Red そして Green それぞれがクラスに依存しているため、 Blue - しかし しません 少なくとも 1 つのメソッドを使用してください。

これによりどのような問題が生じる可能性がありますか?

  • 変える必要がある Red, 、そして私も変わります Blue のニーズに応えるために Red.
  • 特定のメソッドは変更していません Blue それ Green にもよりますが、それでも、 Green に依存します Blue そして私は変わりました Blue, 、依然として影響を与える可能性があります Green.
  • したがって、私の変更点は、 Red 影響を与える可能性がある Blue なぜなら、それらは私に、両方が依存するクラスを変更するよう導いたからです。

それが「後方の力」です。クライアントのニーズのためにクラスを変更することがあります。そのクラスに、それをさまざまな目的で使用するさまざまなクライアントがある場合、それらに影響を与える危険があります。

前述したように、インターフェイス分離原則の簡単な定義は次のとおりです。

クライアントは、使用しないメソッドに依存することを強制されるべきではありません。

それと Robert Martin の論文の上記の点の間に、ISP に関する多くの説明が実際には他の原則について話していることは明らかです。

  • 多数のメソッドを含むクラスやインターフェイスは望ましくありませんが、特に ISP が原因というわけではありません。単一責任に違反する可能性があります。しかし、ISP 違反は大きなインターフェイスや大きなクラスではなく、クラス内で発生します。 による 大きなインターフェイスでは、そのすべてのメソッドを使用しない場合。すべての方法を使用しても、依然として乱雑に聞こえますが、それは ISP とは関係ありません。
  • インターフェイスを実装しているが、特定のメソッドに対して例外をスローするクラスは悪いですが、それは ISP でもありません。ISP とは、次のようなクラスを指します。 依存する クラスではなくインターフェイス上で 埋め込む インターフェース。

Google で「インターフェイス分離」を検索すると、コード サンプルを含む上位の結果のほとんどが、次のようなクラスを示しています。 完全に実装しない インターフェイス、これは ISP の目的ではありません。この原則を次のように言い直す人もいます。

インターフェイス分離原則では、クライアントが使用しないインターフェイスの実装を強制されるべきではないと述べています。

...しかし、それは ない 原則。定義文書では、このような懸念を ISP 違反の副作用として言及していますが、それらがリスコフ置換違反であることを示しています。

さらに、新しいインターフェイスが基本クラスに追加されるたびに、そのインターフェイスを派生クラスで実装（またはデフォルトにすることを許可）する必要があります。実際、関連する実践としては、これらのインターフェイスを純粋な仮想関数ではなく nil 仮想関数として基本クラスに追加します。特に、派生クラスがそれらを実装する必要性を負担しないようにするためです。このコラムの 2 番目の記事で学んだように、このような慣行は これはリスコフ置換原則 (LSP) に違反しており、メンテナンスと再利用性の問題につながります。

さらに、クライアントが使用しないメソッドを実装すべきではないということさえ意味がありません。の クライアント インターフェイスのメソッドは実装されていません。

私はこの論文を、あたかも聖典か何かであるかのように尊大に引用するつもりはありません。しかし、記事で説明されている原則の名前 (記事自体の名前) を使用する場合は、その記事に含まれる実際の定義と説明も考慮する必要があります。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top