[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jfriends-ml 11546] Re: エクストリー ムプログラミングエピソード（ Re: JavaCC ）

高橋（徹）です。

   "murayama <locutus@xxxxxxxxxxxxxxxx>"さんは書きました：

> 私がUML屋が嫌いな理由の一つは，すぐ設計を複雑化させるというのも
> あるんですよねー．なんでこんなに無意味に複雑な設計にするのやら，
> まったく理解に苦しむ．設計を複雑にすると実装者がどれだけ苦労する
> 羽目になるのか想像できんのかな？
このエクストリームプログラミングエピソードでは、最初に
+-------+
| Game  |
+---+---+
    |
+---+---+
| Frame |
+---+---+
    |
+---+---+
| Throw |
+-------+
という思いつき(?)設計から開始します。
ボーリングの問題記述を行うと自然と登場する概念です。（設計上よいか
否かではなく）

この本では、XPなので、テストを考えてから実装していきます。詳細は
本やWebを参照していただくとして、エピソードの話しが進んでいくと、
ThrowやFrameには、テストするに値する振る舞いがないとの結論に達し、
最終的に実装ではThrowやFrameクラスは消滅し、GameとScorerの2つの
クラスとなります。
ボーリングの投球はint配列としてScoreの属性となり、Scoreには、投球の
累積から得点を算出するビジネスロジックが「きれいに」実装されるという
結果となりました。

> だからこそ「フレームをオブジェクトにする」という発想を最初からするのは
> 避けるべきだと思います．最初からこういう決断をし，それ以外の選択肢を
> 全く考えない辺りは，作者はアジャイルというよりはUMLモデラーなんじゃ
> ないかと勘ぐりたくなります．
多少うがった見方をすると、最初にOOD的な設計をしてから、実装へ落とし
込んでいく段階でテストファーストによる振る舞いの設計から最初の設計の
問題を浮き上がらせ、最終的にきれいな形に持っていく過程を見せている
のではないかとも考えられます。

P.35の記述を引用すると
“テストを最初に書くという行為は、設計上の判断をふるいにかける行為
 でもある”


---
TAKAHASHI Toru