I.はじめに
今日のソフトウェア開発分野は急速に進化しており、ソフトウェア システムはますます複雑になっています。その際、刻々と変化する要件やビジネスシナリオに直面して、ソフトウェア開発をいかに迅速かつ効率的に完了させるかが重要な課題となっています。広く使用されているソリューションとして、デザイン パターンはベスト プラクティスを表します。これらのソリューションは、多数のソフトウェア開発者によるかなりの期間にわたる試行錯誤の結果であり、通常は経験豊富なオブジェクト指向ソフトウェア開発者によって採用されます。
デザイン パターンは、繰り返し使用され、ほとんどの人に知られ、要約された一連のコード設計エクスペリエンスです。デザイン パターンは、コードを再利用し、他の人がコードを理解しやすくし、コードの信頼性を確保するために使用されます。デザイン パターンは、自分自身、他者、およびシステムにとって Win-Win であることに疑いの余地はありません。デザイン パターンにより、コードのコンパイルが真のエンジニアリングになります。デザイン パターンは、建物のレンガや石と同じように、ソフトウェア エンジニアリングの基礎です。
プロジェクトでデザイン パターンを合理的に使用すると、多くの問題を完全に解決できます。各パターンには、現実に対応する対応する原則があります。それぞれのパターンは、私たちの周りで繰り返し発生する問題と、その問題を説明しています。核となる解決策、それがデザインの理由ですパターンは幅広く使用できます。
2. デザインパターンとは
デザインパターンを定義する
デザイン パターンは、ソフトウェア開発における長年の実践と要約を経て、特定の問題を解決するための経験的な方法です。これは、開発者がソフトウェアを設計する際によくある問題を回避し、ソフトウェアの品質と保守性を向上させるのに役立つ再利用可能なソリューションです。
GOF ギャング オブ フォー
1994 年、Erich Gamma、Richard Helm、Ralph Johnson、John Vlissidesは、「デザイン パターン - 再利用可能なオブジェクト指向ソフトウェアの要素」(中国語訳: デザイン パターン - 再利用可能なオブジェクト指向ソフトウェア要素) と呼ばれる本を共著し、次の概念を導入しました。ソフトウェア開発におけるデザインパターンを初めて学びました。
4人の著者を総称してGOF（Gang of Four）と呼びます。彼らが提案した設計パターンは、主に以下のオブジェクト指向設計原則に基づいています。
- 実装ではなくインターフェイスにプログラムします。
- 継承よりもオブジェクトの合成を優先します。
デザインパターンの目標
デザインパターンの目標には主に次の点が含まれます。
- 結合の削減: 設計パターンを使用することで、システム内のさまざまなモジュールを分離して、システムの保守性と拡張性を向上させることができます。
- 再利用性の向上: デザイン パターンは、車輪の再発明を回避し、コードの再利用性を向上させるのに役立ついくつかの一般的なソリューションを提供します。
- コードの可読性の向上: デザイン パターンは、コードを理解し、読みやすくする共通の言語と構造を提供します。
- コードの保守性: 各モジュールが分離されているため、コードの保守が容易になります。
- エラーの削減: デザイン パターンは、よくある間違いを回避するのに役立つ実証済みのベスト プラクティスであるため、デザイン パターンを使用すると、コードのエラー率を減らすことができます。
- 効率: デザイン パターンは広く認識されているため、コードの効率とパフォーマンスを向上させるために最適化されてきました。
3. デザインパターンの6原則
設計パターンは、開発者が高品質で保守可能で再利用可能なソフトウェア システムを構築するのに役立つ厳格な原則に基づいています。6 つの設計原則を紹介します
1. 単一責任原則 (SRP)
単一責任の原則とは、クラスが 1 つの機能領域における対応する責任に対してのみ責任を負うことを意味します。あるいは、単純に、クラスは 1 つのことだけを実行すると言うこともできます。クラスを担当する機能が複雑すぎる場合は、コードの再利用とメンテナンスを実現するために、クラスを複数のクラスに分割し、各クラスが 1 つの機能領域内の対応する責任のみを担当する必要があります。
2. オープンアンドクローズ原則 (OCP)
オープンクローズの原則は、ソフトウェア エンティティは拡張に対してオープンであり、変更に対してクローズである必要があることを意味します。つまり、システムを設計する際には、元のコードの変更は避け、拡張機能によって新しい機能を実装する必要があります。
3. リスコフ置換原理 (LSP)
リスコフ置換原則は、オブジェクト指向設計の基本原則の 1 つです。リスコフ置換原則は、基本クラスが出現できる場所には必ずサブクラスが出現しなければならないことを意味します。つまり、サブクラスはプログラム内の任意の場所で親クラスを置き換えることができ、プログラムの論理動作は変更されないことが保証されます。LSP は継承再利用の基礎です。派生クラスが基本クラスを置き換えることができ、ソフトウェア ユニットの機能に影響がない場合にのみ、基本クラスを真に再利用でき、派生クラスは継承に基づいて新しいクラスを追加することもできます。基本クラスの動作。
4. 依存関係逆転原理 (DIP)
この原則は、オープンとクローズの原則の基礎であり、依存性逆転の原則は、高レベルのモジュールが低レベルのモジュールに依存すべきではなく、両方が抽象化に依存すべきであることを意味します。抽象インターフェイスは具体的な実装に依存すべきではなく、具体的な実装は抽象インターフェイスに依存する必要があります。簡単に言うとインターフェースのプログラミングであり、実装クラスを呼び出す代わりにプログラムが直接インターフェースを呼び出すことで、クライアントと実装モジュールの結合度が低くなります。
5. インターフェース分離原則 (ISP)
インターフェイス分離の原則は、クライアントが必要のないメソッドを実装する必要がないように、インターフェイス内のさまざまなタイプのメソッドを分離および分離することを指します。言い換えれば、あるクラスの別のクラスへの依存関係は最小のインターフェイス上で確立される必要があり、インターフェイスにはクライアントが必要とするメソッドのみが含まれるように、インターフェイスをできるだけ小さく、より具体的なインターフェイスに分割する必要があります。
6. デメテルの法則 (LoD)
オブジェクトは他のオブジェクトとの対話をできる限り少なくし、クラス間の結合をできる限り減らす必要があります。最小知識の原理としても知られる最小知識は、オブジェクトが他のオブジェクトについてできる限り知識が少ないことを意味します。
第四に、デザインパターンの分類
デザインパターンは、創造パターン、構造パターン、行動パターンの3種類に分類できます。
創作パターン
このタイプのパターンは、オブジェクトを作成するためのメカニズムを提供し、既存のコードの柔軟性と再利用性を向上させることができます。
| シリアルナンバー | タイプ | 説明 |
|---|---|---|
| 1 | ファクトリメソッドパターン | オブジェクトを作成するためのインターフェイスを定義し、そのサブクラスにどのファクトリ クラスをインスタンス化するかを決定させます。ファクトリ モードでは、サブクラスへの作成プロセスが遅延されます。 |
| 2 | 抽象的な工場パターン | 具体的なクラスを指定せずに、一連の関連オブジェクトまたは相互依存オブジェクトを作成するためのインターフェイスを提供します。 |
| 3 | シングルトンパターン | クラスのインスタンスが 1 つだけであることを保証し、そのインスタンスへのグローバル アクセス ポイントを提供します。 |
| 4 | ビルダーパターン | 複雑なビルドをその表現から分離すると、同じビルド プロセスで異なる表現を作成できるようになります。 |
| 5 | 試作パターン | プロトタイプ インスタンスを使用して、作成するオブジェクトのタイプを指定し、これらのプロトタイプをコピーして新しいオブジェクトを作成します。 |
構造パターン
これらのパターンは、構造を柔軟かつ効率的に保ちながら、オブジェクトとクラスをより大きな構造に組み立てる方法を記述します。
| シリアルナンバー | タイプ | 説明 |
|---|---|---|
| 1 | アダプターのパターン | クラスのインターフェイスをクライアントが必要とする別のインターフェイスに変換します。アダプター パターンを使用すると、インターフェイスに互換性がないために連携できないクラスが連携できるようになります。 |
| 2 | ブリッジパターン | 抽象化を実装から分離して、両方が独立して変更できるようにします。 |
| 3 | 複合パターン¶ | オブジェクトをツリー構造にグループ化して、「部分と全体」の階層を表します。複合モードを使用すると、ユーザーは単一オブジェクトと複合オブジェクトを一貫した方法で使用できます。 |
| 4 | デコレータパターン | 追加の責任をオブジェクトに動的に追加します。機能の追加という点では、デコレータ パターンはサブクラスを生成するよりも柔軟です。 |
| 5 | ファサードパターン | ファサード モードは、サブシステム内の一連のインターフェイスに一貫したインターフェイスを提供し、サブシステムを使いやすくする高レベルのインターフェイスを定義します。 |
| 6 | フライウェイトパターン | 共有テクノロジーを使用して、粒度の細かい多数のオブジェクトを効率的にサポートします。 |
| 7 | プロキシパターン | このオブジェクトへのアクセスを制御するために、他のオブジェクトにプロキシを提供します。 |
行動モデル
これらのパターンは、オブジェクト間の効率的な通信と責任の委任を担っています。
| シリアルナンバー | タイプ | 説明 |
|---|---|---|
| 1 | 責任連鎖パターン | リクエストの送信側と受信側を結合することを避け、複数のオブジェクトがリクエストを受信できるようにし、これらのオブジェクトをチェーンに接続し、オブジェクトがリクエストを処理するまでこのチェーンに沿ってリクエストを渡します。 |
| 2 | コマンドパターン | リクエストをオブジェクトにカプセル化し、さまざまなリクエストでクライアントをパラメータ化できるようにします。 |
| 3 | イテレータパターン | オブジェクトの内部表現を公開せずに、集約オブジェクトの要素に順次アクセスする方法を提供します。 |
| 4 | メディエーターパターン | 中間オブジェクトは、一連のオブジェクトの相互作用をカプセル化するために使用されます。中間オブジェクトにより、オブジェクトが相互に明示的に参照する必要がなくなり、結合が緩くなり、オブジェクト間の相互作用を独立して変更できます。 |
| 5 | メメントパターン | オブジェクトの内部状態をキャプチャし、カプセル化を壊さずにその状態をオブジェクトの外部に保存します。 |
| 6 | オブザーバーパターン | オブジェクト間の 1 対多の依存関係を定義します。オブジェクトの状態が変化すると、そのオブジェクトに依存するすべてのオブジェクトが通知され、自動的に更新されます。 |
| 7 | 状態パターン | オブジェクトの内部状態が変化したときにオブジェクトの動作を変更できるようにし、オブジェクトがそのクラスを変更しているように見えます。 |
| 8 | 戦略パターン | 一連のアルゴリズムを定義し、それらを 1 つずつカプセル化し、交換可能にします。 |
| 9 | テンプレートメソッドパターン | 一部のステップをサブクラスに延期して、操作内のアルゴリズムのスケルトンを定義します。テンプレート メソッドを使用すると、アルゴリズムの構造を変更せずに、サブクラスでアルゴリズムのいくつかの特定のステップを定義できます。 |
| 10 | 訪問者のパターン | これは主にデータ構造をデータ操作から分離するため、オブジェクト構造を変更せずに新しい操作を追加できます。 |
| 11 | インタプリタパターン | 言語の文法を定義し、その言語の文を解釈するインタープリターを構築します。適用範囲が狭いです。 |
V. 結論
創作は簡単ではありません。この記事が役に立ったら、いいね、ブックマーク、注目をお願いします。皆様のご支援、励ましが創作の最大の原動力です。
