ラベル デザインパターン の投稿を表示しています。 すべての投稿を表示
ラベル デザインパターン の投稿を表示しています。 すべての投稿を表示

2011年8月13日土曜日

Facadeパターン : 隠蔽 or not 隠蔽?

デザインパターンねたの続きです。

Facadeパターンというものがあるんですが、一言で言えば、
「複数の(低水準な)オブジェクトをまとめて扱えるような(高水準な)窓口用クラスを作る」
というものです。

HeadFirstデザインパターンから例を引用すると、
低水準なコンポーネントである
アンプ、スピーカー、プロジェクタ、照明、・・・
といったものを、
高水準クラスである"ホームシアター"で一気に調整する、とかそんな感じです。

HeadFirstデザインパターンでは、
Facadeを使うクラスが、Facadeクラスに低水準コンポーネントを渡す
という形で説明されています。
したがって、高水準な機能だけでは実現できないような"微調整"が必要なときには、
低水準コンポーネントに直接アクセスすることが可能である、と説明されています。
つまり、Java風擬似コードで言うとこうです。

class FacadeUser{
	...
	func(){
		...
		LowLevelComponent1 comp1 = new LowLevelComponent1();
		LowLevelComponent2 comp2 = new LowLevelComponent2();
		Facade facade = new Facade(comp1, comp2);
		...
	}
	...
}
class Facade{
	LowLevelComponent1 comp1;
	LowLevelComponent2 comp2;
	// constructor
	Facade (LowLevelComponent1 comp1,  LowLevelComponent2 comp2){
		this.comp1 = comp1;
		this.comp2 = comp2;
		...
	}
	...
}
一方、wikipediaなんかでは、
Facadeとなるクラスの中で、privateに低水準コンポーネントを作る、ということをしています。
したがって、Facadeを使う側は、直接低水準コンポーネントを触れない、というわけです
(setterやgetterを作れば別ですが)。
特に、日本語版wikipediaでは低水準コンポーネントを隠蔽する点にしっかり言及しています。
擬似コードだとこんなです。
class FacadeUser{
	...
	function(){
		Facade facade = new Facade();
		...
	}
	...
}
class Facade{
	private LowLevelComponent1 comp1;
	private LowLevelComponent2 comp2;
	// constructor
	Facade (LowLevelComponent1 comp1,  LowLevelComponent2 comp2){
		this.comp1 = new LowLevelComponent1();
		this.comp2 = new LowLevelComponent2();
		...
	}
	...
}

隠蔽するかしないかで、クラス図的にはほぼ同じでも、
正直相当違うんじゃないかと思うのですが、どうなんですかねえ。
どっちが正解とかそういうことは無いとは思うのですけども、
せっかく名前をつけている以上はっきりしておいてもらいたいなあと思います。

ま、そもそもFacadeパターンなんて、
わざわざ言われなくても勝手に使っているものにしか見えない、というそもそもの問題がありますが。
この辺の「何をいまさら」感は、Template methodパターンとどっこいどっこいでしょう。

2011年7月24日日曜日

Iteratorパターン

注意:

  • この記事は適当に書かれています。あとでドリーが綺麗にまとめてくれます。
  • この記事はC#erな人が書いています。

現在デザインパターンを勉強中なのですが,さて,デザインパターンの中で一番を選ぶとしたら一体なんなのでしょうか。私が思うにそれはIteratorパターンでしょう。Iteratorパターンはプログラムを書く中で,最もよく使われ,最も直接目にすることはなく,今でも最もHOTなパターンです。

このパターンは集合に対し統一的にアクセスする時によく使われる実装を形式的にまとめたものでした。しかし今ではJavaを初めとし様々な言語でその実装を隠蔽しforeachとして利用できるようになっています。



Iteratorパターンは何故よく使われるのか,それは集合に対して汎用的に利用できるパターンだからでしょう。しかし最近ではメソッドチェーンと呼ばれるプログラムの書き方が流行り,集合に対する操作は今まで以上にエレガントに表現されるようになりました。

http://www.atmarkit.co.jp/fdotnet/chushin/comparedataproc_01/comparedataproc_01_01.html

今までのプログラムと見た目がぜんぜん違う!でも大丈夫,内部的には普通にIteratorパターンが使われています。Iteratorは不滅です。Javaはエレガントな言語じゃないので今まで通りifと一緒に拡張for文(Java5.0より追加された構文)を使ってください。



