復習:Proxyパターン

今回はProxyパターンの復習です。
Proxyパターンは、インスタンスを必要になってから生成するというパターンです。

多くのインスタンスの中から一つだけ選び出すといったような画面を作成する際に、インスタンス全てを完全な形で用意するのは無駄が多いです。
このようなときに、インスタンスのリストに表示するだけの情報を持ったインスタンス(代理人)を生成し、それをリストの表示に用いるというような使い方がされます。
代理人が保持する情報はあくまでも情報の一部であり、それ以上の情報が必要になった時に初めて本物のインスタンスを生成します。

復習:Flyweightパターン

今回はFlyweightパターンの復習です。
Flyweightパターンは、一度生成したオブジェクトを使いまわすことによってメモリの使用量などを抑えるデザインパターンです。
オブジェクトの種類が少なく、同じオブジェクトが繰り返し何度も使われるような場合において力を発揮します。
生成したオブジェクトを管理するための手間が発生するため、オブジェクトの種類が少ない、同じオブジェクトが何度も使われない、などの場面では逆に使わないほうが良いでしょう。

復習:Stateパターン

今回はStateパターンの復習です。
Stateパターンは状態をクラスとして表現することで、コードの簡略化を行なっています。
どういうことかというと、状態分岐をコードに書くとif文やswitch文を書く必要があり、冗長になってしまいます。
しかも状態をひとつ追加しようとするとif文にも変更を加えなくてはならず、保守性に欠けます。

状態をクラスとして表現し、インスタンスとして保持することで、状態変化の際には、参照するインスタンスを変更するだけでそれを表現できる、というわけです。
状態に関する情報をコードではなく、クラスそのもので表現しています。

復習:Memento

今回はMementoパターンの復習です。

Mementoパターン
状態の保存を行うパターンです。
状態に必要な情報をインスタンスとして保存します。
また、そのインスタンスから元の状態に復帰する機能もつけます。
アンドゥ機能などを実装する際に役に立つパターンでしょう。
このパターンは以前のオブジェクトの状態の再現を目的としています。
このパターンでは現在の自分の状態を保存し、Mementoとして作成するOriginator
保存された状態を表現するMemento
Memento保存の要請を出したり、保存されたMementoをどこかに保持しておき、復帰の際にそれを渡すなどの処理を行うCaretakerの3種類の役があります。

広いインターフェースと狭いインターフェース
Memento役はOriginator役の情報を保存し、復帰できるようにしなくてはならないので、必然的にOriginator役の情報を全て持っています。
つまり、Originator役における隠蔽情報はMemento役に対しては、隠蔽されていません。
しかし、オブジェクト指向の考えに則るならば、Originator役の隠蔽情報はMemento役以外には隠蔽されなくてはなりません。
Memento役に対する情報隠蔽とMemento役以外に対する情報隠蔽の2種類を使い分ける必要があるわけです。

復習:Observer

今回はObserverパターンについての復習です。
Observerパターンは複数のオブジェクトがひとつのオブジェクトを監視する際に使用するパターンです。

Observerパターン
通知とそれに対する処理を行うパターン。
subject、被観察者とobserver、観察者の2つのオブジェクトがある。
Subjectは全てのobserverを登録するリストを持つ。
変化が起こった時、Subjectは予め登録されたobserverに対してどのような変化が起きたかを通知する。
その際、各observerに実装されている特定のメソッドupdateを自分自身もしくは、変化について分かる値を引数として呼び出す。
updateメソッドを呼び出されたobserverは、引数からsubjectの情報を取得し、それに対する処理を行う。
どのような値を引数としてもたせるか、subjectとobserverの関係をどのようなものにするかなどは実装によって異なる。

復習：Mediator

今回はMediatorパターンの復習です。

Mediatorパターンは、複数のオブジェクトが相互に作用し、状態を変更させるようなときに使用するパターンです。
全てのオブジェクトを統括するクラス(Mediator)を用意します。
個々の部品となるクラス(Colleague)は自分の状態変化を調停者に知らせ、調停者は個々のオブジェクトの状態に応じた全体の状態を調整します。

全ての状態や動作を調停者に記述することで、プログラムの保守性が高くなります。

もし、この個々のクラスの状態による動作を各クラスに記述していると、コードが分散することになり、保守性が低下します。
状態の遷移などが相互に作用するような複雑なアプリケーションを作成する場合、Mediatorパターンを用いたほうがスマートに記述できるのかもしれません。

ColleagueとMediatorの関係
全てのcolleagueは調停者mediatorに変化を知らせるメソッドを持つ、変化を受け取った調停者は変化に対して他のcolleagueを変化させる。
個々のcolleagueが連動して動くとき、その動きを調停者側に全て書き込むことによってコードの分散を防ぎ、保守性を高く保つ。
Mediator自身の動作はアプリケーションに依存しているため、再利用性は低い。
典型例はGUIプログラム

復習：Facade

今回はFacadeパターンの復習です。

Facadeパターンは複雑な処理に関する操作の窓口をシンプルにすることで
クラスの操作を簡略化しているパターンです。

複雑なものを単純に見せる、裏で動いている処理を隠蔽することで単純化しています。

Facadeパターンがしていることはそれほど多くなく、デザインパターンの中ではむしろ単純な部類ですね。

Facadeパターンは外部から見える部分を少ないので、外部との繋がりを薄くすることができます。
そうすることで、クラス間の繋がりが疎となり、再利用性の高いクラスが記述できます。

Facadeパターンはクラスの設計の技法と言うよりは、リファクタリングの技法に近いのかもしれません。