石橋秀仁です。このMLは久しぶりの投稿です。
Kaoru Hosokawa <khosokawa@....com> wrote:
> ホソカワです。ちょっと遅いレスです。
> > 佃です。
> > TFPを実践しているみなさんはボトムアップで開発をしているので
> > しょうか？
> > このような悩みは私だけでしょうか？
>
> 確かに、トップダウンで作っていくと、通らないテストのスタックができていくでしょ
> うね。でも、トップダウンにもなにかリズムがあるような気がします。
>
> 例えば、Wake氏のサンプルをトップダウンで書くとすると、
> のようなメソッドを私は考えます。TFPは、ここでメソッドの中身を書く前にテスト
> を書きましょうと言っているので、テストを書きます。
> コンパイルが全然通らないので、一つ一つクラスを定義していきます。
> これでコンパイルが通り、テストも実行できます。私は、これで、one cycle が終わっ
> たと思っています。この繰り返しがリズムを作り出すのではないでしょうか？
ぼくも似ています。このへん、インタプリタ言語は強いですね。
UNIXのコマンドライン(bash)とvi（人によってはemacs）と
rubyとRubyUnitの組み合わせは、とても快適です。
＃ちなみに、Smalltalkは、やっていません。
＃来年、時間があればsqueakに手を出します。
未定義のメソッドについても、method_missingをオーバライドするなり、
スタブを突っ込むなり、いくらでも「実行」させる方法があります。
それも、「リズム」を損なわずに、というのが重要だと思いますが、
リズミカルにできています。
＃惜しむらくは、弊社にプログラマが私一人なので、
＃原理的にペアプロが不可能であること (^^;
というような方法で、少なくともトップダウンでやっていて、
不自由はしていません。
なお、TFPにはいる前、つまりコーディングに手を付ける前に、
パッケージ内のクラス郡の協調関係までは、おおまかに
決めておきます。CRCカードやUML（もちろん手書き）を使って。
このMLでは標準的な方法であるように見受けられますが、どうでしょう？
さてさて、僭越ながらノウハウを言いますと、最初の協調関係
（と静的構造の設計）の段階で、すこし工夫すると、
よりよい「リズム」でプログラミングできます。
概要：
リファクタリングをしやすくするために、
システムを、独立して変更可能な、小規模なサブシステムに分割する
方針：
「継続的にリファクタリングしやすい構造」を考えます。
代償として、最初から「理想的なクラス構造」にたどり着くことを
放棄します。低結合度／高凝集度（だったかな？）指向ということで。
実際：
FacadeやProxyなどのパターンを用いて、システムをサブシステム
（パッケージ）単位に分割します。パッケージ中でも、さらに
サブパッケージに・・・と再帰的に。経験上、分割の目安は
構成要素数がマジックナンバー（７±２）に到達するくらいまでかな、
となんとなく思っています。
低結合／高凝集にするためのパターンは、どれも役立つと思います。
デメリット：
リファクタリングを前提にすることで、記憶領域や実行時間の面で、
デメリットがあります。空間効率上、時間効率上の無駄が増えます。
POSA本の6章？に書いてあったと記憶していますが、
「柔軟性はタダではない」ですね。もちろん間接性を高めることによる
コストは大きいです。最初からがっちり静的構造を決めてしまえば、
無駄な中間（ファサードなど）クラスが多数出てくることになります。
でも、よほどの頭脳でなければそんなの無理だし・・・
というわけで、リファクタリングという活動を、
設計上の方針にも組み込んでいるという話です。
ひょっとして『リファクタリング』に書いてあったりします？
買っただけで読んでいないので (^^;;;
よりよくするためのご指摘いただければ幸いです。
--
石橋秀仁 hideto-i@....jp
i-mode: i.sys@....jp
ICQ#: 83329246 MSN: hideto_i@....com
Do you like jazz? jazzbar@....com