Iteratorパターンはよく内部イテレータと外部イテレータに分けて説明されます。多くの言語では外部イテレータの利用が言語レベルでサポートされています。では内部イテレータはどこで使われるのでしょうか。実は別のパターン,Observerパターンに姿を変えて利用されることがあります。

Observerは例えばマウス座標の監視などに使われます。でもよく考えるとObserverは連続で通知されるマウスの座標というデータを順に処理しているだけです。そう,これはIteratorパターンと同様なのです。Iteratorパターンがデータをpullして処理しているのに対し,Observerは向こうからデータがpushされる,ただそれだけの違いです。
さて,そんな事が真面目に研究されているプロジェクトがあります。その名もReactiveExtension.ちょっと調べてみるとpull型をpush型に変えるだけでこれだけの違いが現れるのかとびっくりします。

発端の映像はこちら(英語でココだけ見ても普通のことしか言ってないように見える)
http://channel9.msdn.com/blogs/charles/erik-meijer-rx-in-15-minutes
Reactive Exntensionがむっちゃ詳しいブログ
http://neue.cc/

ここらへんを見るとウヒョーとなれること,請け合いです。

2011年7月18日月曜日

デザインパターン絶賛考え中

誰かさんが部屋に置いていったオライリーの「Head First デザインパターン」を読んでます。
いやーこれは良い本ですね。
まだ斜め読みレベルですが、よく出来た本だと思います。
でも手元にあるのが第一刷だからか、怒涛の誤植祭りになってます。
修正がかかっているでしょうし、新しいのを改めて手に入れようかなとも思っています。
あるいは、英語のペーパーバック版のほうが値段が安いのでそっちにしようかな・・・

とりあえず、この本を(一週間かけて)読み終わってから、
頭の中でデザインパターンをまとめてみたいと思います。

とりあえず、今考えているのは、Strategy/State/Commandパターンについてです。
この本には、StrategyとStateは双子だと書いてあるみたいです(まだそこまで読めてませんが)。
デザインパターンを読み解く」では、
これにあわせてCommandも一緒だと指摘してあります。
確かに、ある関数(手続き/処理/アルゴリズム)をひとつのオブジェクトとして扱って、
交換や再利用などを楽にする、という方向性としては近いものを感じます。

手続きを状況に応じて入れ替える、というイメージだとStrategyに、
状態に応じて処理が切り替わっていくというイメージだとStateに、
それぞれをコマンドとみなして、キューにつんで実行していく、というイメージだとCommandになる、
というイメージを今のところは持っています。

Commandはともかく、Strategy/Stateではひとつの関数だけでなく
複数の関連する関数群をオブジェクトとしてまとめる、ということもあるでしょう。
その意味では、"Factory Methodを一まとめにしてオブジェクトにする"という
Abstract Factoryも、若干近い趣があるかもしれません。

まあ、まだまだ考え中です。

2011年7月10日日曜日

デザインパターンを(真の意味で)理解するために

デザインパターンを一通り勉強しようと、
日本語、英語問わずいろいろなウェブサイトを眺めているのですが、
いろいろとデザインパターンに対する疑問がわいてきました。

たとえば、有名なGoFの23パターンについて、
パターンの"粒度"もまちまちだし(一般的過ぎるものから、非常に限定された問題にのみ使えるものまで)、
分類の仕方もほかのやり方があるだろう、と感じました。

先人の知恵は示唆に富むものであることは重々承知なのですが、
深い理解のために知識を再構成することは非常に重要だと思うのです。
しかしながらウェブ上だと、
GoFの23パターンをずらずら説明しておしまい、みたいなところが多く見えます。
「もうちょっとなんか考えてから説明しろよ」と正直思ってしまいます。
で、いろいろ探して、参考になる(と現時点で思っている)次の2つを見つけました

デザインパターンを読み解く
Relationships between Design Patterns

前者は日本語のサイト、後者は英語で書かれた論文です。
どちらも、沢山あるデザインパターンの本質を考察し、
その位置づけや関係性を再構成しようとしています。
別にわかりやすくそれぞれのパターンを解説しているわけではないですし、
その解釈もこの両者で一致しているわけではありません。
しかしながら、このような努力は非常に素晴らしいものだと思いますし、
表面を舐めただけの解説よりも256倍ためになります。

今度からこれらのサイトを参考にしていきながら、
デザインパターンについてちょっと考えていきたいと思っています。
他にも参考になるものが見つかると尚良いのですが。
書籍のほうがまだマトモなのですかね?