しかしねぇ、コードという明確な形まで落としておかないとね。
頭に覚えてなきゃならないんで精神的にどんどんキツクなるんだよね。

設計とドキュメントは別というのは正しいのだが、
ウォーターフォールの場合はドキュメントの形に残さなければ
マイルストーンがあやふやになるので、プロセスがない状態と言っていい。

ＸＰはそういう意味では、開発全部の期間を設計にしようというスタイル。
マイルストーンは、ストーリー、タスクで図れるのでそれで問題ない。
また、デザインの失敗もリファクタリングによる調整で処理できる。
だから、いちいち全体ー全部なんて気にする必要がない。
コードが教えてくれるきれいな形を求めていけば
自然にシンプルでよい設計に落ち着く。

この点、設計でドキュメントベースでやってると、
設計の上できれいな形になっても、コードが汚くなる可能性が高い。

設計上の美しさのポイントとコードの美しさのポイントがずれるのが問題なのだ。

良い例が、ジャクソン法。ジャクソン法の設計は非常に美しいしわかりやすい。
だけど、コードがガタガタ。えらくこみいったものになる。

ＲＵＰの場合、以前誰かがリンクはってくれた
http://www.asahi-net.or.jp/~dp8t-asm/java/articles/ObjectModeling/article.html
の人、設計もモデリングも問題ない。

だけど、コードは、elseifが多すぎて何がなんだかという状態。
Factoryパターンを使ったから格好よいでしょ。
というのが趣旨なんだけど、あの程度じゃあそこまではいらない。
設計だけやってると、どうしても大げさになっちゃうんだよ。
ご苦労さまという感じ（＾＾；

ItemFactory.javaで結局 DVDクラス生成するところで、
CDクラス呼んじゃってるしなぁ。筆がすべってしまったのだろうけど。

ＸＰは、コードセントリックな設計法だから、すなわち
コードが美しくてシンプルなのがベストな設計法と言っていい。
基準がひとつなので、管理しやすいし、同じ方向をみんなで向きやすい。

設計期間がｘ倍。美しさの基準がひとつ。
シンプルでいいね。ＸＰマンセー。