トップページ > コンテンツ > プログラミング効率化 > プログラムを作る上での考え方 > デザインパターン

ここでは、ケースごとにどのデザインパターンを検討しても良いか記録しておくことにする。

目的 目的に対応したデザインパターン
オブジェクト使用者がオブジェクト内容(どのクラスとどのクラスがペアの組み合わせなのか等)を知らずとも利用できるようにしたい。 FactoryMethod,Abstract Factory
複雑なコンストラクタ処理でクラスから外出ししたい。 Builder
大部分は一緒だけど、一部分だけ違うようなオブジェクトを楽に沢山作りたい Prototype
オブジェクトの生成数を減らしたり、再利用する等して負荷を減らしたい Singleton,Flyweight
既存のクラスをいじらずに機能を追加したい Adapter,Decorator,Proxy
機能をClassA,ClassB等に分けて実装した際に、
ClassA,ClassBのサブクラスが継承していないクラスの実装を利用したい
Bridge
枝葉のような再起的な階層構造を持つクラスをシンプルにまとめたい Composite
複数クラスを利用する際に汎用的な処理をまとめることで、
クラスの使用者側に複数クラスの処理をいちいち意識させないようにしたい
Facade
教室のクラスメイトに手紙を渡し続けるようなイメージで、
手紙に関係のある人の所へ回った時点で何らかの処理をして欲しい
Chain of Responsibility
複数の処理を命令として一つオブジェクトにまとめたい Command
構文解析したい Interpreter
オブジェクトの中身の構造を気にせずに、データを取り出したい Iterator
複数のオブジェクトの相互関係を簡易化したい Mediator
オブジェクトの状態を幾つか前の状態に戻したい(undoの実行) Memento
オブジェクトの状態変化を捉えたい Observer
オブジェクトの状態に合わせて処理を切り替えたい State
アルゴリズムや機能を交換可能にしたい Strategy,template method
拡張対象の状態によらず処理を追加したい Visitor

最終更新:2021年07月23日 09:31