
Javaの開発をする上で、必ず知っておきたいのがJavaのデザインパターンです。先に行ってしまうと、デザインパターンとは、先人のプログラマー達が編み出してきた設計ノウハウを集めて、使いやすいような部品として名前をつけてカタログ化したものです。
簡単に言ってしまうと、「こんな機能を求めているなら、このカタログにのっている部品を使ってね!」、「このカタログに載っている部品は全員が把握している内容だから、他の人がみてもわかりやすいコードになるよ!」ということです。本記事では踏み込んだ内容ではなく、デザインパターンの一覧と、そのパターンがどのようなときに使われるかの簡単な説明を記載します。
デザインパターンとは?なんで必要なの?
JavaのデザインパターンといえばGoFのデザインパターンがあまりにも有名です。「Gang of four(4人組)」その名の通り、4人の設計者が作ったデザインパターンです。本記事では4人の説明は省きます。
前述した通り、デザインパターンとは設計ノウハウを集めて、使いやすいような部品として名前をつけてカタログ化したものです。なぜJavaのコードをカタログ化する必要があるのでしょうか。それはソフトウェアの生産性や保守性を大幅に向上することができるからです。
例えばカレーをレシピ通りつくることを考えてみましょう。「具材を切って、煮込んで、カレーの固形ルーをいれて、はい、完成!」非常に簡単ですよね。じゃあもし、カレーの固形ルーがこの世に存在しない場合どうなりますか?おそらく大半の人はカレーを作るのを諦めますよね。お店で食べた方が早いと。このルーがJavaでいうところのデザインパターンです。ルー(デザインパターン)を見ただけで味の想像も作り方もなんとなくわかってしまいます。

このように誰もがわかりやすく一般的な書き方になったデザインパターンを利用することで、自分が見ても他人が見てもわかりやすいコードを書くことができ保守性が爆上がりします。またスパイスを1から集める必要がないため、生産性も爆上がりします。
デザインパターン一覧
GoFのデザインパターンには23種類のパターンがあります。これらのパターンは下記の3種類に分けることができます。
- オブジェクトの「生成」に関するパターン
- プログラムの「構造」に関するパターン
- オブジェクトの「振る舞い」に関するパターン
オブジェクトの「生成」に関するパターン
オブジェクトの生成に関するパターンには下記の5つがあります。
パターン名 | 概要 |
---|---|
Abstract Factory | 関連したオブジェクトの集まりを、具象クラスを指定しなくても生成することが可能になる |
Builder | オブジェクトの生成過程を抽象化し、自由自在にオブジェクト生成が可能になる |
Factory Method | オブジェクトの作り方を親クラスで定め、具体的な処理をサブクラスで行うことでオブジェクトの生成方法を柔軟に行うことが可能 |
Prototype | クラスを元にオブジェクトを生成するのではなく、オブジェクトから別のオブジェクトを生成(コピー)する |
Singleton | クラスのオブジェクトが1つしか生成されないことを保証する |
プログラムの「構造」に関するパターン
プログラムの構造に関するパターンには下記の7つがあります。
パターン名 | 概要 |
---|---|
Adapter | 非互換性の2つのオブジェクトの間にアダプターを設置することで、関連性を持たせることが可能 |
Bridge | 機能と実装を分離して、それぞれで拡張することが可能になる |
Composite | 入れ物のクラスと中身のクラスを、1つの抽象クラスでまとめて、それぞれのクラスから得られるオブジェクトを同一視できるようにする |
Decorator(Filter) | 元となるオブジェクトに装飾(デコレート)を行うことで機能を拡張させる方法 |
Facade | 複数のクラス組み合わせて使う手順を、まとめる(窓口)クラスを作ってシンプルに利用できる方法 |
Flyweight | 1つのオブジェクトを再利用することで計算資源を節約する方法 |
Proxy | 代理人オブジェクトを立てて、本人でもなくてもできる処理を代理人オブジェクトが引き受け、本人にしかできない処理を本人のオブジェクトが実行する方法 |
オブジェクトの「振る舞い」に関するパターン
プログラムの振る舞いに関するパターンには下記の11個があります。
パターン名 | 概要 |
---|---|
Chain of Responsibility | 複数のオブジェクトに自身のオブジェクト持つことで、鎖のように連結され各オブジェクトを渡り歩くことで、目的のオブジェクトを参照する方法 |
Command | 一つ一つのコマンドオブジェクトとして表現し、コマンドの管理を容易にすることが可能 |
Interpreter | 何らかの形式で書かれたファイルの中身を解析・表現し、言語の文法をオブジェクトで表現する方法 |
Iterator | 集合体の要素にアクセスする方法で、集合体とアクセス方法を分離することで、集合体の内部構造を無視してアクセスすることが可能 |
Mediator | 複数のオブジェクト間の依存性を解消し、オブジェクト間の直接の通信をメディエーターオブジェクトを介してのみ作業を行うようにする方法 |
Memento | オブジェクトのスナップショットを作成し、それを復元できるようにする方法 |
Observer | 観察対象のオブジェクトの状態が変化したとき、観察者のオブジェクトに通知を行う方法 |
State | 状態をオブジェクトととし、そのオブジェクトを切り替えることによって状態の変化を表現する方法 |
Strategy | 状況に応じてオブジェクトの振る舞いを変更する方法 |
Template Method | 抽象的な処理を親クラスで定義し、サブクラスで処理を実装することでオブジェクトの振る舞いを共通化する方法 |
Visitor | データ構造とそのデータに対する処理を分割し、Visitorオブジェクトに処理を追加することで、データ構造に変更を加えることなく処理アルゴリズムの追加ができる方法 |
まとめ
上述した通り、デザインパターンとは設計ノウハウを集めて、使いやすいような部品として名前をつけてカタログ化したものです。上手く使えば、飛躍的に開発を楽に、かつ保守性の向上も期待できます。上手く使っていきましょう!
本記事とは別に、個々のデザインパターンの詳細についても説明した記事を用意しております。是非そちらも参考にしてください。