C# のオブジェクト指向設計の 7 つの原則の紹介

1: Single Responsibility Principle (SRP)

1. 定義: オブジェクトには単一の責任のみが含まれるべきであり、その責任はクラスに完全にカプセル化されています

または: クラスに関する限り、それは次のとおりです。その変化の原因の一つ。

2. 分析: クラス (またはモジュールほど大きいかメソッドのように小さい) が負う責任が大きければ大きいほど、そのクラスが再利用される可能性は低くなり、クラスが負う責任が多すぎる場合、それは分割に相当します。これらの責任が組み合わさって、いずれかの責任が変更されると、他の責任の運用に影響を与える可能性があります。 クラスの責任には、主にデータ責任と動作責任の 2 つの側面が含まれます。データ責任はその属性を通じて反映され、動作責任はそのメソッドを通じて反映されます。 単一責任の原則は、多くのコード リファクタリング手法で見られるもので、クラスのさまざまな責任を発見し、それらを分離する必要があります。クラスの複数の責任を発見するには、設計者に強力な分析能力と設計能力、および関連するリファクタリングの経験が必要です。

3. 例:

例の説明 Java ベースの C/S システムの「ログイン機能」は、次のログイン クラス (Login) を通じて実装されます。
ここで、単一責任原則を使用して再構築されます。

2: オープンクローズ原則 (OCP)

1. 定義: ソフトウェアエンティティは拡張に対してオープンであり、変更に対してクローズである必要があります。つまり、モジュールを設計する際には、モジュールを変更せずに拡張する必要があります。つまり、ソースコードを変更せずにモジュールの動作を変更できます。

2. 分析: 開閉の原則は、1988 年に Bertrand Meyer によって提案されました。これは、オブジェクト指向設計における最も重要な原則の 1 つです。オープンクローズ原則の定義では、ソフトウェア エンティティは、ソフトウェア モジュール、複数のクラスで構成される部分構造、または独立したクラスを指すことができます。抽象化はオープン/クローズの原則の鍵です。 開閉の原理は、より具体的な「変動のカプセル化の原理」(EVP) によって説明することもできます。変動のカプセル化の原理では、システムの変動要因を見つけてカプセル化する必要があります。

3: リスコフ置換原理 (LSP)

1. 定義: 型 S のすべてのオブジェクト o1 に対して、型 T のオブジェクト o2 が存在し、すべてのプログラム P が T で定義されている場合、すべてのオブジェクト o1 が o2 に置き換えられます。 、プログラム P の動作が変わらない場合、型 S は型 T のサブタイプです

または: 基本クラス (親クラス) を参照するすべての場所は、そのサブクラスを透過的に使用できる必要があります オブジェクト。

2. 分析: リスコフ置換原理は、2008 年チューリング賞受賞者であり、米国初のコンピューターサイエンス博士であり、MIT の教授であるバーバラ・リスコフとカーネギーメロン大学のジャネット・ウィング教授によって 1994 年に提案されました。

リスコフ置換原則は、一般的な方法で表現できます。つまり、ソフトウェアで基本クラス オブジェクトを使用できる場合は、そのサブクラス オブジェクトも使用できる必要があります。基本クラスがそのサブクラスで置き換えられた場合、プログラムはエラーや例外を生成しません。逆に、ソフトウェア エンティティがサブクラスを使用する場合は、基本クラスを使用できない可能性があります。リスコフ置換原則は、開始および終了原則を実装するための重要な方法の 1 つです。サブクラス オブジェクトは、基本クラス オブジェクトが使用される場所であればどこでも使用できるため、プログラム内でオブジェクトを定義するために基本クラスの型を使用し、実行時にそれらを使用するようにしてください。サブクラス タイプを決定し、親クラス オブジェクトをサブクラス オブジェクトに置き換えます。

4: 依存関係逆転原則 (DIP)

1. 定義: 高レベルのモジュールは低レベルのモジュールに依存すべきではなく、すべて抽象化に依存する必要があります。抽象化は詳細に依存すべきではなく、詳細は抽象化に依存すべきです

または: 実装ではなくインターフェイス用のプログラム。 (実装ではなく、インターフェイスに対するプログラムです。)

2. 分析: 依存性逆転の原則は、1996 年に Robert C. Martin が「C++ Reporter」のために書いた Engineering Notebook の 3 番目のコラムであり、後に彼のコラムに追加されました。 2002 年に出版された古典的な書籍『アジャイル ソフトウェア開発、原則、パターン、実践』で。

簡単に言うと、依存関係逆転の原則は、コードは具象クラスではなく抽象クラスに依存する必要があること、プログラミングは具象クラス用のプログラミングではなく、インターフェイスまたは抽象クラス用に行う必要があることを意味します。 開閉原理を実現するための鍵は抽象化であり、具体的な実装は抽象化から導き出されます。開閉原理がオブジェクト指向設計の目標である場合、依存関係反転原理はオブジェクト指向設計の主な方法です。

依存関係逆転の原則を実装する一般的な方法の 1 つは、コード内で抽象クラスを使用し、構成ファイル内に具象クラスを配置することです。

