Date:  Sat, 26 Jul 2003 00:45:15 +0900
From:  川端　光義 <kawabata@....jp>
Subject:  [XP-jp:04548] Re: 「 An Extreme Programming Episode 」の翻訳版を掲載しました
To:  extremeprogramming-jp@....jp
Message-Id:  <20030725235341.EA3A.KAWABATA@....jp>
In-Reply-To:  <20030724233847.B1D7.AKASAKA.H@....com>
References:  <3F1E2019.726004CB@....jp> <20030724233847.B1D7.AKASAKA.H@....com>
X-Mail-Count: 04548

川端です．

たくさんの方にご覧いただけて，とても嬉しいです．

またコメントをありがとうございました．

赤坂さん，平鍋さん wrote:
> > でも、Gameのadd(11)の問題はこのままで良いの？とか気になる部分がいくつか
> > あります。最後のコードを見ると本当にシンプルで解り易いのでしょうか？
> > 結局、GameとScoreの２つのクラスに落ち着いてしまいましたが、クラス図にし
> > てみると、私には結構ダザイ感じがします。
> > Gameがフレームの1投目かどうかを知ってる(firstThrowInFrame)とか、フレーム
> > の知識も知ってるとか。また、Scoreがスコア計算用に持っているballという属
> > 性は解り難いような気がします。
> 
> ええ，わたしもめちゃダサだと思いますよ．でも，テスト駆動開発がこう導いた
> なら，それはそれで一つの収束解かと．

このことは私もすごく悩みました．
ペアプロする相手によっても，収束解って変わりますよね．

で，役割をきっちりさせる意味でもっとリファクタリングできるんでしょうが，
YAGNIの原則に反するのか？っていう感じもしました．
オブジェクト指向的には，ダサイと思うんですが，これは
ＸＰでいうシンプルなのかな？とも思いました．

例えば，ボーリングのルールを変更した時，
数多く作られたクラスと，２つだけのクラスとでは
実際どちらが早く仕様変更に対応できるか？
普通は役割が分かれているモデルの方が仕変に強いと思いますが，
予想しない変更だった場合，どうなんだろう？と．

この辺，皆さんの意見を伺いたいです．



■■■............ Agileware.jp
   アジャイルウェア
      川端 光義
   E-mail：kawabata@....jp
   URL：http://agileware.jp
--- Agileware.jp ---------■■■■■■