和訳： Project Lambda (前半)

注：この文書はProject Lambdaの提案を和訳したものです。訳の正確性は保証しません。
この文章におかしなところがあればオリジナルを参照してください。

Brian Goetz 2010/10/10

この文書はJava言語にラムダ式を追加する案です。このスケッチはMark Reinholdによって 2009/12に作られた原案をもとに作られました。前のバージョンは2010年7月に発表されました。

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パターンとどっこいどっこいでしょう。

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/

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

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

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

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

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

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

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

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

くいずです（JavaScript apply編）

くいずです
pushを　じっこう　したとき　あらーと　で　でる　もじれつ　なーんだ

var x =" World";
var o = { x: "He" };
 
function f(m){
 for(var i = 0; i < arguments.length; i++){
  m+=arguments[i];
 }
 m = this.x + m;
 alert(m)
};
function push(){
 f.apply(o,new Array("l","o",this.x));
};

こたえ
こんなの一発で理解できたらすごいです。
元ネタ、というか参考サイト