SOLIDアーキテクチャの開発の原則を理解しない方法

SOLIDアーキテクチャ（Robert Martinの著者）の開発の原則の説明と解釈には問題があります。 多くの情報源がその定義と使用例を示しています。 それらを研究し、自分自身を使ってみようとすると、私は彼らのアプリケーションの魔法について十分な説明がないと常に考えていました。 そして、内部ギアを見て、理解するために、そして私にとっては覚えておくために、それらを「タームシェルフ」に配置しようとしました。 まあ、それが他の誰かに役立つなら。

上記の設計アプローチの「棚のジャグリング」に進みます。

単一責任原則（SRP）単独責任原則

1つのコードは、1つの目標の実装中にのみ変更する必要があります。 コードのセクションが2つのタスクと異なる用途の変更を実装する場合、目的ごとにインスタンスにこのセクションを複製する必要があります。 これは、重複を排除するという一般に受け入れられている原則からの逸脱を必要とするため、非常に重要です。

この原則の目的は、コードセクション、プロシージャ、クラス、コンポーネントの開発に以下の不変条件が存在するという事実に起因する暗黙のエラーを排除することです（以下、[コンポーネント]という用語はこれらの概念を組み合わせるために使用されます）。

• [1]正しく書かれた[コンポーネント]が必ず使用され、より頻繁に数回使用されます。
• [2]使用の各場所で、[コンポーネント]は一貫した動作を維持し、再現可能な結果を​​もたらすことが期待されます。
• [3] [コンポーネント]を複数の場所で使用する場合、結果は各使用場所を満たす必要があります。
• 使用場所の1つで[コンポーネント]の変更が必要で、別の使用場所で[コンポーネント]の以前の動作が必要な場合、その後の変更（または異なる動作を提供する追加パラメータによる[コンポーネント]の一般化）で[コンポーネント]のコピーを作成する必要があります。

• プログラマが解決する現在のタスクにとって重要ではない[コンポーネント]の使用場所がある場合、この[コンポーネント]に加えられた変更のこれらの使用場所との互換性のチェックを忘れるのは非常に簡単です。

  
  
  
  
  
  
  

  したがって、すべての使用場所は、単一の責任の[単一責任]ゾーンに配置する必要があります。つまり、プログラマーによって解決された問題については、一度に変更して考慮してください。

  
  
  
  
  
  
  

  この原則は、コードのセクションと、複数の場所で使用されるコンポーネント、ライブラリ、プログラム、プログラムのセットの両方に適用されます。

  
  
  
  
  
  
  

  多くのソースは、SRPの理想として「関数」を1つだけ持つクラスと、アプリケーションのすべての機能をアンチパターンとして組み合わせた「神オブジェクト」のクラスの例を示しています。 「関数」が1つしかないIMHOクラスは、コードアーキテクチャの時期尚早な最適化の要件であり、最初から多くのクラス（コードエンティティ）を書くことを促します。 「機能」を担当する異種コードエンティティの外部関係を分析するよりも、コードを相互作用させる。 小さなアプリケーションの「神のオブジェクト」も強力な犯罪ではありません。開発を開始できます。必要なすべてのエンティティを選択し、それらを書き留めて、標準ライブラリと外部モジュールの外部オブジェクトから分離します（生細胞を作成し、膜で分離します）。 プロジェクトの成長と開発の過程で、SRPを追跡するのに役立つ多くの方法があります。それらの1つは、クラスへの分割であり、各クラスが担当する「機能」の数を最小限に抑えます（細胞の分割と体内での専門化）。

  
  
  
  
  
  
  

  ここで、SRPを維持するための一連のテクニックを書きたいと思いますが、この作業はまだ完了していません（「手を伸ばす」ことを望みます）。 これらのトリックを探すことができる明白な領域から：

  
  
  
  
  
  
  
• デザインパターン;
• すべてのアプリケーションメソッド（GitHubのフォーク）を満たすコンポーネントを作成するのではなく、異なる特殊なコンポーネントブランチを使用します。

開閉原理（OCP）開閉原理

プログラマが新しいタスクを実装するには、新しいコードを追加する必要があり、古いコードは変更する必要がないように、コードの開発を計画することが最適です。 追加するにはコードを開いて（開く）、変更するにはコードを閉じて（閉じる）なければなりません。

