山崎＠東工大です。
> > > OOで設計した場合、1:9（あるいは2:8)の1(あるは2)の部分が、9(あるいは8)に
> > > 影響を与えます
>
> 私のイメージともしかすると違いがあるのかもしれません（し、いのかもしれ
> ませんが、そのあたり私が曖昧にしか書いていないため分からない）のでもう少
> しイメージを補足いたします。
>
> 私は、1(あるいは2)の部分がコアの部分と考えています。
> 想定したシステムの1（あるいは2）ぐらいの規模のものがコアになり、それが
> しっかり作れればあとはかなり安定して実装や保守をしていけるという実感があ
> ります。もちろんコアをとても汎用的なフレームワークとして考え実装しようと
> した場合には、1（あるいは2）以上の大きさになる場合もあると思います。
以前に僕はこう書いたのですが、
> この問題に関してごうぎさんと僕の認識の違いとなっているのは、恐らく最初
> に用意するコアとか叩き台の規模だけなのではないかと思います。
規模だけではなく、コアという言葉の捉え方が違っていたようです。まず、
コア：システムの中核
というところは一致できると思います。ごうぎさんのイメージを解釈しますと、
コア：システムの中核：システムの主要な動作を定めているクラス群
という性質が加わるのではないかと思います。ここで重要なのは、ごうぎさん
の「安定する実感がある」という言葉を踏まえると、コアの範囲を決めるのは
実装以前ということになります。
一方、僕の最初のメールでは
> 恐らくこの問題に関してもいわゆる 1:9 の法則があって、ほとんどのクラス
> は責務の分析をしっかりやらずにプログラミングしてもあまり問題がないが、
> 一部のクラスは分析をしっかりやる必要があり、そのバランスをうまく調整す
> る必要があるという事ではないでしょうか。
と書いていた訳ですが、この 1 のクラス群というのは、実装後に分析／設計
を振り返ってみた時に、他への影響が大きいと判断したクラス群です。そのよ
うなクラスはコアの中でも特に影響力の大きな部分です。つまり、
(僕の言う)分析をしっかり行う必要のあるクラス ＜ (ごうぎさんの言う)コア
という関係が成り立ちそうです。僕の実感では、コアは全体の2割くらいで、
その中でも実際に影響力の大きなクラスは全体の1割くらいです。この数字は
恐らくごうぎさんも納得頂けるのではないかと思います。
> だたこういうアプローチだと分析をしっかりしないといけないし、設計でも責
> 務を綺麗に洗練分類しそれを元にインターフェースを定義し同時にそれを使う仕
> 掛けも作ってていくことなどが必要になります。XPでこういったことを最初にし
> っかりするのは相応しくなく感じていたのです。しかし、責務を強く意識してXP
> をしていると次第に上記のアプローチに近づいていくように感じました。そして
> 実際かなり近づいた時にXPがどういった姿になっているのか悩んでいたのでした。
この点に関する僕の仮説は次の二つです。
(1) 分析をしっかり行う必要のあるクラスは、実はそれほど多くなく、分析前
に推測可能である。
(2) 分析をしっかり行っても XP に自然に取り込む事が出来る。
(1)については繰り返しになりますので、ここでは詳しく述べません。
(2)については、XP でもプログラミングに入る前に分析／設計を行うわけです
が、その比重が若干変わることになるだけではないかと思います。XP 白本を
読み直したのですが、ペアプログラミングは、さくさくコードを書くためでは
なく、ペアで互いにレビューし合う事で意識の共有を図りながら実装を進める
ために行うと僕は解釈しました。つまり例えばごうぎさんと僕がペアを組んで
いて、ごうぎさんが詳細な分析の必要性を主張して僕が同意したならば、分析
に力を注いだ後でテストを書いてコーディングに入っても何ら問題はないと考
えます。
山崎 進 --- yamazaki@....jp
東京工業大学数理計算科学専攻柴山研