目次
習得した知識ポイント
- デザインパターンの3つのカテゴリーとは何ですか?
- 各カテゴリにはどのような具体的なデザインパターンが含まれるか
創造的
作成パターンはオブジェクトのインスタンス化プロセスを抽象化したもので、抽象クラスで定義されたインターフェイスを通じてシステム内でオブジェクトがどのように作成され結合されるかなどの情報をカプセル化します。
作成モードは主にオブジェクトの作成に使用されるため、ソフトウェア モジュールはオブジェクトの作成に関連しません。
含まれるデザインパターンは次のとおりです。
- 抽象的な工場パターン
- ビルダーモード
- ファクトリメソッドパターン
- プロトタイプパターン
- シングルトンパターン
構造的
構造パターンは主に、既存のクラスとオブジェクトをアセンブルして、より大きな構造を取得するために使用されます。一般に、カプセル化、プロキシ、継承などの概念は、1 つ以上のクラスを結合およびカプセル化し、統一された外部ビューや新しい機能を提供するために使用されます。
主にクラスまたはオブジェクト間の関係の処理、クラスとオブジェクトの効果的な編成、および優れたアーキテクチャの形成を担当します。
主なモードには次のものがあります。
- アダプターパターン
- ブリッジモード
- コンビネーションモード
- デコレータパターン
- 外観モード
- フライウェイトモード
- プロキシモード
行動的
このモードは主に、オブジェクトと提供されるサービスの間の責任の割り当てに使用されます。オブジェクトまたはクラスのモードを記述するだけでなく、それらの間の通信モード、特にピア オブジェクトのグループが相互に連携して完了する方法についても記述します。どちらの主体も単独では達成できない任務です。
主にクラスとオブジェクト間の相互作用を扱い、クラスとオブジェクトに責任を割り当てる方法を説明します。
主なモードには次のものがあります。
- 責任連鎖モデル
- コマンドモード
- 通訳モード
- イテレータパターン
- メディエーターパターン
- メモモード
- オブザーバーパターン
- ステートモード
- 戦略パターン
- テンプレートメソッドパターン
- 訪問者のパターン
例：
従来の構造化ソフトウェア設計手法はオブジェクト指向設計原則に準拠していないため、高い凝集性と低い結合性の要件を十分に満たすことができず、モジュールが近すぎるため、ソフトウェアの拡張と保守に多くの困難が生じます。ケース デザインパターンの出現と広範な適用は、問題を解決するための効果的な方法を提供します. デザインパターンを使用することにより、開発者は既存の設計手法を使用して、合理的な構造、容易な再利用および保守性を備えたソフトウェアを設計できます. ユーザーのニーズが変化した場合、新しいニーズを実現できます少量のコードを変更するか、元のコードを変更せずに、この要件を満たします。これにより、システムの変更可能性と安定性が向上し、システム開発コストが削減されます。
動作タイプであるストラテジーは、一連のアルゴリズムを定義し、それらを 1 つずつカプセル化して交換可能にし、アルゴリズムを使用するユーザーとは独立して変更できるようにします。監視モジュールのアラーム機能では、監視する各ソフトウェアのフロントエンド インターフェイスでアラーム情報を受信するようにユーザーが設定できます。たとえば、DingTalk にはデフォルトで SMS、WeChat、電話の音声も含まれています。タスクが異常であり、アラーム送信の要件を満たしている場合、バックエンド コードはユーザーが設定した情報を取得し、指定されたストラテジを呼び出して、設定情報に従ってアラーム情報を送信します。具体的な実装は次のとおりです。まず基本クラス AlarmSender を抽象化し、サブクラスは基本クラス DingSender(AlarmSender)、クラス SMSSender (AlarmSender) などを拡張し、サブクラスに特定の実装 def send(self, info) を定義します。 RabbitMQ アラームとユーザーがデフォルトの釘付け方法を設定します。アラームを送信するときのコードは、mq_ins = MQInfo(info='alarm content', way=[DingSender]) をインスタンス化します。way はアラームを送信する具体的な方法です。 mq_ins.way.send(info) を呼び出してアラームの送信を完了します。このモードを利用すると、アラートの出し方（つまりアルゴリズム）を自由に切り替えられることや、アラートのクラス名をパラメータとして渡せることがわかり、これも抽象クラスを利用するメリットの一つです。インターフェイスを設計するだけでなく、コードの冗長性も削減され、拡張性が高く、移植が容易で、柔軟に使用できます。
例 2:
戦略パターン:
このシステムでは、家計の支払い機能が設計されており、現在、WeChat、Alipay、UnionPay などの多くのオンライン支払いチャネルがあります。各決済チャネルのアルゴリズムは異なります。当初は複数の条件で判定していましたが、各チャネルの決済実装に関わるアルゴリズムにも条件判定が重く含まれていました。このように定義したところ、コードが正しくないことがわかりました。分析後、戦略モードでは、最初に paystrategy インターフェイスを抽象ロールとして定義し、次に alipaystrategy、wechatpaystrategy、unicpaystrategy などの特定のロールを定義します。これらの具体的な実装クラスは、次のことをカプセル化します。支払い方法のアルゴリズム、およびこれらのクラスは paystrategy インターフェイスを実装します。Paycontextstartegy が定義されており、このクラスは paystrateg を参照します。Web が支払いをリクエストし、支払い方法の pay_code を持っている場合、コントローラはリクエストを受信した後、paycontextstartegy を使用して、alipaystategy、wechatpaystategy、uniompaystrategy などの特定の支払いクラスを呼び出します。戦略パターンを使用することで、異なる決済方法の自由な切り替え、複数の条件判断の回避、継承ではなく組み合わせの使用、アルゴリズムの選択とアルゴリズムの実装の分離、プログラム間の結合の軽減、優れた拡張性と保守性を実現します。
例 3:
Chain of Responsibility パターン: Chain of Responsibility パターンは、ハンドラーのチェーンに沿ってリクエストを送信できるようにする動作設計パターンです。リクエストを受信した後、各プロセッサはリクエストを処理するか、チェーン内の次のプロセッサにリクエストを渡すことができます。
テストプラットフォーム:
リクエスト --- パブリックパラメータ（環境情報、パブリック設定）を組み立てる --- パーソナライズされたパラメータを置き換える --- コンテキストパラメータを置き換える
