4

単一責任の原則が、すべてのオブジェクトには変更する理由が 1 つ必要であり、Strategy パターンで実装された単一の戦略クラス (定義による) に、さまざまな理由で変更できる複数のメソッドがあると述べている場合、それは実装が不可能であることを意味しますか? SRPに違反することなく戦略パターン？

4

5 に答える 5

3

どうして？思い出すと、戦略パターンは基本的に、使用されているロジック/アルゴリズムを分離する方法です。したがって、クライアントには m_IAlgorithm があります。IAlgorithm には、1 つではないにしても、少数のメソッド セットが必要です。

したがって、AlgoImplementation クラスが変更される唯一の理由は、

  • 実装するアルゴリズムに変更がある場合。（責任・行動の変化）
  • または IAlgoritm が変更された場合..インターフェイスの定義を間違えない限り、これはまれです。(これは独自のパブリック インターフェイスの変更です。SRP に違反しているとは思わないでください。)
于 2009-04-28T07:31:06.183 に答える
3

私は実際には逆に見えます。戦略パターンを使用すると、2 つのことを切り離すことができます。1 つの仕事を完了するために使用される (潜在的な) アルゴリズムと、これらのアルゴリズムに関する意思決定ロジックです。

どのアルゴリズムを使用するかについて条件付きロジックを実行し、それらのアルゴリズムを囲むクラスがあるかどうかはわかりません。また、あなたがそれをほのめかしたと言っているわけではありませんが、戦略がSRPを壊す例と、あなたの意見ではより良い設計は何かを示していません.

于 2009-04-28T07:42:28.980 に答える
2

私が単一責任の原則に最も精通しているコンテキストは、システム全体の設計であり、システム内のコンポーネントのグループ化に関して戦略パターンを補完することができます。

戦略パターンを使用して、クライアントが交換可能に使用する一連のアルゴリズムを定義します。次に、単一責任の原則を使用して、クライアントとクライアントがシステム内で使用するアルゴリズムをグループ化する場所を決定できます。作業がアルゴリズム B だけで行われている場合、およびその逆の場合は、アルゴリズム A のコードを妨害する必要はありません。コンパイル済み言語の場合、これはリファクタリング、バージョン、および展開サイクルの複雑さに大きな影響を与える可能性があります。アルゴリズム B の変更だけが必要な場合に、クライアントとアルゴリズム A、C、および D をバージョン管理して再コンパイルするのはなぜですか。

単一責任の原則をこのように理解すると、戦略パターンを実装するクラスを持つことが SRP に違反する場所がわかりません。クライアント クラスの目的は、クライアントの責任である戦略パターンを実装することです。アルゴリズムの目的は、それらが担当するロジックを実装することです。単一責任の原則では、さまざまな理由で変更されるため、システム内でそれらをすべてグループ化しないでください。それが私の 0.02 ドルです。

于 2011-04-18T13:31:19.613 に答える
0

良い点:)それは多くの場合に理にかなっている単一の責任のガイドラインだと思いますが、戦略パターンのようにそうでない場合もあります..

于 2009-04-28T07:20:08.787 に答える