記事のディレクトリ
1.まとめ
デザインパターンは、前任者のコード開発経験の要約であり、一連のルーチンであり、文法的な規制ではなく、コードの再利用性、保守性、可読性、および安全性を向上させるためのソリューションです。
1995年、GoFは23のデザインパターンを含む本「DesignPatterns」を出版しました。それ以来、デザインパターンの分野におけるマイルストーンが確立されました。
1.1デザインパターンの種類
- 作成モード
- 構造モデル
- 行動モデル
クリエーターパターン
これらのデザインパターンは、新しいオペレーターでオブジェクトを直接インスタンス化する代わりに、オブジェクトの作成中に作成ロジックを非表示にする方法を提供します。これにより、プログラムは、特定のインスタンスに対して作成する必要のあるオブジェクトをより柔軟に決定できます。
構造パターン
これらのデザインパターンは、クラスとオブジェクトの組み合わせに焦点を当てています。継承の概念は、インターフェイスを組み合わせ、組み合わせたオブジェクトが新しい関数を取得する方法を定義するために使用されます。
動作パターン
これらのデザインパターンは、オブジェクト間の通信に特別な注意を払っています。
1.2デザインパターンの原則
1.オープンクローズ原則
開閉の原則は、拡張のために開き、変更のために閉じることを意味します。プログラムを拡張する必要がある場合、ホットスワップ可能な効果を実現するために元のコードを変更することはできません。つまり、プログラムを拡張可能にし、保守とアップグレードを容易にすることです。この効果を実現するには、インターフェイスと抽象クラスを使用する必要があります。これについては、後で特定の設計で説明します。
2.リスコフの置換原則
リヒター置換原則は、オブジェクト指向設計の基本原則の1つです。リヒター置換原則は、基本クラスが出現する可能性がある場合は常に、サブクラスが出現する必要があると述べています。LSPは継承と再利用の基礎であり、派生クラスが基本クラスを置き換えることができ、ソフトウェアユニットの機能に影響がない場合にのみ、基本クラスを実際に再利用でき、派生クラスはそれに基づいて新しいクラスを追加することもできます。基本クラスの動作。リヒター置換原則は、開始と終了の原則を補足するものです。開閉の原則を実現するための重要なステップは抽象化であり、基本クラスとサブクラス間の継承関係は抽象化の具体的な実現であるため、リヒター置換原則は抽象化を実現するための具体的なステップの指定です。
3.依存性逆転の原則
この原則は、開始と終了の原則、特定のコンテンツの基礎です。インターフェイスプログラミングでは、具体的ではなく抽象化に依存します。
4.インターフェイス分離の原則
この原則は、単一のインターフェースを使用するよりも、複数の分離されたインターフェースを使用する方が優れていることを意味します。また、別の意味もあります。クラス間の結合度を下げることです。実際、デザインパターンは、大規模なソフトウェアアーキテクチャから始まり、アップグレードと保守が容易なソフトウェアデザインのアイデアであり、依存関係の削減と結合の削減に重点を置いていることがわかります。
5.デメテルの法則、デメテルの法則としても知られています
最も知られていない原則は、システムの機能モジュールを比較的独立させるために、エンティティが他のエンティティとの対話をできるだけ少なくする必要があることを意味します。
6.複合再利用の原則
コンポジションの再利用の原則は次のとおりです。継承の代わりにコンポジション/アグリゲーションを使用してみてください。
2.シンプルなファクトリモデル
電卓の例を通して。プログラミングにオブジェクト指向のアイデアを使用する方法を説明するため。
2.1最初に最も単純な例を見てください
Console.WriteLine("请输入数字A");
string A = Console.ReadLine();
Console.WriteLine("请输入运算符号");
string B = Console.ReadLine();
Console.WriteLine("请输入数字B");
string C = Console.ReadLine();
string D = "0";
if (B == "+")
{
D = Convert.ToString(Convert.ToDouble(A) + Convert.ToDouble(B));
}
if (B == "-")
{
D = Convert.ToString(Convert.ToDouble(A) - Convert.ToDouble(B));
}
if (B == "*")
{
D = Convert.ToString(Convert.ToDouble(A) * Convert.ToDouble(B));
}
if (B == "/")
{
D = Convert.ToString(Convert.ToDouble(A) / Convert.ToDouble(B));
}
Console.WriteLine($"运算完成后的结果是{D}");
2.2上記のコードの問題
1.この命名方法のコードは非常に不規則です。
string A = Console.ReadLine();
2.判断の分岐、これは各条件の判断を行うことに相当します。これは、コンピューターによる3つの無駄な作業に相当します。
if (B == "+")
{
D = Convert.ToString(Convert.ToDouble(A) + Convert.ToDouble(B));
}
3.除数が0の場合、または記号が正しく入力されていない場合はどうすればよいですか？エラー処理メカニズムなし
if (B == "/")
{
D = Convert.ToString(Convert.ToDouble(A) / Convert.ToDouble(B));
}
4.オブジェクト指向思考を使用しなかった（例として活字印刷を取り上げる）
- 保守性：変更したい場合は、変更したい単語を変更するだけです。
- 再利用性：以前に使用できたすべての単語を再利用します
- スケーラビリティ：単語を追加する場合は、レタリングを追加するだけで済みます
- 優れた柔軟性：単語の並べ替えは、水平方向または垂直方向のいずれかに配置する必要がある場合があります
2.3オブジェクト指向の考え方
オブジェクト指向の設計アイデアを使用する場合は、カプセル化、継承、およびポリモーフィズムの使用を十分に検討して、プログラムの結合度を減らす必要があります。
2.3.1コピーと再利用
上記のプログラムはコマンドラインを使用して完了します。以下の計算機を使用してこのような機能を完了したい場合、コードの再利用を実現するにはどうすればよいですか？
内部のコードをコピーするだけです。これだけでは不十分です。このアプローチはコピーと呼ばれ、再利用ではありません。
2.3.2ビジネスのカプセル化
カプセル化を使用すると、ビジネスロジックとインターフェイスロジックを分離し、それらの間の結合を減らすことができるため、統合、保守、および拡張の目的を達成できます。
public class Operation {
public static double GetResult(double numberA, double numberB, string operate)
{
double result = 0;
switch (operate)
{
case "+":
result = numberA + numberB;
break;
case "-":
result = numberA - numberB;
break;
case "*":
result = numberA * numberB;
break;
case "/":
result = numberA / numberB;
break;
}
return result;
}
}
2.3.3密結合と疎結合
上記のコードに基づいて、別のルートを開く操作を追加した場合、それをどのように使用しますか？無差別に、スイッチにブランチを追加するだけで、操作クラスを直接変更できます。問題は、元の加算、減算、乗算、除算の計算が正しいことです。変更プロセス中に元の乗算を加算に変更すると、元の関数を変更するのと同じになり、効果が大幅に減少します。
現時点では、仮想メソッドとしてGetRestultを作成する必要があります
参照
[1] https://www.runoob.com/design-pattern/design-pattern-intro.html