山崎＠東工大です。
> > > コードは以下みたいな感じで書きたいです。
> > > // Input ⇒ (Intermediary ⇒) Output
> > > Input input;
> > > Intermediary inter = Input.toIntermediary();
> > > Output output = Inter.toOutput()
> >
> > Intermediary inter = input.toIntermediary();
> > Output output = inter.toOutput();
> >
> > ですよね？
>
> え？そうですけど、何か違ってましたか？
> # inputが未初期化のこと？...きっと、入力パラメータですね(^^;;
いや、Input.toIntermediary(); と小文字でなく大文字でクラスメソッドのよ
うに書いていたものですから。細かくてすみません。
> > Input -> Intermediary -> Output のようにクラスが変化するならばこれで良
> > いと思うのですが、同一のクラスに、データが蓄積されたり、内部データが変
> > 換されたりする場合には、どのようにするのが良いとお考えですか？
>
> データが蓄積される場合は、それは重要な別の概念としてクラスを抽出します。
> 内部データが変換されるケースは、状況にもよると思いますが、
> 内部データの状態（に付属する変化するデータ構造）として扱いたいですね。
Intermediary のフィールドとして蓄積されるデータや状態を表すオブジェク
トを用意するということですね。
> > そこで、解決策としては処理を分割する時に、将来の変更の余地がないほど粒
> > 度を細かく分割し、粗粒度の機能クラスを細粒度の機能クラスのコンポジショ
> > ンとして構成すればよいのではないかと考えてみました。
> >
> > 図に書くと次のようなイメージです。
> > +------------------------+
> > |Process1 | -> ...
> > +------------------------+
> > | | |
> > +------+ +------+ +------+
> > |Sub1-1| |Sub1-2| |Sub1-3|
> > +------+ +------+ +------+
> >
> > テストケースは細粒度の機能クラスに対して書きます。テストケースクラス自
> > 体は増えますが、一つ一つの機能クラスは単純なので、一つのクラスに対して
> > 考えるべきテストケースは少なく抑えることができ、全体のテストの数はあま
> > り増加しないでしょう。このテストは処理の組み換えが起こっても再利用する
> > ことができます。
(中略)
> > 粗粒度の機能クラスに対するテストは結合テストとなるので、処理の組み換え
> > が起こると書き直す必要があるでしょう。しかし、細粒度の機能クラスの単体
> > テストが十分整備されていれば、結合テストの数を抑えることができるので、
> > 書き直しのコストは減るものと思われます。
>
> でも、（これも状況次第になってしまいますが）
> 実はこれら小粒度の機能クラスについては、適切なメソッドに分割されていれば、
> 「メソッドの移動」で充分に対応可能な（それほど大変ではない）のではないか
> とも思いますが、いかがでしょうか？
細粒度の機能クラスを抽出すること自体は、それほど大変ではないのかもしれ
ません。むしろ大変なのは、テストケースの構成を変えなくてはいけないこと
で、細粒度の機能クラスの単体テストを整備して、必要に応じて粗粒度の機能
クラスの結合テストを変更しなくてはならないわけですから。
山崎 進 --- yamazaki@....jp
東京工業大学数理計算科学専攻柴山研