SOLIDの原則は、オブジェクト指向プログラミング（OOP）が従う5つのルールです。これらのルールまたは原則を使用して、コードの臭いを回避し、単純なリファクタリングを可能にしながら、拡張と保守が容易なソフトウェアを作成できます。明らかに、これらの5つの原則は万能薬ではなく、コードベースを修復したり、コードベースに魔法をかけたりすることはありません。これらのルールに従っても、メンテナンスとリファクタリングを困難にするコードを記述できます。これらのルールは、ソフトウェアを設計および作成するときに心に留めておくべき良いものですが、コーディングガイドラインやその他の概念（設計パターンなど）と組み合わせて使用することもできます。
この記事では5つの原則すべてを紹介しますが、コード例とコードスニペットを通じて各原則をより詳細に説明する他の記事にもリンクします。OOPを理解していない、または確認したい場合は、OOPの基本を説明する前にこれらの投稿を読むことをお勧めします。
単一責任の原則
単一責任原則（SRP）は、おそらく5つの原則の中で最も理解しやすいものです。クラスごとに1つのジョブのみが必要です。非常にシンプルに思えますが、開発者がそれを追及しようと努力しても、ほとんどの開発者はあなたに言うことができます。この原則で理解するのが難しいのは、クラスの単一の責任が非常に具体的または抽象的な場合があることです。たとえば、長方形のデータ、そのサイズと位置を保存することを目的とするクラスがあるかもしれませんが、クラスの場合は、長方形のすべてのデータを保存して計算を処理するより一般的なクラスを持つことができます。面積と周長。2番目の例では、複数のタスクを実行し、その面積または周長を計算できますが、責任処理長方形は1つしかありません。ユーザーの署名も同じカテゴリで処理されると、責任がなくなり、SRPが破棄されます。
単一責任の原則について覚えておくべき重要なことは、各クラスは既存の存在に対して明確に定義された目的を持つ必要があり、1つのことしかできないということです。この問題は、長方形の処理などの非常に具体的である場合や、より一般的な場合があり、複数の操作（ユーザー認証の処理など）があります。原則は、より小さなスコープに拡張することもできます。各クラスには単一の目的があり、そのクラスの各メソッドには、より具体的な単一の目的があります。
単一責任の原則の詳細については、こちらをご覧ください。
開閉の原理
開閉の原則では、オブジェクトは展開のために開かれ、変更のために閉じられるべきであると述べています。つまり、どのオブジェクトも機能を拡張または追加するのは簡単ですが、変更または変更しないでください。この原則は、OOPパラダイムの外では意味がないため、最初は理解することが困難です。特定の関数を処理し、コードを変更できないようにコンパイルするコードがあるとします。コードに機能を追加して、ソースコードを変更せずに拡張および拡張できるようにする必要がありますが、変更のために閉じることができます。機能を追加するには、最初にソースコードを変更してからコードを再コンパイルする必要があるため、これはOOPの外では不可能です。ただし、OOPでは、クラスのコンパイルソースを使用して、それを新しいクラスで継承できます。新しいクラスは、プリコンパイルされたクラスの子になります。基本クラスから継承すると、基本クラスにはない機能を追加したり、基本クラスを変更したままにすることができます。つまり、基本クラスから継承する場合、基本クラスを変更または修正する必要はありません。
オープンとクローズの原則について詳しくは、こちらをご覧ください。
リスコフの代替原則
Liskovの置換の原則では、基本クラスが使用される場所であればどのサブクラスでも置換できると述べています。これは、基本クラスまたはサブクラスを持つクラスを使用するコード内の場所がある場合、コードを壊したり変更したりせずに、そのサブクラスを使用できることを意味します。基本クラスをそのサブクラスのいずれかの実装で置き換える場合、違いを生じさせたり、エラーやエラーを作成したりしないでください。この原則により、継承ツリーが実際に正しい継承関係に従い、基本クラスからコピー関数に拡張するだけでなく、継承階層を考慮するように強制します。
リスコフの代替原則について詳しくは、こちらをご覧ください。
インターフェース分離原理
インターフェース分離の原則では、クラスが、使用しないインターフェースやメソッド、またはこの場合は実現不可能なインターフェースやメソッドを実装するように強制されるべきではないと述べています。OOPのコンテキストでコーディングする場合、通常はポリモーフィズムが使用されるため、多くの異なる具体的な実装で共通コードを使用できます。ただし、これにより、クラスがインターフェイスを実装してポリモーフィズムを許可する場合がありますが、これは実際には意味がありません。たとえば、連絡先情報を処理するクラスは、その人の給与または時給を処理するクラスまたはインターフェースから実装しないでください。インターフェース分離の原則に違反するもう1つの理由は、インターフェースに含まれるメソッドが多すぎるためです。2つのメソッド「talk」と「fly」の実装を強制できるインターフェースがあると仮定します。これら2つのメソッドは、異なるタイプの鳥に使用されます。ただし、一部の鳥は飛行できないため、Dodo鳥のクラスを作成する場合は、このインターフェースから実装し、この場合は意味のない「fly」メソッドの実装を強制されます。これは、各インターフェイスが1つのメソッドのみを持つべきであるという意味ではありません。インターフェースを妥当なサイズのコンポーネントに分解することは難しいことであり、おそらくコードベースを後でリファクタリングすることになります。物理コンポーネントのシステム設計パターンは、インターフェース分離の原則の良い例です。
インターフェイスの分離の原理について詳しくは、こちらをご覧ください。
依存関係の原則
依存関係の逆転の原則では、どのエンティティも具体的な実装ではなく抽象に依存する必要があります。つまり、依存関係の具体的な実装ではなく、ポリモーフィズムを使用して、クラスをインターフェイスまたは抽象クラスに依存させる必要があります。これにより、基本クラスをリファクタリングしなくても、特定の実装を簡単に交換できます。これは便利なルールですが、コードベースの具象クラスごとにインターフェイスを作成できるため、すぐに制御できなくなります。
依存関係の逆転の原理について詳しくは、こちらをご覧ください。
SOLIDの原則は従うべき重要なルールです。これにより、コードベースの維持、拡張、悪臭の回避が容易になります。ただし、これらの原則のいずれかを採用して実行すると、実際にはコードベースが悪化します。たとえば、コードを完全に変更しないままにしておくと、リファクタリングや機能の変更が防止され、すべての具象クラスがインターフェイスに依存するようになり、管理する必要のある巨大なコードベースにつながります。重要なことは、可能な原則に完全に従うことができない場合は、コードベースを確認することです。多くのソフトウェア関連のヒントとテクニックと同様に、厳密に従わなければならない厳密なシステムではなく、優れたガイドラインとして扱います。
投稿はもともとhttps://acroynon.comに投稿されました
から：https://dev.to//acroynon/the-solid-principles-15a5
