kitajimaです。
> > 機能ごとに頻繁に改修がはいるので、下手に共通クラスを作るより、別個のク
> > ラスに似たような実装を施したほうが、PGのアサイン・管理も楽だったりしま
> > す。
>
> コードが重複していたほうが良いというのは、僕には理解
> しがたいので質問です。
>
> うまく作れば一箇所で修正がすむところを、何箇所も修正
> しなければならないと、変更コストが大きく増える思うの
> ですが、それは問題にならないんでしょうか?
# 村山様、「赤旗」「青旗」のフォローありがとうございます。
実現したいことは、
1. DBからデータを取得して、
2. 画面用に加工して、
3. 画面表示する
なので、
1. はSQLの最適化のため、それぞれ別個にコーディング
2. は画面を意識して画面ごとに別個にコーディング
となると、共通化できる部分が・・・。
画面間でデータを使いまわすケースでは、共通クラス(VOに近い)を作っていま
すが、共通といっても、あくまでその画面で必要となるデータを意識したつく
りになるので、あまり機能横断的な汎用性は考えられていません。
汎用性を持たせると、ある機能で修正があった場合、別の機能にまで影響が及
んでしまうため、避けた方が無難なケース、でしょうか。
> PGのアサインや管理が楽なのはどういう面なんでしょうか?
Aという機能と、Bという機能に、ほぼ同時に修正が要求された場合、
Aの修正をXさんに割り当て、Bの修正をYさんに割り当てるとします。
AとBで共通して使用するクラスがあった場合、どちらかの修正が終わるまで他
方にソースを開放できないため、同時進行で修正できない、ということがあり
ます。
また、先にAの修正を加えたため、複雑化した共通クラスに、さらにBの修正を
加えた結果、2段階の複雑さを増してしまい、A・Bどちらにとっても「読みづ
らい」ソースになることも考えられます。
村山様のご指摘のとおり、制御ロジック・業務ロジックがオブジェクトの中に
書き込まれる点が原因ですね。
ロジック部分を外に出してそれをモデルクラスとして、更に簡潔な(アトミッ
クな)データとデータ処理だけを残した「オブジェクトらしいオブジェクト」
を作る、では、解決になりませんね。結局「どんどん複雑になっていくロジッ
ククラス」というのが残ってしまいます。