問題タブ [interface-segregation-principle]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
oop - インターフェイス分離の原則と便利/ヘルパー メソッド
インターフェイス分離の原則は、コンビニエンス/ヘルパー メソッドにどのように適用されますか? 例えば:
取引先を表すインターフェースを作りたい。最低限必要なのは、パートナーのリスト全体を設定または取得するセッター メソッドとゲッター メソッドです。
また、特定の人がパートナーのリストに含まれているかどうかを知らせるために、contains() メソッドも必要です。getPartners() を呼び出して、指定された人がそのリストに含まれているかどうかを確認するため、これはヘルパーまたは便利なメソッドと見なします。
インターフェイス分離の原則に関する私の理解では、contains() メソッドを別のインターフェイスに分離する必要があるということです。私の例では大したことではありませんが、ヘルパー メソッドのリストがすぐに長くなる可能性があるため (addPartner、addPartnerByID、addPartnerByUserid など)、これは実際的な問題です。
私の懸念は、contains() メソッドを保持するためのインターフェースの名前を選ぶのが非常に難しいと感じていることです。あなたのデザインに何か問題があります。PartnersSupportingSetInclusionChecks という名前のインターフェイスを使用するのは適切ではないように思われます。また、PartnerHelperMethods という名前だけのインターフェイスを使用するのも適切ではないようです。
このようなメソッドにインターフェイス分離の原則を適用するにはどうすればよいですか?
solid-principles - インターフェイス分離原則の動機付けポスターを理解する
このページのインターフェイス分離原則の「やる気を起こさせるポスター」に、「これをどこに接続してほしいですか?」と書かれているのはなぜですか?
インターフェイス分離の原則は言う
クライアントは、使用しないインターフェイスに依存することを余儀なくされるべきではありません。
画像とキャッチフレーズがこの原則にどのように関連しているかはわかりません。漠然としていますが、高レベルのオブジェクトが低レベルの実装に依存してはならない依存関係逆転の原則のモットーのようです (プラグポイントは、プラグインされているデバイスの詳細を知る必要はありません)。
これらのことわざが冗談であることは承知していますが、もう一方のことわざが原則をいかにかわいく説明しているかを考えると、ISP のこの特定のポスターを誤解したくありません。
c++ - C++ でスマート ポインターを使用してインターフェイス分離の原則を実装するにはどうすればよいですか?
私は Delphi と C# のバックグラウンドを持っているので、インターフェイスを彼らの視点から理解しています。私は数年間 C++ をやっていますが、その観点からインターフェイスをまだ学んでいます。
私のアプリケーションでは、各クラスでサポートされているさまざまな動作を示すために、複数のインターフェイスを実装する (つまり、複数の純粋な抽象クラスを継承する) クラスが必要な状況があります。これは正確には ISP ではありませんが、同じ問題であるほど十分に近いものです。
動作インターフェイスは相互に継承されません。階層はありません。
Delphi と C# は息を切らさずにこれを行いますが、C++ でこれがどのように行われるかを理解しようとしています。(また、今のところ、私は C++11 に限定されています。)
dynamic_pointer_cast、static_pointer_cast について調査しましたが、継承階層が必要です。
reinterpret_pointer_cast を見ましたが、C++11 では使用できません。
ビヘイビアー インターフェイスが継承するルート インターフェイス (COM の IUnknown や Delphi の IInterface に似ています) を使用して継承階層を作成しようとしましたが、ひし形の問題に遭遇しました。
基本インターフェースにメソッドを追加して各ビヘイビアーインターフェースへの参照を返すという提案をいくつか見てきましたが、それは私が本当に望んでいない一種の結合です。後でそれらを実装する他のビヘイビアーやクラスを追加する必要があるかもしれないからです。
これは、私がやろうとしていることの簡単な例を示す、コンパイルしていないコードです。
SOME_KIND_OF_CAST プレースホルダーが ProcessAllBehaviorA メソッドのどこにあるのかを理解しようとしています。
私はこれをやろうとする最初の人にはなれないと確信しています。
他の人は、C++ でスマート ポインターを使用してインターフェイス分離の原則 (または私のような同様のパターン) をどのように実装していますか?
java - Liskov 置換原理 VS インターフェイス分離原理
この 2 つの原則を理解するのに苦労しています。これは少し長文の質問なので、しばらくお待ちください。
クラスがあるとしましょう
とインターフェース
そして、2 つの子クラスを作成します。
そして今、私たちは道具を作りShape
ますSideCountable
子クラスに変更を加える
そして、この構造のテスト関数を作成します(LSPに従って):
そして、ここでやめたいと思います。なぜなら、実際には次のステップで立ち往生したからです。3 番目のクラスを作成するとどうなるでしょうCircle
か。
Circle には側面がないため、SideCountable
for this children の実装はばかげているように聞こえます。わかりました。実装を Quad と Triangle のみに移動できますが、この場合、LSP は機能しなくなります。誰かが私がすべき最善の方法を説明できますか?
- クラスに残し
SideCountable
て0を返し、インターフェイスの分離原則を破りますか?Shape
Circle
- 移行
SideCountable
しQuad
てTriangle
LSP の原則を破りますか?