塚本です。
>>>>> "firo" == 矢崎 博英 <firo@....jp> writes:
firo> 矢崎です。リプライありがとうございます。
(中略)
firo> ですから、
firo> XPは柔軟性、再利用性に対立するものではない。しかし、それを
firo> やみくもに行うことには反対する。必要な時に必要な程度で行う。
ありがとうございます。やはり原則はそうですね。
それでも、個人的にいって「Refactoring すればどうにかなる」という過度の
幻想は抱けません。要件の決め打ちが支配的なシステムを作ると、追加要件の
内容次第では Refactoring の必要なユニットだらけになると思うのです。
# 開発コストが「運任せ(要件の着順次第)」になりそうなイメージがあります。
それはそうと、最初のメールで
firo> これも例えばなのですが、デザインパターンにしろ、Fowlerのアナリシス
firo> パターンにしろ、ある種の柔軟性、再利用性、拡張性のようなものを
firo> ねらいとしているところが多いと思うのですが、これらはXPのシンプル
firo> と対立するものなのでしょうか？
とありましたが、パターンは Refactoring を行なう時の良いお手本になると
思います。
>>>>> "石井" == 石井 勝 <mishii@....jp> writes:
石井> Simplicityについてですが，
>> ２．柔軟性を考慮しなくても、後からそれが必要になったときに、
>> Refactoringなどを行って柔軟性を確保することができるように
>> なる。よって、Simplicityとは、必要になるまでは柔軟性を考慮
>> しない（それが必要になったらする）。
石井> 僕はXPを調べたときこっちだという印象を受けました．
石井> というか，柔軟性という単語にひっかかるのですが，現在の仕様
石井> （テスト）に対してもっとも簡単なものであればよい，ということでしょう．
石井> 現在の仕様がMVCを求めるものであればそうするでしょうし，求めない
石井> ならMVCを使うのはoverkillということではないでしょうか？
「現在の」を額面通りに考えすぎると勝手が良くないケースもありそうです。
例えばこんなケースを想定してみて下さい。
現在の初号機: 1 [CPU/ボード]
次期の二号機: 1..4 [CPU/ボード]
次期への移行コストを考えると、ボード 対 CPU の関連は最初から「1:多」に
モデリングされるケースもあると思います。初号機についてはCPU側の多重度
1..m に制約 {m=1} がついて test suite も 1 CPU 用に限定されますけど。
MVC にしても、フレームワークとして提供されているものを「使う」ぶんには
MVC なしの実装をスクラッチで書くよりもむしろ、アプリケーションコードは
シンプルになり得ると思います。
話は変わりますが、「シンプル」と「拡張性」の両立というと、XP が OCP
(Open-Closed Principle) とどのように協調できるかにも興味があるのですが、
そのあたりはいかがでしょう?
--
Yoshihiro Tsukamoto