Java言語で学ぶデザインパターン入門読みました
本について感想
GoFのデザインパターンを初心者にもわかりやすく紹介されておられる本でした。
しかし、個人的には「学んだデザインパターンを業務や個人開発で実践してみないとどんなところでどんなパターンが適しているか、もしくは必要となってくるのかわからない」、という考えのまま最初から最後まで読んでしまったため自身の経験の中で実践できるかはわからないといった感想を持ちました。
また、普段からオブジェクト指向を意識したコーディングを行っていないことについても気づかされ、これからのコーディングにはオブジェクト指向の概念を意識したコードを書いていきたいと思っています。
オブジェクト指向を意識しているプログラマ初心者ならこの本を読んで「ああ、とても勉強になったな…」と思うはずですが、そうではない僕からするとこの本がすべてのプログラミング初心者にまでお勧めされる理由が全く理解できませんでした。
写経について
僕にとっては意味がないと思いました。前述したとおり、普段からオブジェクト指向を意識してコーディングを行っているわけでもなく、単に「コードを書いている」というだけの感覚の方には写経してまでデザインパターンを勉強することはお勧めはしないと思います。その前にまずオブジェクト指向についてちゃんと知っておく必要があるかなと思っています。
「こんなパターンがあるんだな…動かして実際に挙動を確かめてみたい！！」という方には付録のCDにあるサンプルプログラムを利用するほうが遥かに時間的に効率のよい勉強法だと思います。
パターンについて
以下、学んだパターンについてまとめてみたので記しておきます。
また写経したコードはこちらに置いてあります。
デザインパターンに慣れる
Iteratorパターン
- 何らかの集合体があったとき、それを順番に指し示していき、全体をスキャンしていく処理を行うためのもの。
- 具体的なクラスだけでプログラミングするのではなく、抽象クラスやインターフェースを使ってプログラミングする
Adapterパターン
- インターフェース（API）が異なっている2つの間に入って、そのずれを埋めるためのもの
- 既存のクラスに一皮かぶせて必要とするクラスを作ることで、必要となるメソッド群を素早く作ることができる
サブクラスにまかせる
Template Methodパターン
- スーパークラスでの処理の骨組みを規定し、サブクラスで処理の内容を具体化するもの
- スーパークラスでの記述が多→サブクラスの記述は楽だが自由度減
- スーパークラスでの記述が少→サブクラスの記述は大変で個々のサブクラスのコードの記述が重複するかもしれない
Factory Methodパターン
- Template Methodパターンをインスタンス生成の場面に適応させたもの
- newによるインスタンスの生成を、インスタンス生成のためのメソッド呼び出しに代えることで、具体的なクラス名による束縛からスーパークラスを解放する
インスタンスをつくる
Singletonパターン
- 指定したクラスのインスタンスが絶対に一個しか存在しないことを保証するパターン
- インスタンスの数に制限を課す＝前提になる条件を増やす
- 複数のインスタンスを作成するとそれらが相互に影響しあってバグを生み出す可能性もある
Prototypeパターン
- クラスからインスタンスを作成するのではなく、インスタンスから別のインスタンスを作成するパターン
- 種類が多すぎてクラスにまとめられない場合、クラスからのインスタンス生成が難しい場合、フレームワークと生成するインスタンスを分けたい場合に使うことができる
Builderパターン
- 段階を踏んで、構造をもったインスタンスをくみ上げていくパターン
Abstract Factoryパターン
- 部品の具体的な実装には注目せず、インターフェースに注目し、そのインターフェースだけをつかって、部品を組み立てpプロダクトにまとめるもの
- 具体的な工場を追加するのは簡単だが、新たな部品を追加するのは困難である
分けて考える
Bridgeパターン
- 「機能クラスの階層」と「実装クラスの階層」を橋渡しする役割を持つ
- クラス階層が複雑になることを防ぐために「機能クラスの階層」と「実装クラスの階層」を分けてしまうのがいい
- 機能追加の際に、実装のクラス階層を全く修正する必要がなく、「すべての実装で」利用可能
Strategyパターン
- アルゴリズムを容易に切り替えることができる
- 委譲というゆるやかな結びつきを使っているので、アルゴリズムを容易に切り替えが可能になっている
同一視
Compositeパターン
- 容器と中身を同一視し、（入れ子になった構造）再帰的な構造を作るパターン
- 容器と中身を同一視するパターンだが、複数と単数の同一視と呼ぶこともできる。複数個のものを集めて、それをあたかも一つのものであるかのように取り扱う
Decoratorパターン
- オブジェクトに対して、どんどんデコレーションをほどこしていくようなパターン
- 包まれるものを変更することなく、機能の追加を行うことができる
構造を渡り歩く
Visitorパターン
- データ構造と処理を分離し、データ構造を渡り歩く「訪問者」を表すクラスを用意しそのクラスに処理をまかせる
- 処理とデータ構造を分離させることで部品としての独立性を高めている
Chain of Responsibilityパターン
- 要求を処理するインスタンスを鎖状に並べて置き、要求を処理できるかどうかを順番にチェックしていく「たらいまわし」のパターン
- 「仕事の振り分け」ができるので個々の仕事に集中できる
- 状況の変化に応じて動的に連鎖の形態を変えることもできる
シンプルにする
Facadeパターン
- 大きなプログラムを処理する際に関係するクラスを適切に制御する必要があり、その処理を行うための「窓口」を用意しておくほうがいい。その「窓口」をFacadeパターンという
Mediatorパターン
- 多数のオブジェクトの間の調整を行わなければならないときに利用されるパターン
状態を管理する
Observerパターン
- 観察対象の状態が変化すると、観察者に対して通知される。このパターンは、状態変化に応じた処理を記述する際に有効である。
- Model、View、Controllerの中のModelとViewの関係はObserverパターンの役割と対応している
Mementoパターン
- このパターンを利用すると、プログラムに対してundo（やり直し）、redo（再実行）、history（作業履歴の作成）、snapshot（現在状態の保存）などを行うことができる
Stateパターン
- システムの各状態を個別のクラスで表現するパターン
- 状態遷移は、状態を表しているクラスのインスタンスを切り替えることで表現される
無駄を無くす
Flyweightパターン
- メモリの消費を少なくするためにインスタンスを共有させるパターン
- 共有しているインスタンスを変更すると、複数個所に変更が及ぶ。なので、共有されるべき本来備わっている情報と、共有させてはいけない外からやってきた情報を意識して区別する必要がある。
Proxyパターン
- 「本人」と「代理人」のオブジェクトを作り、忙しくて仕事ができない本人オブジェクトの代わりに、代理人オブジェクトが仕事を代理でやってくれるパターン
- 例として、HTTPプロキシはHTTPサーバとHTTPクライアントの間に入って、WEBページのキャッシングを行うソフトウェアのこと
クラスで表現する
Commandパターン
- 「命令」をオブジェクトとして表現し、履歴をとったり再実行を行ったりすることができるパターン
Interpreterパターン
- 書かれたコードを解釈・実行するもので、この通訳プログラムのことをインタプリタと呼ぶ
引用
