山崎＠東工大です。
> > というのも、当時も今も、少しずつスタイルや作業の質が変わりながらも、設計・実
> > 装時ともに、責務を強く意識して設計（あるいは実装しながら設計）すると、自然にパ
> > タンの適用やインターフェース間のプロトコルの設計、構造（仕掛けを含む）の設計を
> > 伴ってしまうからです。そうでないとしっくりこないのです。そして、この責務を重視
> > したアプローチはかなりしっかりしたモデリングやコアな部分の作りこみを自然と伴い
> > 、そこから見るとXP的ではないように感じたということです。
恐らくこの問題に関してもいわゆる 1:9 の法則があって、ほとんどのクラス
は責務の分析をしっかりやらずにプログラミングしてもあまり問題がないが、
一部のクラスは分析をしっかりやる必要があり、そのバランスをうまく調整す
る必要があるという事ではないでしょうか。
> 結局は、時間をかけてもかけなくても（XPかどうかに関わらず）、不自然な役割
> が見えてきたときにリファクタリングする必要があるわけですよね。
僕が問題を感じるのは、責務を変更するようなリファクタリングは比較的コス
トが高く、責務を分析すべき所でしっかり分析しないと後で痛い目にあう場合
があるということです。
実際に経験した例では、一連の処理を段階ごとに分解(A->B->C->...)し、それ
ぞれの段階の中間結果オブジェクトを渡す設計にしたのですが、各段階で行う
処理の責務を変更せざるを得なくなった時(特に中間結果のインターフェース
を変えざるを得なくなった時)、各段階ごとに作成した膨大なテストケースを
修正する必要に迫られて困った事があります。
いつ詳細な分析を必要とするかという問題は、経験に依って判断する要素が多
いようで、デザインパターンとまでは行かなくてもリファクタリングで述べら
れいる「不吉な臭い」のような形で良いのでカタログ化できないものかと個人
的に思います。
山崎 進 --- yamazaki@....jp
東京工業大学数理計算科学専攻柴山研