この原則の目的は、人件費を最小限に抑え、開発における次の不変条件に起因する暗黙のエラーを排除することです。

• 前述の[1]、[2]、[3]
• 新しいタスクを実装するために、プログラマは新しい[コンポーネント]を追加したり、古い[コンポーネント]の動作を変更したりできます。
• [コンポーネント]の追加には、新しい使用場所での検証が必要であり、プログラマーの時間を要します。
• 新しいタスクによって引き起こされる[コンポーネント]の動作の変更には、新しい使用の場所と古い使用のすべての場所での検証が必要であり、プログラマの時間もかかります。公開された[コンポーネント]の場合、[コンポーネント]を使用するすべてのプログラマの作業

• プログラマが費やす時間を最小限に抑えながら、新しいタスクを実装するオプションを選択することをお勧めします。

  
  
  
  
  
  
  

  多くの場合、ソフトウェア開発の実践では、追加のコストは変更のコストよりもはるかに少ないため、[Open-Closed]原則を使用するメリットが明らかになります。 同時に、新しいタスクの実装が[コンポーネント]のみを追加することになる状態でプログラムアーキテクチャを維持するための多くのテクニックがあります。 このアーキテクチャでの作業にもプログラマーの時間が必要ですが、大規模なプロジェクトでの練習では、古い手順を変更するアプローチを使用するよりもはるかに少ないことがわかります。 そしてもちろん、この開発の説明は理想化です。 追加または変更するだけでは、タスクの実装はほとんどありません。 実際には、これらのアプローチを組み合わせて使用​​しますが、OCPはaddアプローチを使用する利点を強調しています。

  
  
  
  
  
  
  

  そして、ここでOCPを維持するための一連のテクニックを書きたいと思います。 これらのトリックを探すことができる明白な領域から：

  
  
  
  
  
  
  
• デザインパターン;
• 機能の配布、更新、開発のためのdllライブラリとオプション。
• COMライブラリとその中のオブジェクトの開発。
• プログラミング言語の開発と以前に記述されたコードのサポート。
• 州の立法システムを開発する。

Liskov Substitution Principle（LSP）バーバラLiskov Substitution Principle

この原則は、ベースインターフェイス[base]の拡張の使用を実装に限定し、ベースインターフェイスの各実装がベースインターフェイスとして動作する必要があることを示しています。 同時に、基本的なインターフェイスは、その使用場所で予想される動作を修正します。 また、ベースインターフェイスによって修正される、予想される動作とは異なる実装動作の存在が、不変式の違反の可能性につながります[2]。

この原則は、抽象化に基づいて設計手法をベースにしており、洗練されています。 このアプローチでは、抽象化が導入されます-多くの状況に特有のいくつかの基本的なプロパティと動作が修正されました。 たとえば、[component-procedure]「状況の前の位置に移動」：「テキスト内のカーソル」、「棚の上の本」、「配列の要素」、「ダンスの足」など。そして、この[component]（多くの場合、日常的な経験によるものであり、形式化されていない）いくつかの前提条件と動作、たとえば：「移動可能なオブジェクトの存在」、「数回繰り返す」、「要素の順序の存在」、「要素の固定位置の存在」。 LSPでは、[component]の新しい使用状況を追加するときに、ベースのすべての前提条件と制限が満たされている必要があります。 そして、「砂糖缶の中の穀物」の状況は、この抽象化では説明できませんが、穀物にはもちろん位置があり、穀物が以前にあった位置があり、穀物をそれらの中に移動することができます-要素の固定位置はありません

この原則の目的は、開発における次の不変条件に起因する暗黙のエラーを排除することです。

• 前述の[1]、[2]、[3]、
• 基本的な[手順]では、多数の状況で役立つ動作を説明し、その適用に必要な制約を設定します。

