矢崎です。リプライありがとうございます。
石井 勝 さんwrote:
> 石井です．
> Simplicityについてですが，
>
> > ２．柔軟性を考慮しなくても、後からそれが必要になったときに、
> > Refactoringなどを行って柔軟性を確保することができるように
> > なる。よって、Simplicityとは、必要になるまでは柔軟性を考慮
> > しない（それが必要になったらする）。
>
> 僕はXPを調べたときこっちだという印象を受けました．
> というか，柔軟性という単語にひっかかるのですが，現在の仕様
> （テスト）に対してもっとも簡単なものであればよい，ということでしょう．
> 現在の仕様がMVCを求めるものであればそうするでしょうし，求めない
> ならMVCを使うのはoverkillということではないでしょうか？
>
> Simplicityについては，柔軟性うんぬんより Communication
> とOnce and Only Once が基本だと思います(XP本のP109)．
> この2点については，Kent Beckの"Best Practice Patterns"
> でも強調されています．
>
109ページには、次のようにまとめられていますね。
Simplestとは、、、
１．システム（コードとテストの両方）が、あなたがコミュニケ-トしたい全て
のことをコミュニケートしなければならない。
２．コードの重複を含んではならない
＃１と２をあわせて、Once and Only Once ruleと呼ぶ。
３．可能な範囲で少ないクラスであること。
４．可能な範囲で少ないメソッドであること。
３、４については**ちょい疑問**ですが（解釈まちがってます？）、１、２に
ついてはAgreeですね。私としては、（もちろん１も絶対なのですが）２につ
いてはSimplestの設計上の絶対条件としてとらえたい気がします。
＃つまりは、重複のあるコードはSimpleではない。。。。。
--
矢崎博英 firo@....jp