デザパタ学習

Proxyパターン(第21章)

ある程度までを代理クラスで処理して、必要になったら本来のクラスに処理させるようにする。

Flyweightパターン(第20章)

Singltonパターンのクラスをかませることで、同じパラメータを持つインスタンスを共有するようにする。使用メモリを抑えるのが目的。

Stateパターン(第19章)

State側のクラスでは状況毎の対処の記述を中心にして、Context側ではState側オブジェクトの状況に対応したメソッドを呼び出すようにする。 なんだかんだで、Interfaceって便利だよなぁ…。IDEに多少依存してる面はあるけど、メソッドの過不足がすぐ確認できて…

Observerパターン(第17章)

何か変化があったとき、そのメッセージをObserver側で受け取って、Observer側で処理をする、という手続きを踏む。 Observerの処理による変化を、Subject側に影響させないようにするのがポイント(物理的な計測でもこれが鉄則だったな)。

Mediatorパターン(第16章)

幾つかのクラスが互いに関係しあってるときなどに、プロセスを窓口役のクラスを介すようにする。2つ以上のクラスが関係しあった処理をまとめて面倒を見ることで、後の修正・拡張の負担を軽減する。 うへぇ、このパターンをそれなりに理解して書くのに1日かか…

Mementパターン(第18章)

他のクラスにパラメータを格納しておくことで、何かあったときにそのパラメータを呼び出して、以前の環境にすることができる。 俺の中では、Undo的な動作はMementoクラス内のパラメータの配列で保存するのかなぁ、と思っていたのだが、テキストにはインスタ…

Facadeパターン(第15章)

えーっと、まず読みは「ファサード」らしい。メインの処理はある一つのクラスを呼び出すだけで、詳しいことはその呼び出されたクラスがすべて行う。プログラムを単純化して見せるのが目的。

Chain Of Responsibilityパターン(第14章)

処理するクラスの順番を決めておいて、できる処理だけやらせる。イテレータとは違うけど、どのクラスにも内部的に、次に処理させるクラスのインスタンスがあるってのが面白い。でも、遅いらしいけど。

Visitorパターン(第13章)

ダブルディスパッチという方法を用いて、Accept側のクラスを変更することなく、新たな処理を加えられるようにする。もう少し言うと、Accept側のクラスはデータ構造の規定に終始するようにして、その処理はVisitor側でまかなう様にすることで、データ構造と処…

Decoreatorパターン(第12章)

インスタンスを取り込むことで、中身を変えることなく処理を追加することができる。 段々、感覚的には分かるけど…、ってのが増えてきたな。23章まで終わってからでもいいけど、おさらいしないと。 あと、やっぱしトップダウン的に記述して、悩みながらやって…

Compositeパターン(第11章)

オブジェクト指向の重要な要素であるマルチプルインスタンスを利用して、入れ子的な構造を処理する。 サンプルのクラス図とは違うけど、マルチプルインスタンスを利用して再帰的な構造を解析するってプログラムは以前書いたことあるなぁ。その時使ったのはC+…

Strategyパターン(第10章)

似たアルゴリズムをそれぞれクラスに隠蔽して、それを別のクラスによってコントロールすることで、柔軟に対応できるようにする。ん?今読み返してみたら、Builderパターンとの違いって何だろ…。「ごっそり」がポイント? 今回は、JavaとRubyの乱数生成のアル…

Bridgeパターン(第9章)

何ができるか(機能)とどうするか(実装)を分ける。「機能」側で定義されたメソッドの中身は、「実装」側のメソッドを呼び出すだけ。そうすることで、今後の拡張にも柔軟に対応できるようになる。

Abstract Factoryパターン(第8章)

Abstractサイドが実装サイドを呼び出す、という仕組みにすることで、柔軟に対応できるようにする。具体的には、メイン側で指定したパラメータによって、実装側が変わる、というような。 今回のサンプルは、今までよりぐっとレベル(クラス数)があがったので…

Builderパターン(第7章)

メインから呼び出されるDirectorクラスはBuilderクラスを呼び出し、そのメソッドを実行するだけで、その実装すらサブクラスによって隠蔽されている。とりあえず、テキストの「知らないからこそ、入れ替えができる。入れ替えられるからこそ、部品としての価値…

Prototypeパターン(第6章)

親クラスが子クラスのインスタンスのクローンを保持しておき、主にハッシュキーでインスタンスを取り出す。子クラスの数が多いとき、管理しやすくするのが目的。 結城センセのサンプルでは、ハッシュキーごとにオブジェクトを格納する変数を変えてるので、自…

Template Methodパターン(第3章)

親クラスではフレームワークを定義し、子クラスで肉付け的に処理を定義する。子クラスが複数ありつつ、親クラス側では共通した処理を定義するのが一般的。処理を俯瞰して、処理のフローと実装を分けてわかりやすくするのが目的。転じて、共通した処理が一本…

Adapterパターン(第2章)

あるデータ等を処理するクラスを継承させて、サブクラス側のメソッドは、内部は親側のメソッドを呼び出してるだけ。サブクラスでワンクッション置いて、柔軟に実装できるようにするのが目的。 個人的には、継承を使った方がシンプルで好き。尤も、継承の方が…

Singletonパターン(第5章)

インスタンス作成時に、常に最初に呼び出されたときの自分自身を指定することで、2つ以上そのクラスのオブジェクトが生成されないようにする。

Factory Methodパターン(第4章)

Template Methodパターンの応用。オブジェクトを生成するとき、更に実際の処理のクラスを生成する。Factory側のクラスがコンストラクタのような働きをして、initialize時にあらかた処理を済ませてから、それを元にProduct側のクラスを生成して、そのオブジェ…

Iteratorパターン(第1章)

データ構造を規定するクラスと、そのデータ構造にアクセスするためのクラス、そして、そのアクセスするクラスのインスタンスを使って順番にデータを取り出すクラスに分けられる。配列を数えているのをクラス内に隠蔽するのが目的。