SOLID原則の例外はありますか？

Question

私はプロジェクトのクラスデザインにSOLID原則を適用しようとしています。 SOLID原則の例外はありますか？私たちはこれらの原則を徹底的に適用しなければなりません。たとえば、私は工場クラスを用意しました。

class XAdderFactory 
{ 
    private Person _person; 

    public bool PersonHasNoRecords 
    { 
     get 
     { 
      return string.IsNullOrEmpty(_person.HasXRecords); 
     } 
    } 

    public XAdderFactory(Person person) 
    { 
     this._person = person; 
     if (PersonHasNoRecords) 
     { 
      new XListMakerAFactory(person); 
     } 
     else 
     { 
      new XListMakerB(person); 
     } 
    } 
} 

このクラスはOCPに準拠しません。
将来、新しいタイプのリストメーカーが必要になる場合があります。新しいelse ifブロックを追加する必要があります。
私のデザインは悪いですか？
あまりにも頻繁に言及されていないSOLIDの原則の例外はありますか？
私の例はOCPの "Strategic Closure"に準拠していますか？ SOLID例外に関する別の例がある場合は、設計者にとって役立つと思います。

Answer 1

オープンクローズの原理は重要かつ有用ですが、すべてのクラスおよびすべてのモジュールに盲目的に適用されるべきものではありません。場合によっては、拡張性を有効にする抽象化を作成するだけでは、拡張子が必要でないため、価値がありません。他のケースでは、要件が変更されることが予想されますが、どのような変更が必要か、他の要件についてはわからないため、決定を延期し、より簡単なモジュールOCPを尊重しない実装。

Answer 2

SOLIDの原則は単なるガイドラインです。あなたは、これらの原則を使って、問題の解決に遭遇することができます。

あなたの主な焦点は、ソリューションを特定のデザインパターンまたは原理に適合させるのではなく、問題の解決策を設計することです。

実際にクラスを変更しないと思う場合は、Open/Closed principleを実装するだけです。一般に、新しいタイプを追加するために既存のFactoryクラスを変更する際には問題はありません。三の原則の下

は解決

Interface_segregation_principleを設計するために非常に便利です：いいえクライアントは、それが

実装クラスがする必要がある場所をコード内で脂肪のインタフェースを使用しないでくださいを使用しない方法に依存するように強制されるべきではありません未使用または関連しないメソッドをオーバーライドします。詳細なインタフェースを設計し、これらの細かいインタフェースを実装するクラスを作成します。 関連SEの質問：

Interface Segregation Principle- Program to an interface

Dependency_inversion_principle：それは良い原則です。あなたは、実装ではなくインターフェイスにプログラムする必要があります。

Liskov_substitution_principle：実行時に動的に実装を変更する必要がある場合は、この原則を使用してください。アプリケーションの実装が変更されない場合、この機能は必要ありません。

しかし、Single_responsibility_principleは5つの原則すべての間で議論の対象となります。 モジュールは1つの責任を負うことがありますが、1つの責任を持つクラスを設計すると、数百/数千のクラスにつながります。

Answer 3

SOLIDの原則（またはその他の関連原則）は、ソフトウェアプロジェクトの潜在的な落とし穴/脅威を実装および保守の面から回避するためのガイドラインです。その反射を知らずに盲目的に原理をたどるだけでは、まったく動作しません。

例として、OCPを使用します。 OCPの背後にあるキーコンセプトは、あなたのプロジェクト100％がOCPに準拠している場合、他のユーザー（外部メンバー、新規メンバー）が現在のコードを見ずにコーディングを行うことができますが、本当にその人の人生を楽にしてくれます。また、既存のコードを変更する必要がないため、既存のコードを何度も何度もテストする必要はありません。しかし、実際には、OCPを壊さなければならない状況がいくつかあります。

例：

• 新しい要件（既存のクラス内で実装する必要があります）、

• など

• 限定フレームワークのサポート（任意のMVCフレームワーク）のバグ修正。

また、状況によっては我々はそれが害を及ぼさないことを知ってOCPを破っている。

原則については、このような簡単な類推があります。歩くときは、歩行者として多くの原則があります。

例：左側の

• ウォーク。

• 歩行者交差点でのみ交差する（車があなたにはっきりと見えて止まるようにする）。

可能な限り確実に安全にしてください。しかし、道路に数マイルの車がない状況を想像してください。道路を横断するための横断歩道をまだ探していますか？権利はありません？あなたは歩行者の交差点でなくてもあなたが安全であることを知っています。そして、道路の左側がかなり泥だらけで歩くことができない状況があるなら、あなたは依然として原則に従うために泥の上にいますか？権利はありません。あなたはむしろ状況を知って右手を歩くだろう。

あなたは原則について考えていると思います。 :)

Answer 4

私はコードを書くときに考慮しなければならない最初のものを見つけたと思う。ユニットテスト。固体原理、デザインパターンなどは、ユニットテストを行うのに役立つツールです。私のような未熟なプログラマー）は例外なくユニットテストを適用する必要があります。テスト結果は、より良い設計に向けてプログラマにつながります。