CLOSURE OF OPERATION (P268) †
要約 †
- P268-1 (If we take 〜)
- 2 つの実数を受け取ってそれらを掛けると別の実数が得られます．これを，実数は「掛け算について閉じている」といいます．
[問題についての説明]
- P268-2 (Of course, 〜)
- もちろん依存性があり，その依存性が概念の基礎となるならそれは悪くありません．インタフェースをプリミティブだけにしてしまうと貧しいものになってしまいます．しかし，多くの不必要な依存性や概念全体もインタフェースに導入されます．
問題サマリ
- P268-3 (Most interesting objects 〜)
- 大部分の興味深いオブジェクトは，プリミティブだけで特徴付けることはできません．
[問題の解決方法についての説明]
- P268-4 (Another common practice 〜)
- 1 + 1 = 2 のような加算操作は実数の集合に閉じています．これは同様にソフトウェアデザインでも広く使われます．XSLT の基本的な使い方は XML ドキュメントを別の XML ドキュメントに変換することです．この操作は XML ドキュメントの集合に閉じています．閉包は操作の解釈を単純化し，メソッドチェーンを容易にします．
解決方法サマリ
- P268-6 (Where it fits, 〜)
- 当てはまるのであれば，操作の戻り値の型は引数の型と同じにしてください．そのような操作はその型の集合に閉じています．閉じた操作は他の概念への依存を導入することなく，高レベルのインタフェースを提供します．
[結果、実装上の検討事項]
- P269-1 (This pattern is 〜)
- ほとんどの場合，このパターンは VALUE OBJECT の操作に適用されます．ENTITY はライフ作るを持つため，新しいインスタンスを返すことができません．ENTITY に閉じた操作もあり得ますが，一般に ENTITIES は計算の結果となるような概念ではありません．そこで多くの場合，VALUE OBJECTS を見つける好機となります．
- P269-2 (An operation can be 〜)
- 操作は抽象型について閉じることができます．その場合，引数の型を実装型と異なるものにできます．加算は実数に閉じていますが，それは有理数も無理数もあり得ます．
- P269-3 (As you're experimenting, 〜)
- 相互依存を減らし，凝集度を高める方法を模索していると，時々このパターンに至ります．
- P269-4 (In the earlier example, 〜)
- 以前の例で，PIGMENT COLOR の mixedWith() 操作は PIGMENT COLOR に閉じていました．他の例も本書の中にちりばめられています．本当の CLOSURE に至らない場合でも，この考えがどれほど役に立つかについて示す例がここあります．
例：コレクションからの選択 †
- P269-5 (In Java, 〜)
- Java では，Collection の部分集合を選びたければ，Iterator を求めます．それから要素を繰り返し，それぞれテストし，マッチしたものを新しい Collection に累積するでしょう．
- (P269 のコード)
- P270-1 (Conceptually, I've 〜)
- 概念としては，集合から部分集合を選ぶだけなのに，余計な概念，Iterator やメカニカルな複雑さはなぜ必要なのでしょうか？ Smalltalk では，Collection の「select」操作を呼び出し，テストを引数で渡します．戻り値はまさに，テストをパスした要素を含んでいる新しい Collection です．
- (P270 のコード)
- P270-2 (The Smalltalk 〜)
- Smalltalk の Collection は他にも Collection を継承した具象クラスを返すいくつかの FUNCTIONS を提供します．それらの操作は「ブロック」を引数として受け取るので，閉じてはいません．しかしブックは Smalltalk の基本的なライブラリ型なので，開発者の精神的な負荷を増しません．それらは簡単に書けて簡単に読めます．それらは部分集合を選択するという問題とは無関係な概念を導入しません．
＊＊＊
- P270-3 (The patterns presented 〜)
- 本章で示しているパターンは設計の一般的なスタイルや設計についての考え方を説明しています．ソフトウェアを明白で，予測可能で，コミュニケーティブにすることは，抽象化とカプセル化を効果的にします．モデルは，オブジェクトがシンプルで使いやすく理解しやすい上に，豊かで高水準のインタフェースを持つための要因となることができます．
- P270-4 (These techniques require 〜)
- MODEL-DRIVEN DESIGN の有用性は設計の詳細や実装の決定のクオリティに敏感で，少数の混乱した開発者をプロジェクトのゴールから脱線させることもあります．
- P270-5 (That said, 〜)
- それは，チームがモデリングや設計のスキルを修練して，これらのパターンや考え方がソフトウェアに反映され，開発者が作業とやり直しにより，複雑なソフトウェアを作れるようになるということです．
担当者のつぶやき †
- Java7 で導入されるだのされないだのと話題で，関数型言語では当たり前の，あのクロージャとは関係ありません．
- P268 の 2 段落目 (実質本文の一段落目) が何を言ってるのかサッパリ分かりません．primitive って何を指してるんだろ？ Java のプリミティブ型のことではなさそうだけど．
- 自分自身に閉じている操作のことを指しているのかも．他のものに依存していないという意味で原始的．そういうメソッドだけからなるインタフェースはたしかに貧しいものになりそう．
- 例から後ろはほとんど全訳になってしまった．要約は難しい．．．
みんなの突っ込み †
- 僕は最初primitiveってプリミティブ型だと思ってましたよ（汗）。もっとも、intとStringとを厳密に区別する意図はないでしょうが。さしあたり、「特定のモデルに限定されない、極めて普遍的なもの」と解釈しておくのはいかがでしょう。 -- 和智?
- 最近流行の「流れるようなインタフェース」と、似ているようで違いますね。 -- 佐藤?
- p.268-l.2ですが、あらためて読んでも難しいですね・・・ムリに解釈すると「もちろん、依存というものは存在するわけだし、それが特定の概念にとって本質的なものなのであれば、悪いことでもない。インターフェイスはプリミティブしか扱ってはいけないとしてしまっては、貧相になるだけだ。しかし、多くの不必要な依存性や、もっと言えば概念の全体が現れてくるのはどこかと言われれば、それもやっぱりインターフェイスなのだ。」ということなのでしょうか。 -- 和智?
