第1章
はじめてのデザインパターン
第2章
逆引きカタログ ロジック編
- Singleton (シングルトン)
- Factory/Factory Method
(ファクトリ/ファクトリメソッド) - Strategy (ストラテジ)
- Composite (コンポジット)
- Visiter (ビジタ)
第1章 初めてのデザインパターン
Authors:
デザインパターンとは
| → | デザインパターンは「良い設計の虎の巻 |
| → | デザインパターンのメリット |
デザインパターンは「良い設計の虎の巻」
デザインパターンとは簡単に言うと「良い設計の虎の巻」です。プログラミングや設計をしていると、以前経験したことがある、 似たような問題に出くわすことがよくありますよね。 そのような問題の解決法にわかりやすい名前を付けて、 カタログ化（虎の巻化）したものがデザインパターンです。
デザインパターンは虎の巻ですので、 知っているのと知らないのでは設計や効率に大きく差がついてきます。 先人たちの「設計に関する試行錯誤の結果」であるデザインパターンを、 効果的に再利用しない手はありません。
デザインパターンにはいくつか種類があります。
表１ デザインパターンの種類
| カタログ名 | 説明 |
|---|---|
| GoFの23のパターン | デザインパターンと言えばこれを指すというくらいのバイブル的存在。 基本的な23のパターンがカタログ化されている。 |
| J2EEパターン | サーブレット/JSP/EJB/JMXを中心にJ2EEに特化したデザインパターン集。 ここで紹介されたパターンはStrutsなどのフレームワークにも適用されている。 |
| アーキテクチャパターン | MVCやレイヤなどシステム全体のアーキテクチャ（構造）をパターン化したもの。 |
| アナリシスパターン | 医療、在庫管理、会計、金融などの具体的な業務システムにおける設計やモデリングのぱたーんをカタログ化したもの。 |
| アンチパターン | デザインパターンが「こうあるべき」ものなのに対して、 アンチパターンは「こうしてはいけない」ものをカタログ化したもの。 |
有名なものとしては「Gang of Four（ギャング・オブ・フォー）」略して「GoF（ゴフ）」 の23のデザインパターンがあります。
表２ GoFの23のパターン（リンクは本特集で解説）
| No | 種別 | パターン名 | 目的 |
|---|---|---|---|
| 1 | 生成に関する パターン |
Abstract Factory （アブストラクトファクトリ） |
関連する部品を生成するファクトリごと切り替える |
| 2 | Builder（ビルダ） | 複雑なオブジェクトを生成する | |
| 3 | Factory Method （ファクトリメソッド） |
サブクラスのメソッドにインスタンスの生成方法をまかせる | |
| 4 | Prototype（プロトタイプ） | コピーしてインスタンスを生成する | |
| 5 | Singleton（シングルトン） | 生成するインスタンスを1個に制限する | |
| 6 | 構造に関する パターン |
Adapter（アダプタ） | インタフェースが一致しないクラスを再利用する |
| 7 | Bridge（ブリッジ） | 機能と実装の階層を分離し、拡張を別々に行う | |
| 8 | Composite（コンポジット） | 再帰的なオブジェクト構造を表現する | |
| 9 | Decorator（デコレータ） | 元になるオブジェクトを包み込んで機能を拡張する | |
| 10 | Facade（ファサード） | 複雑な処理を呼び出すシンプルな入り口を提供する | |
| 11 | Flyweight（フライウェイト） | インスタンスを共有して、インスタンスの生成コスト・使用メモリを抑える | |
| 12 | Proxy（プロキシ） | 代理（プロキシ）を用意してインスタンスの生成やアクセス制限をコントロールする | |
| 13 | 振る舞いに関する パターン |
Chain of Responsibility （チェイン・オブ・レスポンシビリティ） |
処理を順番にたらいまわす |
| 14 | Command（コマンド） | 命令そのものをオブジェクトとして扱う | |
| 15 | Interpreter（インタプリタ） | 構文解析の結果を表現するクラスを定義する | |
| 16 | Iterator（イテレータ） | 複数のオブジェクトに順番にアクセスする | |
| 17 | Mediator（メディエータ） | 複数のオブジェクトを集中管理する | |
| 18 | Memento（メメント） | オブジェクトの状態を保管して復元可能にする | |
| 19 | Observer（オブザーバ） | オブジェクトの状態変化を通知する | |
| 20 | State（ステート） | 状態に応じて処理内容を切り替える | |
| 21 | Strategy（ストラテジ） | アルゴリズムを交換可能にする | |
| 22 | Template Method （テンプレートメソッド） |
一連の処理の一部をサブクラスで実装し、変更可能とする | |
| 23 | Visitor（ビジタ） | 複数のオブジェクトを渡り歩く処理を追加・変更する |
そのほかにもJavaに特化したパターンとして、サーバサイドJavaのパターンを集めたJ2EEパターンなどがあります。
表３ J2EEパターン（本特集で解説しているもののみ）
| 種別 | パターン名 | 目的 |
|---|---|---|
| プレゼンテーション層のパターン | ViewHelper（ビューヘルパ） | ビューからロジックを分離する |
| ビジネス層のパターン | Session Facade （セッションファサード） |
ビジネスロジックの複雑さを隠して、 シンプルな入り口を作る |
| インテグレーション層のパターン | Dao（Data Access Object） | データアクセスを抽象化する |
本特集では主にGoFとJ2EEからピックアップしたパターンをご紹介します（表2〜3）。
デザインパターンのメリット
デザインパターンを知り、実践していくことでどのような効果があるのでしょうか？筆者は次のような効果があると考えます。
@再利用性の高い柔軟な設計ができるようになる
デザインパターンの多くは再利用性の高い柔軟な設計を目指しています。多くの熟練開発者の「知恵」が 詰まったデザインパターンを知ることで、経験がまだ少ない開発者も設計のヒントを多くもらうことがで きるでしょう。また、直接デザインパターンを使わなかったとしても、デザインパターンを理解すること で「設計力」を高めていき、より良いコードが書けるようになっていくことは、技術者として成長していく 楽しみにもつながることでしょう。
A共通の言葉を使って会話ができるようになる
デザインパターンをお互いが共通理解しているチームでは、パターン名を使った会話が交わされるように なります。「この3つの処理は共通処理をテンプレートパターンで実装しよう」「このロジックはあとで 変更があってもよいようにファクトリメソッドにしといてよ」といった感じです。これによりコミュニケ ーションは円滑になり、ミーティングにかける時間も大幅に短縮されることでしょう。現在、デザインパ ターンをまったく使わないJavaプロジェクトというのはまず考えられませんので、デザインパターンをチーム 全体が知っていることによるメリットは大きいと言えるでしょう。
Bオブジェクト指向が理解できる
これは筆者が感じたメリットです。一般的ではないかもしれませんし、反論もあることを承知でご説明しま す。デザインパターンはオブジェクト指向の基本の上に成り立っています。良いデザインパターンのサンプル は、良いオブジェクト指向プログラミングのサンプルでもあります。実プロジェクトではなかなか経験できな い「凝った設計を試すこと」で、オブジェクト指向に対する視野が広がることでしょう。デザインパターンの 学習により、オブジェクト指向の理解が深まるという、一石二鳥の学習効果があるのではないでしょうか。
