On Tue, 28 Sep 2004 23:34:06 +0900,
kitajima <********@*****.**.**> wrote:
> > > 機能ごとに頻繁に改修がはいるので、下手に共通クラスを作るより、別個のク
> > > ラスに似たような実装を施したほうが、PGのアサイン・管理も楽だったりしま
> > > す。
> >
> > コードが重複していたほうが良いというのは、僕には理解
> > しがたいので質問です。
> 画面間でデータを使いまわすケースでは、共通クラス(VOに近い)を作っていま
> すが、共通といっても、あくまでその画面で必要となるデータを意識したつく
> りになるので、あまり機能横断的な汎用性は考えられていません。
> 汎用性を持たせると、ある機能で修正があった場合、別の機能にまで影響が及
> んでしまうため、避けた方が無難なケース、でしょうか。
なるほど。そもそも共通化できそうなものが無いというケース
なんですね。勘違いしていました。
> > PGのアサインや管理が楽なのはどういう面なんでしょうか?
>
> Aという機能と、Bという機能に、ほぼ同時に修正が要求された場合、
> Aの修正をXさんに割り当て、Bの修正をYさんに割り当てるとします。
> AとBで共通して使用するクラスがあった場合、どちらかの修正が終わるまで他
> 方にソースを開放できないため、同時進行で修正できない、ということがあり
> ます。
これは、ロックしないタイプのバージョン管理ツールを使えば
解決する問題ではないのでしょうか?
構成管理のポリシーがあって、それにアーキテクチャが左右され
ているわけですよね。もろもろの事情で、構成管理のポリシーが
ソフトウェアのアーキテクチャより重要なのであれば、しかたが
ない事なんでしょうけど、視点を変えることはできないのかなと
思いました。
> また、先にAの修正を加えたため、複雑化した共通クラスに、さらにBの修正を
> 加えた結果、2段階の複雑さを増してしまい、A・Bどちらにとっても「読みづ
> らい」ソースになることも考えられます。
リファクタリング…:-)
-- Yuji Yamano <*******@**.***.**.**>
Loan me your funky mind. So I can play with it,
for nothing is good unless you play with it. --George Clinton