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

kyosho5’s blog

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

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

第15章 Facadeパターン

複雑に絡み合っている詳細をまとめ、高レベルのインタフェース(API)を提供する。

・Facade役
→システムを構成しているその他大勢の役のシンプルな窓口となる。高レベルなインタフェース(API)をシステム外部に提供する。

・その他大勢の役
→それぞれ自身の仕事をするが、Facade役のことは意識しない。
Facade役から呼び出されて仕事をするが、その逆は起こらない。

・Client役
→Facadeパターンを利用する役


システムが大きくなるにつれてその複雑さは増大していくが、裏方のクラスの関係やその使い方などを意識しないで済むようこのパターンを使う。
インタフェース(API)を少なくすることが大事。(外部との結合が疎になる→パッケージを部品として再利用しやすくする。)
Facade役をもったクラスが複数個ある場合に、それらをまとめたFacade役を導入することも可能。

第16章 Mediatorパターン

処理内で全体に波及する出来事が起こった場合は相談役を介して大局的な判断を仰ぎ、相談役からの指示を受けて処理を実施する。
多数のオブジェクトの間の調整を行う必要があるときにはこのパターンを使う。
個々のオブジェクトが互いに通信しあうのではなく、相談役をとのみ通信を行う。
実際のロジックは相談役の中にのみ記述する。

・Mediator役
→Colleague役と通信を行い、調整を行うためのインタフェース(API)を定める。

・ConcreteMediator役
→Mediator役のインタフェース(API)を実装し、実際の調整を行う。・
アプリケーションへの依存度が高いロジックを実装したコードが集中しているためため再利用しにくい。

・Colleague役
→Mediator役と通信を行うためのインタフェース(API)を定める。

・ConcreteColleague役
→Colleague役のインタフェース(API)を実装する。
アプリケーションへの依存度が高いコードがないため再利用しやすい。

本来オブジェクト指向では処理を分散させるように実装することが多いが、今回のような場合は処理を各クラスに分散させると
デバッグや修正、機能追加などが大変になる。
各クラスに分散させるものと1クラスに集中させるものをうまく分ける必要がある。