Loading article…
ソフトウェア エンジニアリングにおいて、創造的デザイン パターンは、オブジェクト作成メカニズムを扱い、状況に適した方法でオブジェクトを作成しようとするデザインパターンです。オブジェクト作成の基本的な形式では、作成手順の柔軟性がないため、設計上の問題が発生したり、設計が複雑になったりする可能性があります。創造的デザイン パターンは、このオブジェクト作成を何らかの方法で制御することでこの問題を解決します。
概要
創造的デザインパターンは、2つの主要なアイデアで構成されています。1つは、システムが使用する具体的なクラスに関する知識をカプセル化することです。もう1つは、これらの具体的なクラスのインスタンスがどのように作成され、結合されるかを隠すことです。[1]
創造的デザインパターンは、さらにオブジェクト作成パターンとクラス作成パターンに分類されます。オブジェクト作成パターンはオブジェクトの作成を扱い、クラス作成パターンはクラスのインスタンス化を扱います。詳しくは、オブジェクト作成パターンはオブジェクト作成の一部を別のオブジェクトに委ねますが、クラス作成パターンはオブジェクト作成をサブクラスに委ねます。[2]
創造的パターンの一部である5つのよく知られたデザインパターンは、
- 抽象ファクトリーパターンは、オブジェクトの具体的なクラスを指定せずに関連または依存するオブジェクトを作成するためのインターフェースを提供します。[3]
- ビルダー パターンは、複雑なオブジェクトの構築とその表現を分離し、同じ構築プロセスで異なる表現を作成できるようにします。
- ファクトリーメソッドパターンは、クラスのインスタンス化をサブクラスに延期することを可能にします。[4]
- プロトタイプ パターンは、プロトタイプ インスタンスを使用して作成するオブジェクトの種類を指定し、このプロトタイプを複製して新しいオブジェクトを作成します。
- シングルトンパターンは、クラスがインスタンスを1つだけ持つことを保証し、そのインスタンスへのグローバルなアクセスポイントを提供します。[5]
意味
創造パターンは、システムとそのオブジェクトの作成、構成、表現方法を切り離すことを目的とします。これにより、オブジェクトの作成内容、作成者、作成方法、作成時期に関してシステムの柔軟性が向上します。 [6]
使用法
現代のソフトウェアエンジニアリングは、クラスの継承よりもオブジェクトの構成に大きく依存しているため、ハードコーディングされた動作から、より複雑な動作に構成できる基本的な動作の小さなセットを定義することへと重点が移っています。 [7]ハードコーディングされた動作は、設計の一部を変更するために全体をオーバーライドまたは再実装する必要があるため、柔軟性がありません。さらに、ハードコーディングは再利用を促進せず、エラーを追跡するのが難しくなります。これらの理由から、ハードコーディングされた動作よりも創造的パターンの方が有用です。創造的パターンは、設計をより柔軟にします。これらは、具体的なクラス内の明示的な参照を、それらをインスタンス化する必要があるコードから削除するさまざまな方法を提供します。[8]言い換えれば、オブジェクトとクラスの独立性を作成します。
次の場合には創造パターンの適用を検討してください。
- システムは、そのオブジェクトや製品がどのように作成されるかには依存しません。
- 関連するオブジェクトのセットは、一緒に使用するように設計されています。
- クラス ライブラリまたは製品の実装を非表示にして、インターフェイスのみを公開します。
- 独立した複雑なオブジェクトの異なる表現を構築します。
- クラスは、作成したオブジェクトをサブクラスで実装することを望みます。
- クラスのインスタンス化は実行時に指定されます。
- インスタンスは 1 つだけ存在し、クライアントは常にこのインスタンスにアクセスできる必要があります。
- インスタンスは変更せずに拡張可能である必要があります。
構造
以下は、ほとんどの作成パターンに共通する単純なクラス図です。作成パターンが異なると、参加するクラスがさらに異なる必要があることに注意してください。
参加者：
- Creator : オブジェクト インターフェイスを宣言します。オブジェクトを返します。
- ConcreteCreator : オブジェクトのインターフェースを実装します。
例
創造的デザイン パターンの例には次のようなものがあります。
- 抽象ファクトリパターン: クラスはオブジェクトを直接作成するのではなく、ファクトリオブジェクトから必要なオブジェクトを要求します。
- ファクトリメソッドパターン: 複数の実装から1つを選択して、特定のタイプのオブジェクトの作成を集中化します。
- ビルダーパターン: 複雑なオブジェクトの構築とその表現を分離し、同じ構築プロセスで異なる表現を作成できるようにします。
- 依存性注入パターン: クラスはオブジェクトを直接作成するのではなく、インジェクタから必要なオブジェクトを受け入れます。
- 遅延初期化パターン: オブジェクトの作成、値の計算、またはその他のコストのかかるプロセスを、最初に必要になるまで遅らせる戦術
- オブジェクト プール パターン: 使用されなくなったオブジェクトをリサイクルすることで、コストのかかるリソースの取得と解放を回避します。
- プロトタイプ パターン: 作成するオブジェクトのタイプがプロトタイプ インスタンスによって決定され、そのインスタンスが複製されて新しいオブジェクトが生成される場合に使用されます。
- シングルトンパターン: クラスのインスタンス化を1つのオブジェクトに制限する
参照
参考文献
- ^ ガンマ、エリック; ヘルム、リチャード; ジョンソン、ラルフ; ブリシデス、ジョン (1995)。デザインパターン。マサチューセッツ州: アディソンウェスレー。p. 81。ISBN 978-0-201-63361-0. 2015年5月22日閲覧。
- ^ ガンマ、エリック; ヘルム、リチャード; ジョンソン、ラルフ; ブリシデス、ジョン (1995)。デザインパターン。マサチューセッツ州: アディソンウェスレー。ISBN 978-0-201-63361-0. 2015年5月22日閲覧。
- ^ フリーマン、エリック; フリーマン、エリザベス; シエラ、キャシー; ベイツ、バート (2004)。 ヘンドリクソン、マイク; ルーキデス、マイク (編)。 Head First Design Patterns。 カリフォルニア: O'Reilly Media。 p. 156。ISBN 978-0-596-00712-6. 2015年5月22日閲覧。
- ^ フリーマン、エリック; フリーマン、エリザベス; シエラ、キャシー; ベイツ、バート (2004)。ヘンドリクソン、マイク; ルーキデス、マイク (編)。Head First Design Patterns。カリフォルニア: O'Reilly Media。p. 134。ISBN 978-0-596-00712-6. 2015年5月22日閲覧。
- ^ フリーマン、エリック; フリーマン、エリザベス; シエラ、キャシー; ベイツ、バート (2004)。 ヘンドリクソン、マイク; ルーキデス、マイク (編)。 Head First Design Patterns。 カリフォルニア: O'Reilly Media。 p. 177。ISBN 978-0-596-00712-6. 2015年5月22日閲覧。
- ^ Judith, Bishop (2007). C# 3.0 デザインパターン. カリフォルニア: O'Reilly Media. p. 336. ISBN 978-0-596-52773-0. 2015年5月22日閲覧。
- ^ ガンマ、エリック; ヘルム、リチャード; ジョンソン、ラルフ; ブリシデス、ジョン (1995)。デザインパターン。マサチューセッツ州: アディソンウェスレー。p. 84。ISBN 978-0-201-63361-0. 2015年5月22日閲覧。
- ^ ガンマ、エリック; ヘルム、リチャード; ジョンソン、ラルフ; ブリシデス、ジョン (1995)。デザインパターン。マサチューセッツ州: アディソンウェスレー。p. 85。ISBN 978-0-201-63361-0. 2015年5月22日閲覧。