• ベース実装の開発された[手順]は、ハードトラックされた暗黙の（非公式に提供された）制限を含むすべての制限を満たさなければなりません。

  
  
  
  
  
  
  

  多くの場合、この原則を説明するために、長方形（[ベース]）と正方形（実装）の例を示します。 状況class CSquare : public CRectangle
  
  
  
  。 [base]では、幅と高さを操作する操作（Set（Get）Width、Set（Get）Height）が導入されています。 CSquareの実装では、これらのSet操作はオブジェクトの両方のサイズを強制的に変更します。 次の制限が[ベース]で「非公式に」設定されているという説明が常にありませんでした：「幅、高さを個別に使用する機能」。 CSquareの実装では、違反が発生し、使用する場所では、この独立性の使用に基づいた単純な一連のアクションが実行されますr.SetWidth(r.GetWidth()*2); r.SetHeight(r.GetHeight()*2)



r.SetWidth(r.GetWidth()*2); r.SetHeight(r.GetHeight()*2)
  
  
  
  -実装の場合、CSquareはCRectangleで想定される2倍ではなく、両方のサイズを4倍に増やします。

  
  
  
  
  
  
  

  私見この原則は、そのような非公式の制約を追跡することの困難さを示しており、開発アプローチ「基本実装」を非常に有用かつ頻繁に使用するには特別な注意が必要です。

  
  
  
  
  
  
  

インターフェースの分離のインターフェース分離原理（ISP）の原則。 依存関係反転の原理（DIP）依存関係反転の原理

これらの2つの原則は、要件の領域では非常に密接です。 両方とも、2つの[コンポーネント]：「クライアント」と「サーバー」の相互作用のためのツールとして、可能な限り低い基本インターフェースを使用することの有用性を暗黙的に暗示します。 この場合、[コンポーネント]で使用される一般情報は、基本インターフェイスに集中しています。 一方の[コンポーネント]（「サーバー」）は基本インターフェースの実装を実装し、もう一方の[コンポーネント]（「クライアント」）はこの実装を参照します。

これらの原則の目標は、コンポーネントの依存関係を最小限に抑え、基礎となるインターフェイスを変更しない場合にコードの独立した変更を許可することです。 コンポーネントがSRPの原則の要件を満たしている場合、コンポーネント変更の独立性により、複雑さと労力が軽減されます。 以下の不変条件が開発に存在するため、同様のアプローチが可能です。

• 前述の[1]、[2]、[3]
• 埋め込まれた各[コンポーネント]動作は、その使用の制限を形成します。
• [コンポーネント]の各使用場所では、そのすべての制限が関係する場合があります。
• 定義の基本的な[コンポーネント]結果は、[コンポーネント]実装よりも複雑さおよび制限の数が少なく、
• [コンポーネント]を変更すると、その制限が変更され、使用するすべての場所の検証が必要になります。これにより、プログラマーの時間の消費、

• ベース[コンポーネント]の使用場所は、[コンポーネント]実装に変更を加えた後に検証を必要としません。

  
  
  
  
  
  
  

  未使用の機能と制限を破棄することにより、ベースインターフェースの「サイズ」を最小限に抑え、[コンポーネント]の実装を（LSP）

  
  
  
  
  
  
  

  ISPの原則は、公開された機能のすべてがこの「クライアント」によって使用されているわけではない場合、「サーバー」のインターフェースの分離（分離）の必要性を強調しています。 この場合、クライアントが必要とする[ベース]のみが割り当てられ、共同制限情報の最小化が保証されます。

  
  
  
  
  
  
  

  そしてここで、DIPを維持するための一連のテクニックを書きたいと思います。 これらのトリックを探すことができる明白な領域から：

  
  
  
  
  
  
  
• クラスの説明をパブリック部分とプライベート部分（およびOOPの他の原則）に分離します。
• 限られた関数とオブジェクト記述子のセットを持つ動的ライブラリとの相互作用の説明、
• ブックライブラリにアクセスするためのインターフェイスとしてファイルキャビネットを使用します。

見出しに戻って、「理解できない」が選択される理由を説明します。 長い間苦しんで非常に有用なルールを誤って強調するために、否定が追加されます。 誤解し、信頼し、テクノロジーの応用にリソースを費やし、その結果、自己満足とファッショナブルなテクノロジーへの関与について自慢する可能性を除いて、テクノロジーを理解せず、したがってテクノロジーを使用しない方が良いです。

ご清聴ありがとうございました。

参照資料

• 一般的なWikiアルゴリズム理論
• シリーズの最初の記事