SOLID Principlesのプログラミング

時間が経つにつれて、SOLIDの 2つの部分、「S」と「O」を理解できました。

「O」–継承と戦略パターンの助けを借りて、オープンクローズドプリンシプルを学びました。

“ S” – ORMの学習中に単一責任の原則を学習しました（永続化ロジックはドメインオブジェクトから取り除かれます）。

同様に、SOLIDの他の部分（「L」、「I」、「D」）を学習するのに最適な領域/タスクは何ですか？

参照資料

1. msdn-C＃でのSOLID原則違反の危険性
2. channel9-.NET / C＃でのSOLID Principlesの適用
3. OOPS原則（固体原則）

数ヶ月前、私はあなたの靴を履いていましたが、とても役立つ記事を見つけました。

各原則は、各ソフトウェア開発者がプロ​​ジェクトで直面する可能性のある実際の状況でうまく説明されています。ここで短くして、リファレンス-SOLID Software Development、One Step at a Timeを指しています。

コメントで指摘したように、別の非常に優れたPDFの読書があります-PabloのSOLID Software Developmentです。

さらに、SOLIDの原理をより詳細に説明する優れた書籍がいくつかあります-SOLID Software Developmentに関する優れた書籍。

各原則の短い要約の編集とコメント：

• 「S」–単一責任の原則は、変更を許可するというビジネスのニーズに基づいています。「変更する単一の理由」は、技術的な概念だけでなく、ビジネスの概念とコンテキストを考慮することで、論理的に分離された概念をグループ化する必要があることを理解するのに役立ちます。 In another words、私は各クラスが単一の責任を負うべきであることを学びました。割り当てられたタスクを実行するだけです。

• “ O” –オープンクローズドプリンシプルを学び、「継承よりも合成を優先する」ようになりました。そのため、仮想メソッドを持たず、おそらく拡張される抽象化に依存するクラスを優先します。

• 「L」–データアクセスを管理するためのリポジトリパターンの助けを借りて、リスコフの代替原則を学びました。

• 「I」–クライアントが使用しないインターフェイスを実装するように強制されるべきではないことを学習することで、インターフェイスの分離の原則を学びました（ASP.NET 2.0のMembership Providerなど）。そのため、インターフェイスには「多くの責任」がありません
• 「D」–依存関係反転の原理について学び、変更しやすいコードを作成し始めました。変更しやすいということは、総所有コストが低くなり、保守性が高くなることを意味します。

CodePlexの有用なリソースがコメントで言及されたため、例としてSOLIDへの参照が含まれています

（I）インターフェースの分離と（D）優越性の反転は、ユニットテストとモックによって学習できます。クラスが独自の依存関係を作成する場合、適切な単体テストを作成できません。あまりにも広いインターフェイスに依存している場合（またはインターフェイスがまったくない場合）、単体テストを行うために何をモック化する必要があるかはあまり明確ではありません。

Liskov Substitution Principleでは、基本的に実装の継承を過度に使用することはできません。コードの再利用のためだけに継承を使用しないでください（このための構成があります）。LSPを順守することで、スーパークラスとサブクラスの間に「is-a関係」が実際に存在することを確信できます。

つまり、サブクラスは、サブクラスのメソッドの実装と同様の方法で、サブクラスのすべてのメソッドを実装する必要があるということです。NOPを実装してメソッドをオーバーライドしたり、スーパータイプが例外をスローしたときにnullを返したりしないでください。Design by Contractの条件で述べられているように、メソッドをオーバーライドするときは、スーパークラスからのメソッドのコントラクトを尊重する必要があります。この原則を破ることを防ぐ方法は、実装されたメソッドをオーバーライドしないことです。代わりに、インターフェースを抽出し、両方のクラスでそのインターフェースを実装します。

GRASPのインターフェイス分離の原則、単一責任の原則、および高コーヒションの原則は何らかの形で関連しています。それらは、変更が非常に簡単に行われるように、変更の理由が1つだけであるように、エンティティが1つのことだけに責任を持つべきであるという事実を参照します。

実際には、クラスがインターフェイスを実装する場合、それらのインターフェイスのすべてのメソッドを実装して使用する必要があると言います。その特定のクラスに必要のないメソッドがある場合、インターフェイスは適切ではなく、元のクラスに必要なメソッドのみを持つ2つのインターフェイスに分割する必要があります。POVから考えることができます。これは、実装によってLSPが壊れる可能性があるため、大きなインターフェイスを作成できないという事実によって、前の原則に関連しています。

Factoryパターンで依存関係の反転を確認できます。ここでは、高レベルコンポーネント（クライアント）と低レベルコンポーネント（作成される個々のインスタンス）の両方が抽象化に依存しています（インターフェース）。階層化されたアーキテクチャにそれを適用する方法：実装された層ではなく、呼び出されたモジュール内の層へのインターフェースを定義すべきではありません。たとえば、データソースレイヤーへのAPIは、データソースレイヤーではなく、呼び出しが必要なビジネスロジックレイヤーに書き込む必要があります。このように、データソースレイヤーは、ビジネスロジックで定義された動作（したがって、反転）を継承/依存し、逆ではなく（通常の方法で）。これにより、設計に柔軟性がもたらされ、まったく異なるデータソースを使用して、コードを変更することなくビジネスロジックを機能させることができます。