SuppleDesign

Chapter 10 : Supple Design

• P245:supple designの反対は stiff design -- 狩野 (2010-05-26 02:20:12)

INTENTION-REVEALING INTERFACES

• このパターンは軽いジャブやね -- 村井 (2010-05-26 16:19:44)
• P246:細部をカプセル化しているのを「The beauty of objects」と表現しているのはおもしろいな -- 狩野 (2010-05-26 17:37:39)

SIDE -EFFECT-FREE FUNCTIONS

• P250: last paragraph: functionてのはmethodではなくて、関数型言語とかの関数ですね -- 村井 (2010-05-26 16:14:31)
• P252: Google先生いわく、(1/2) gallon = 1.89270589 リットル -- 名無しさん (2010-05-26 16:21:42)
• P252: queryとmodificationをseparateするのですね。モナド先生、出番です！ -- 村井 (2010-05-26 16:31:28)
• P252: CQRS先生！？ そこまで大きい話ではない模様です！ -- 村井 (2010-05-26 16:33:22)
• P252:for purists ←笑うところですね。わかります -- 狩野 (2010-05-26 18:19:46)
• P252:なるほどimmutableって便利だなって思った。 -- 狩野 (2010-05-26 18:28:12)

ASSERTIONS

• P257: 追加された、ミックスされていない絵の具の一覧を出す場合、引数を変更しているとなぜ都合が悪いのだろう？ -- kentaro714 (2010-05-26 11:39:57)
• P258:自分でこの発想が出来るかは微妙だなぁ… -- kentaro714 (2010-05-26 11:42:35)
• P258: Mix前の情報が必要だから、Mix前のままもっておき、Mix後の情報は必要になった時点で評価して返す、と。遅延実行とかカリー化とか連想する。 -- kentaro714 (2010-05-26 11:47:47)
• P258: Fig10.10 個人的には constituentsは StockPaintへじゃなくて、直接Paintに関連してもいいかな。StockPaint要らなくなる。MixedPaint同士を混ぜることができる。そうすると MixedPaintとPaintも１つでいいのか。よくわかんなくなってきた -- 村井 (2010-05-26 16:46:54)
• P255:委譲をいいかげんに使うとおっかないということがわかった -- 狩野 (2010-05-26 18:36:55)

CONCEPTUAL CONTOURS

• P260:1文目に激しく同意。 -- kentaro714 (2010-05-26 11:49:02)
• EarlyPaymentPolicyってなんなんだろう？ -- kentaro714 (2010-06-09 15:58:26)
• P260:high cohesion と low coupling は、conceptにもコードにも適用できる。 -- 狩野 (2010-06-09 17:57:05)
• P261:1段落目：conceptually meaningful unit ← Domain Drivenだなあと。 -- 狩野 (2010-06-09 17:58:34)
• P262:1段落目：「refactoringの範囲が局所化されるのはモデルに沿っていることになる」というのは、判断基準の一つとして興味深い。 -- 狩野 (2010-06-09 18:12:14)
• P264:1段落目：［じゅうよう］ドメインの概念と設計の一致 -- 狩野 (2010-06-09 18:29:54)
• 「intuitive」がなんども出てくるのが興味深い。 -- 狩野 (2010-06-09 18:31:50)

STANDALONE CLASSES

• 最初Singletonと勘違いして読んでた・・・ -- 村井 (2010-06-08 12:37:12)
• たいていはVALUE OBJECTというケースだよね。P266 下から7行目付近 -- 村井 (2010-06-08 12:44:40)
• P267: (メモ) STANDALONE CLASSES is an extreme of low coupling. -- 村井 (2010-06-08 12:45:50)
• P265:「一度に考えなきゃいけないことを減らす」って、いろいろなプラクティスの根底にある考え方ですよねー。 -- 狩野 (2010-06-09 18:47:53)
• KISSですねわかります -- 狩野 (2010-06-09 18:51:15)
• P266：上部斜体「what they represent」の意味がとれなかった。 -- 狩野 (2010-06-23 02:15:55)

CLOSURE OF OPERATIONS

• P268: 最初の引用 有理数、無理数とか、これは何かの伏線のようだが特に腑に落ちるような話が見つけられなかった -- 村井 (2010-06-09 12:50:45)
• P270: 遂にSmalltalkのコードが登場 -- 村井 (2010-06-09 12:52:25)
• @murai 有理数とか無理数の話は福久さんがいればぜひつなげてほしいところ。 -- kentaro714 (2010-06-09 16:01:52)
• ほぼそのままな引用ではあると思います。 -- kentaro714 (2010-06-09 16:06:03)
• 例が結局Collectionなのが残念きわまりない。 -- kentaro714 (2010-06-09 17:09:25)
• and, not, orなどの論理演算をSpecificationに閉じるように構成可能、という話が後で出てきてた。 -- kentaro714 (2010-06-09 17:53:57)
• P269：概念的に閉じていれば脳負荷が少ないという話か -- 狩野 (2010-06-23 02:45:36)

DECLARATIVE DESIGN

• とにかく長いが、Declarative Desingを広範に導入するのは厳しいよね、という論調。小さな範囲に絞れば有効な例も見てきた、ORMなど…という。基本同意見。例のアレはどうなんでしょう。 -- kentaro714 (2010-06-09 17:55:17)
• P272 2段落：レールの上で作ってる分には宣言的設計もよいけど、一歩外れると破滅ラウンジ -- 狩野 (2010-06-23 03:10:07)
• P272 最後：modelを修正するためには言語を修正することができる必要がある -- 狩野 (2010-06-23 03:18:23)
• P273 最初：保守チームのスキルを考慮して技術を選ぶことも必要 -- 狩野 (2010-06-23 03:20:21)

A Declarative Style of Design

• Declarative だと厳しいが、Styleを取り入れることで利点を得よう、というアプローチ。 -- kentaro714 (2010-06-09 17:55:49)
• P278:この例は必要なのだろうか？いまひとつ意図が見えない。 -- kentaro714 (2010-06-09 18:23:32)

Angles of Attack

• P289:思い切りSharePieの実装出てますね。星野さんのと比較してみたいところです。 -- kentaro714 (2010-06-17 12:40:20)
• P290:この辺、遙か昔に頑張って想像しながら一度やった内容ですね。 -- kentaro714 (2010-06-17 12:57:13)