3

Liskov Substitution Principleより - www.blackwasp.co.uk

LSP に準拠していないことを示す一般的な兆候の 1 つは、クライアント クラスがその依存関係のタイプをチェックする場合です。これは、人為的に型を記述するオブジェクトのプロパティを読み取るか、リフレクションを使用して型を取得することによって行われる場合があります。多くの場合、switch ステートメントは、依存関係のタイプに応じて異なるアクションを実行するために使用されます。この追加の複雑さは、Open / Closed Principle (OCP) にも違反します。これは、さらにサブクラスが導入されると、クライアント クラスを変更する必要があるためです。

次のテクノロジ (リフレクションを使用する) は LSP 違反になりますか?

  1. 依存性注入
  2. 制御の反転

注: 私は C# のバックグラウンドを持っています。

http://blogs.msdn.com/b/simonince/archive/2008/06/30/dependency-injection-is-dead.aspxから

反射; ほとんどの (おそらくすべて?) 依存性注入コンテナーは、オブジェクトを動的に検査し、それらの依存性を決定する、リフレクションにある程度依存しています。

参考文献:

  1. ヒエラルキーはリスコフに違反している - それで何？

  2. Liskov Substitution Principle (LSP) を破らないようにするにはどうすればよいですか?

  3. Liskov Substitution Principleはインターフェースを実装するクラスにも適用されますか?

  4. これは Liskov 置換の原則に違反していますか? もしそうなら、どうすればよいでしょうか?

  5. GWT の ActivityMapper は Liskov Substitution Principle に違反していますか?

4

1 に答える 1

3

私がLSPを理解する方法は、サブクラスがあらゆる状況で基本クラスの代用可能であるべきであることを単に述べているだけです。つまり、基本クラスのインスタンスを(メソッド、コンストラクター、サービスなどに)渡すたびに、できるはずです。これが機能するようにコードを変更せずに、代わりにサブクラスのインスタンスを渡します。他の原則と同様に、LSP はガイドラインであり、厳密なルールではありません。これにより、コードが拡張可能になりやすくなります。フレームワークの作成者がリフレクションを使用する場合、LSP を壊していません。これを、サービス ロケーションを使用するフレームワークと単純に対比できます。これは現在、多くの OO 支持者によってアンチパターンと見なされていますが、フレームワークで独自のコンテナーを選択できるようにする必要があります。いつものように、それはトレードオフであり、コンテキストに依存します (あなた自身の特定のユースケース) .

于 2013-06-19T11:23:42.163 に答える