クラス間の結合

ゼロ結合関係

具体的な結合関係

抽象的な結合関係

依存関係逆転の原理では、クライアントが抽象的な結合に依存することが依存関係逆転の原理の鍵となります。

依存関係の注入

コンストラクターの注入: コンストラクターを通じてインスタンス変数を注入します。

Setter Injection: Setter メソッドを通じてインスタンス変数を注入します。

インターフェイスインジェクション: インターフェイスメソッドを通じてインスタンス変数を注入します。

5: インターフェース分離原則 (ISP)

1. 定義: クライアントは、必要のないインターフェースに依存すべきではありません。この定義におけるインターフェースは、定義されたメソッドを指すことに注意してください。

または: インターフェースが大きすぎる場合は、インターフェースを使用するクライアントはそれに関連するメソッドを知るだけで済みます。

2. 分析: インターフェイス分離の原則は、単一の完全なインターフェイスを使用するのではなく、複数の特殊なインターフェイスを使用することを指します。各インターフェイスは比較的独立した役割を担うべきであり、それ以上でもそれ以下でもなく、実行すべきことはすべて実行する必要があります。

(1) インターフェイスは 1 つの役割のみを表し、各役割は独自の特定のインターフェイスを持ちます。この原則は「役割分離原則」と呼ぶことができます。

(2) インターフェースは、クライアントが必要とする動作、つまり、クライアントが必要としない動作のみを提供する必要があります。大きな合計インターフェース。

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​に/インターフェイス外のメソッドは単一責任の原則を満たしている必要があり、インターフェイス内で関連する一連の操作を定義する必要があります。また、高い凝集性を満たすことを前提として、インターフェイス内のメソッドは少ないほど良いです。 システムの設計時にカスタマイズされたサービスを使用できます。つまり、クライアントごとに異なる幅のインターフェイスを提供し、ユーザーが必要とする動作のみを提供し、ユーザーが必要としない動作を非表示にすることができます。

6: 複合再利用原則 (CRP)、合成/集合体再利用原則 (CARP) とも呼ばれます

1. 定義: 複雑さの目的を達成するために、継承の代わりにオブジェクトの組み合わせを使用するようにしてください。 (再利用メカニズムとして、継承よりもオブジェクトの合成を優先します。)

2. 分析: 合成と再利用の原則は、関連付け関係 (結合関係や集約関係を含む) を通じて、一部の既存のオブジェクトを新しいオブジェクトで使用することを意味します。新しいオブジェクトのメソッドを委任して呼び出すことで、新しいオブジェクトは既存の関数を再利用するという目的を達成します。つまり、構成/集計関係をできるだけ使用し、継承の頻度を減らします。

オブジェクト指向設計では、2 つの基本的な方法、つまり合成/集約関係または継承を通じて、既存の設計と実装を異なる環境で再利用できます。
継承と再利用: 実装が簡単で、拡張も簡単です。システムのカプセル化を破棄します。基本クラスから継承された実装は静的であり、実行時に変更できず、限られた環境でしか使用できません。 (「ホワイト ボックス」の再利用)

構成/集約の再利用: 結合度は比較的低く、メンバー オブジェクトの操作は選択的に呼び出され、実行時に動的に実行できます。 (「ブラック ボックス」再利用)
組み合わせ/集約によりシステムの柔軟性が高まり、クラス間の結合が減少し、1 つのクラスでの変更が他のクラスに与える影響が比較的少ないため、実装には通常、組み合わせ/集約を使用することが推奨されます。 ; 次に、継承を考慮します。継承を使用する場合は、リスコフ置換原則に厳密に従う必要があります。継承を効果的に使用すると、問題が理解され、複雑さが軽減されます。一方、継承を乱用すると、システムの構築と保守が難しくなります。システムは複雑なので、継承の再利用は慎重に使用する必要があります。

7: デメテルの法則 (LoD)、最小知識原則 (LKP) とも呼ばれます

1. 定義:

(1) 「見知らぬ人」と話さないでください。英語の定義は、「見知らぬ人と話さないでください。

(2) 直接の友達とのみコミュニケーションを取りましょう。」です。英語の定義は次のとおりです: 直接の友人とのみ話してください。

(3) 各ソフトウェア ユニットは他のユニットについての最小限の知識を持ち、そのユニットと密接に関連するソフトウェア ユニットに限定されます。英語の定義は次のとおりです: 各単元は他の単元について限られた知識のみを持つ必要があります: 現在の単元に「密接に」関連する単元のみです。

2. 分析: デメテルの法則は、19 年の秋に米国のノースイースタン大学で行われた研究に由来します。 1987年。「デメテル」研究プロジェクト。簡単に言えば、デメテルの法則は、ソフトウェア エンティティは他のエンティティとの対話をできるだけ少なくする必要があることを意味します。このように、1 つのモジュールが変更された場合、他のモジュールへの影響は最小限に抑えられ、拡張は比較的容易になります。これは、ソフトウェア エンティティ間の通信の幅と深さを制限する必要があります。

以上がC# のオブジェクト指向設計の 7 つの原則の紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。