前書き
GoFのデザインパターンが世に登場した『オブジェクト指向における再利用のためのデザインパターン』は1995年の発行だそうで、もはや古典の域ですね。
Swiftなどのモダンな言語では「もう使わないパターン」とか「もっとシンプルに解決できるパターン」などもあり、具体的な解決方法として崇め奉るモノではないかなと思います。
しかし、GoFのデザインパターンを、「解決方法」ではなくて、開発で良く陥る「状況」と解決に至る「発想」、そしてそれに対する「名前付け」に着目すると、改めて研究してみる価値はあると考えます。
この記事シリーズは、iOS/Swiftエンジニアである執筆者個人が、
ごく普通のiOSアプリ開発でよくある状況や
Swiftのコアライブラリやフレームワークで使われているパターンに
着目してデザインパターンを学び直してみた記録です。
記事の一覧
| 生成に関するパターン | 概要 |
|---|---|
| Factory Method | 実際に生成されるインスタンスに依存しない、インスタンスの生成方法を提供する。 |
| Abstract Factory | 関連する一連のインスタンスを状況に応じて、適切に生成する方法を提供する。 |
| Builder | 複合化されたインスタンスの生成過程を隠蔽する。 |
| Singleton | あるクラスについて、インスタンスが単一であることを保証する。 |
| Prototype | 同様のインスタンスを生成するために、原型のインスタンスを複製する。 |
| 構造に関するパターン | 概要 |
|---|---|
| Adapter | 元々関連性のない2つのクラスを接続するクラスを作る。 |
| Facade | 複数のサブシステムの窓口となる共通のインタフェースを提供する。 |
| Bridge | クラスなどの実装と、呼出し側の間の橋渡しをするクラスを用意し、実装を隠蔽する。 |
| Composite | 再帰的な構造を表現する。 |
| Decorator | あるインスタンスに対し、動的に付加機能を追加する。 |
| Flyweight | 多数のインスタンスを共有し、インスタンスの構築のための負荷を減らす。 |
| Proxy | 共通のインタフェースを持つインスタンスを内包し、利用者からのアクセスを代理する。 |
| 振る舞いに関するパターン | 概要 |
|---|---|
| Chain of Responsibility | イベントの送受信を行う複数のオブジェクトを鎖状につなぎ、それらの間をイベントが渡されてゆくようにする。 |
| Command | 複数の異なる操作について、それぞれに対応するオブジェクトを用意し、オブジェクトを切り替えることで、操作の切替えを実現する。 |
| Mediator | オブジェクト間の相互作用を仲介するオブジェクトを定義し、オブジェクト間の結合度を低くする。 |
| Observer | インスタンスの変化を他のインスタンスから監視できるようにする。 |
| State | オブジェクトの状態を変化させることで、処理内容を変えられるようにする。 |
| Strategy | データ構造に対して適用する一連のアルゴリズムをカプセル化し、アルゴリズムの切替えを容易にする。 |
| 【以下は割愛】 | |
| Interpreter | 普通のiOSアプリ開発では利用ケースが限定的なので割愛 |
| Iterator | Swiftでは言語機能でサポートされているので割愛 |
| Template Method | Swiftではprotocolとして言語仕様に組み込まれているため割愛 |
| Memento | 普通のiOSアプリ開発では利用ケースが限定的なので割愛 |
| Visitor | 難解すぎて普通のiOSエンジニアが使っても幸せになれないような気がするので割愛（笑 |
※概要はWikipediaより引用