読者です 読者をやめる 読者になる 読者になる

kyosho5’s blog

貧乏で数学があまり得意ではない理系出身のエンジニアのブログ

デザインパターン勉強メモ⑤

第9章 Bridgeパターン

機能のクラス階層と実装のクラス階層を橋渡しする。

・機能のクラス階層
スーパークラスは基本的な機能を持っている
②サブクラスでは新しい機能を追加する

・実装のクラス階層
スーパークラスでは抽象メソッドによってインタフェース(API)を規定している
②サブクラスは具象メソッドによってそのインタフェース(API)を実装する

上記2つの考え方が混在してしまうととても複雑なクラス階層になってしまうため、
設計の段階でどちらの意図で階層を作ろうとしているのかを考える必要がある。

Bridgeパターンを用いて異なるクラス階層にしてしまうことで上記のわずらわしさをなくす。

・Abstruction役
→機能のクラス階層の最上位クラス。Implementor役のメソッドを使って基本的な機能だけが
記述されている。
このクラスはImplementor役を保持する。

・RefinedAbstruction役
→Abstruction役に対して機能を追加した役

・Implementor役
実装のクラス階層の最上位クラス。Abstruction役のインタフェース(API)を実装するための
メソッドを規定する役。

・ConcreteImplementor役
→具体的にImplementor役のインタフェース(API)を実装する役

2つのクラス階層に分割したことで、それぞれのクラス階層を独立に拡張することができる。
(もう片方のクラス階層は一切手を加える必要がない。)

継承はクラス拡張の際に便利だが、結びつきが硬くなってしまう(変更の際にはソース自体を変更する必要がある)
サンプルではMainクラスの中で各実装クラスのインスタンスを作って引数として渡しているため(継承ではなく委譲)、
Mainクラスのみの変更で実装を切り替えることができる。

継承は固い結びつきであり、委譲はゆるい結びつきである。


第10章 Strategyパターン

問題を解くためのアルゴリズムが実装されている部分がごっそり交換できるような仕組み。
アルゴリズムを切り替え、同じ問題を別の方法で解くことを容易にするパターン。

・Strategy役
→戦略を利用するためのインタフェース(API)を定める。

・ConcreteStrategy役
→Strategy役のインタフェース(API)を実際に実装する役。
ここで具体的な戦略(作戦・方策・方法・アルゴリズム)を実際にプログラミングする。

・Context役
→Strategy役を利用する役。ConcreteStrategyのインスタンスを持っていて、必要に応じてそれを利用する。
あくまで呼び出すのはStrategyクラスのインタフェースである。


Strategyパターンではアルゴリズムの部分をほかの部分と意識的に分離し、インタフェース(API)の部分のみを規定する。
→プログラムから委譲によってアルゴリズムを利用する。
また、動的にアルゴリズムを切り替えが可能になる。