dorivenの日記

気がついたら社会人。気になる技術的なことについて少しずつ書いていけたらと思っております。

【デザインパターン】パターンの有効利用

デザインパターン

研究とプライベートで予定も中々ヒートアップしてまいりました。
いよいよ来週なので精一杯楽しみたいと思います！

参考書


さらっと読める「OREILLY Head First デザインパターン」を参考にしながら書いています。
しばらくはこいつを参考にデザインパターンについて書いていくよ！

概要


この章は今まで習得してきたデザインパターンという言葉や概念に対する掘り下げが行われています。
そもそものデザインパターンの定義や、デザインパターンのスキームなどの概念的な話が多く、理解をするまでにしっかりと熟読していく必要がありました。
中にはデザインパターンの作者になるにはどうすればいいのか？という題材もありましたが、デザインパターンの理解とはあまり関係がないので省きます。

デザインパターンの定義


そもそもデザインパターンとは何なのか？とう定義について参考書では触れられています。
参考書には以下のように書かれている。

パターンはコンテキストにおける問題の解決策です。

そして、これだけではわからないとも触れており、以下ような３つに分類して説明が行われていた。

  1. コンテキスト
    パターンが適用される状況であり、繰り返し起こる必要がある。
  2. 問題
    コンテキストの中で達成したい目標上での発生する制約。
  3. 解決策
    一連の制約を解決し目標を達成するために、誰もが適用できる一般的な設計。

更にこれに対する例をこう述べています。

  1. コンテキスト
    キーを中に入れたまま、車をロックしてしまった。
  2. 問題
    どのようにして定刻に出社するか。
  3. 解決策
    窓を割って中に入り、エンジンをかえて職場まで運転して行く。

問題には「職場へたどり付く」という目的と時間、距離などの制約が存在する。

解決策として「窓を破る、鍵屋を呼ぶ」などが考えられますね。
しかし、繰り返し起きるであろう問題に対して適用する解決策としてはコストという点から見れば不適切な解決策だという事が分かります。
合鍵の準備や、置き忘れの予防策などはコスト面で良い解決策となりそうです。
もちろん、問題が起きた後では予防・代替策は不可能なので大きなコストを払うことなりますが。

つまり、デザインパターンは繰り返し起きるであろう共通の設計上の問題を解決するものである、と述べられています。
たしかに、デザインパターンというのは状況（コードやビジネスロジック上での制約や仕様）に合わせて使用するパターンを臨機応変に変えていくイメージがありますね。

デザインパターンのスキーム


デザインパターンには主に３つのスキームに分けることが出来ます。
それは「作成」、「振る舞い」、「構造」という三種類です。

  1. 作成
    オブジェクトのインスタンス化を伴うもの
  2. 振る舞い
    クラスとオブジェクトがどのように相互作用し、どのように責務を分配するかということに関与する
  3. 構造
    クラスやオブジェクトをより大きな構造にに組み込むことを可能にしています

これらのスキームの分類についてはWikipediaにわかりやすい記述があったのでそちらを引用させていただきます。

パターン名 概要 GoF Code Complete[1]
Abstract Factory 関連する一連のインスタンスを状況に応じて適切に生成する方法を提供する。 Yes Yes
Builder 複合化されたインスタンスの生成過程を隠蔽する。 Yes No
Factory Method 実際に生成されるインスタンスに依存しない、インスタンスの生成方法を提供する。 Yes Yes
Prototype 同様のインスタンスを生成するために、原型のインスタンスを複製する。 Yes No
Singleton あるクラスについて、インスタンスが単一であることを保証する。 Yes Yes

パターン名 概要 GoF Code Complete[1]
Adapter 元々関連性のない2つのクラスを接続するクラスを作る。 Yes Yes
Bridge クラスなどの実装と、呼出し側の間の橋渡しをするクラスを用意し、実装を隠蔽する。 Yes Yes
Composite 再帰的な構造を表現する。 Yes Yes
Decorator あるインスタンスに対し、動的に付加機能を追加する。Filterとも呼ばれる。 Yes Yes
Facade 複数のサブシステムの窓口となる共通のインタフェースを提供する。 Yes Yes
Flyweight 多数のインスタンスを共有し、インスタンスの構築のための負荷を減らす。 Yes No
Proxy 共通のインタフェースをもつインスタンスを内包し、利用者からのアクセスを代理する。Wrapperとも呼ばれる。 Yes No

パターン名 概要 GoF Code Complete[1]
Chain of Responsibility イベントの送受信を行う複数のオブジェクトを鎖状につなぎ、それらの間をイベントが渡されてゆくようにする。 Yes No
Command 複数の異なる操作について、それぞれに対応するオブジェクトを用意し、オブジェクトを切り替えることで操作の切替えを実現する。 Yes No
Interpreter 構文解析のために、文法規則を反映するクラス構造を作る。 Yes No
Iterator 複数の要素を内包するオブジェクトのすべての要素に順にアクセスする方法を提供する。反復子。 Yes Yes
Mediator オブジェクト間の相互作用を仲介するオブジェクトを定義し、オブジェクト間の結合度を低くする。 Yes No
Memento データ構造に対する一連の操作のそれぞれを記録しておき、以前の状態の復帰または操作の再現が行えるようにする。 Yes No
Observer (出版-購読型モデル) インスタンスの変化を他のインスタンスから監視できるようにする。Listenerとも呼ばれる。 Yes Yes
State オブジェクトの状態を変化させることで、処理内容を変えられるようにする。 Yes No
Strategy データ構造に対して適用する一連のアルゴリズムをカプセル化し、アルゴリズムの切替えを容易にする。 Yes Yes
Template Method あるアルゴリズムの途中経過で必要な処理を抽象メソッドに委ね、その実装を変えることで処理が変えられるようにする。 Yes Yes
Visitor データ構造を保持するクラスと、それに対して処理を行うクラスを分離する。 Yes No

しかし、なぜここに来てスキーマによる分類が出てきたのでしょうか？
それはスキーマを知ることでどのパターンを適用すればいいかが見えてくるからです
先ほどもデザインパターンについて、コンテキストと問題に対する解決策を提示する時、どのようなコンテキストかが分かれば適用するデザインパターンも見えてくるということです。
インスタンスの生成に関する問題であれば、「生成」に関するデザインパターンから珍味するようにです。

しかし、このパターンの分類にはDecoratorのように自分で理解できない分類があったりします。
ここらへんはパターンへの理解を深めなければ理解するのが難しいので精進が必要ですね。

パターンについての知力


デザインパターンとは何にでも適用するのものではありません。
しかし、デザインパターン初心者のうちは何にでもパターンを適用してしまおうとします。
これを参考書では「初心者の知力」と呼んでいます。

次にパターンの理解が進みデザインパターンの必要な部分を理解してくるが、どのパターンを適用すればいいのかをまだ分からない状態です。
これを参考書では「中級者の知力」と呼んでいます。

最後にパターンの適合場所と種類が判断出来るのを「禅の知力」と呼んでいます。

デザインパターンを使うならこの禅の知力と呼称している領域まで到達したいものですね！

ボキャブラリ


デザインパターンを学ぶメリットとしてボキャブラリとしての意図の共有化があります。
チーム全体がデザインパターンを知ることでデザインパターンの名称だけでどのような設計にしたいのか、という意図が伝わりコミュニケーションに使う時間が少なくなります。
その時間を開発に有効活用することが出来るようになり、より効率的な開発が可能です。