デザインパターンについてまとめた
デザインパターンについて勉強しようと思い、自分の言葉でまとめました！
何かおかしいところなどありましたらコメントお願いします！
| パターン名 | 種別 | 実装 | 使うのは | 概要 |
|---|---|---|---|---|
| Adapter | 構造 | 普通 | 簡単 | Adapter(適合)パターン。元となるクラスに手を加えずにインターフェースを変更するパターン。実装方法は継承と移譲の2パターンある。 |
| Bridge | 構造 | 簡単 | 簡単 | Bridge(橋)パターン。DIによって継承の階層を減らすパターン。継承を正しく使おうとすればこのパターンに行き着く気がする。 |
| Composite | 構造 | 簡単 | 簡単 | Composite(複合)パターン。木構造を伴う再帰的なデータ構造を実装する際に用いるパターン。Componentインターフェース、Leafクラス、Compositeクラスを作成する。入れ子集合モデルの実装を実装したものに当たる(はず)。 |
| Decorator | 構造 | 簡単 | 簡単 | Decorator(装飾者)パターン。既存クラスの振る舞いを変更せずに拡張(Decorate)するパターン。拡張したいクラスをDIする。 |
| Facade | 構造 | 簡単 | 簡単 | Facade(建物の正面)パターン。シンプルなインタフェースを定義することで複雑な処理を利用しやすくするパターン。Railsのserviceクラスはこのパターンを用いることが多い。 |
| Flyweight | 構造 | 普通 | 難しい | Flyweight(フライ級)パターン。生成したオブジェクトを再利用するパターン。インスタンス生成に時間がかかる場合、メモリを節約したい場合に有効。生成したオブジェクトの状態が変わってしまうと再利用できないため、適用できるのはイミュータブルなオブジェクトに限られる。 |
| Proxy | 構造 | 簡単 | 簡単 | Proxy(代理人)パターン。「そのクラス」の代わりに処理を受け持つクラス(Proxy)を作成するパターン。Proxyでまかないきれない場合に、「そのクラス」のインスタンスを生成して処理を委任する。 |
| Chain of Responsibility | 振る舞い | 普通 | 普通 | Chain of Responsibility(責任の連鎖)パターン。自身が処理を実行できない時に次のオブジェクトに処理の実行を任せるパターン。どこまで責任を連鎖させるかはあらかじめ定義しておく。 |
| Command | 振る舞い | 難しい | 難しい | Command(命令)パターン。Commandオブジェクトによって処理をカプセル化し、Invoker(起動者)からCommandsを実行するパターン。クライアント(利用者)はInvokerに実行の依頼をするだけでよいので、実際の処理(Command)を柔軟に変更することができる。 |
| Interpreter | 振る舞い | 難しい | 簡単 | Interpreter(通訳)パターン。なんらかのフォーマットに基づいて記述された文を解釈するパターン。たぶん、DSLの実装はこれ。 |
| Iterator | 振る舞い | 難しい | 簡単 | Iterator(反復)パターン。配列など要素の集合に対して繰り返し処理を行うパターン。要素の集合に対して順番に処理を行うので、要素の大きさがわからなくても処理を実行(実装)することができる。 |
| Mediator | 振る舞い | 普通 | 普通 | Mediator(仲裁人)パターン。複数のクラスが相互の参照し合う時にその仲介(Mediator)を作成するパターン。Facadeは一方的に利用するのに対して、Mediatorは相互に参照し合う点が異なる。 |
| Memento | 振る舞い | 普通 | 普通 | Memento(形見)パターン。その時のインスタンスの状態を保存しておいて、後から利用できるようにするパターン。Originator(作成者)がMemento(形見)を作成し、Caretaker(世話人)がMementoのリストを保持する。 |
| Observer | 振る舞い | 普通 | 普通 | Observer(観察者)パターン。通知者となるオブジェクトが発信する通知を受けて観察者(Observer)が処理を行うパターン。通知者オブジェクトに観察者オブジェクトを設定(複数可)する。通知者と観察者はお互いにインターフェースを通じてやりとりするため、具体的な実装を意識しなくてよくなる。 |
| State | 振る舞い | 簡単 | 普通 | State(状態)パターン。インスタンスが状態を持つ場合に状態による振る舞いの違いを状態インスタンスに移譲するパターン。状態による振る舞いの違いを移譲するので、条件分岐を減らすことができる。 |
| Strategy | 振る舞い | 簡単 | 簡単 | Strategy(戦略)パターン。ロジックをコンテキストによって切り替えたい時に用いるパターン。クラス図はBridgeパターンと同様だが、その目的が異なる。Bridgeパターンは構造に関するパターンで、Strategyパターンは振る舞いに関するパターン。 |
| TemplateMethod | 振る舞い | 簡単 | 簡単 | Template(ひな型)Methodパターン。スーパークラスでテンプレートとなるメソッドを定義し、サブクラスで処理の詳細を実装するパターン。 |
| Visitor | 振る舞い | 普通 | 難しい | Visitor (訪問者)パターン。構造と処理を分離するパターン。構造(Acceptor)が処理(Visitor)を呼び出し、Visitorが構造に依存した処理を実行する。 |
| AbstractFactory | 生成 | 普通 | 難しい | 複数オブジェクトを生成する際、生成するオブジェクトに複数の組み合わせが存在する場合、その組み合わせをを抽象化して利用しやすくするパターン。FactoryMethodを複数の関連するオブジェクトに適用するようなイメージ。 |
| Builder | 生成 | 普通 | 難しい | オブジェクトの生成過程を抽象化するパターン。インスタンス生成の引数が動的に変わる場合に有効。実装方法はいくつかある。①DI + TemplateMethod ②メソッドチェイン |
| FactoryMethod | 生成 | 普通 | 難しい | Factory(工場)Methodパターン。インスタンス生成をFactoryクラスに行わせるパターン。これにより抽象クラスを抽象クラスのまま扱えるので、抽象クラスを具象クラスにする必要がなくなる。 |
| Prototype | 生成 | 普通 | 簡単 | Prototype(原型)パターン。プロトタイプとなるインスタンスを流用するパターン。インスタンス生成を挟まないことでインスタンスが持つ状態をコピーして使うことができる。 |
| Singleton | 生成 | 簡単 | 難しい | 生成できるインスタンスの数を1つに制限するパターン。 |
参考にしたサイト
「Googleで検索して1ページ目に表示された結果を全部読む」という方法で勉強したのですが、IT専科さんの解説がとても参考になりました。
Author And Source
この問題について(デザインパターンについてまとめた), 我々は、より多くの情報をここで見つけました https://qiita.com/shin1rok/items/cd2dcfd554eaf8cecb7c著者帰属：元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .