这样的系统如何架构

[shengli_liao]

现在处在项目开发的瓶颈上，不过我们稍微幸运点，技术可以随自己的意愿，既可以采用最先进的，也可以采用较传统的，但是要求稳定。我们做的是比较复杂的业务计算应用系统，采用的Swing/Servlet技术，基于Weblogic/Oracle。这里介绍一下遇到的麻烦，目标是要做四个类似的子系统，各系统间的操作流程与数据流程基本相同，但在实现细节和数据结构方面有些差异，最开始想采用继承的方式，毕竟继承是面向对象的优越性嘛，先弄一个基础的系统模块，然后在该基础上根据不同的需求扩展成四个不同的系统，可后来发现这种方式对包名的定义都很费脑筋，而且数据结构定义，数据操作流程，界面的继承定义都几乎乱成一锅粥，只好放弃了这种模式。现在采用的四个不相干的子系统，由于各系统间的需求有差异，现在天天复制来复制去，时不时还出些简单的复制错误。不知道大家在遇上这类问题时如何解决，给点建议。

[睿音]

先反对一下这点：
> 毕竟继承是面向对象的优越性.
个人感觉在系统中多态才最体现了OO的优越性。
推荐由粒度小的接口构建系统，反对泛滥的继承。

[qioudong]

重复的代码太多不好，这样就失去面向对象编程的意义了
可以多用一些接口方法重写

[little06]

用interface吧
然后不停的修改问题，只能在设计的时候尽量考虑更多的问题

设计的框架才比较好

修改后，只能进行代码重构了

[heipn]

我觉得应该提供一些基础服务，供各个系统调用。不同的地方利用template模式，回调实现。也可以使用aop。抽象应该是对底层服务的，不能上层也抽象吧。个人意见啊。

[老紫竹]

给你个建议吧！

不要同时做4个系统，先集中兵力完成其中一个。

然后做第二个，同时对代码进行重构，特别是抽象出接口。 当然，如果你很自信，第一个就可以抽取出。

然后第三个，再次重构

...

重构的代码量，取决于你的经验了。

这种方式，可以保证立即有系统能使用，早期发现问题或者需求变更，你只修改1-2个，总比每次都修改4个好好吧！
领导会满意，你的团队也会有成就感！

[miaoliujun]

如果只是业务逻辑不一样分的4个子系统，而且目前需要大量的copy，可以在做之前仔细考虑哪些方法是公用的，先提取出来做成一个公用的方法包，应该可以解决你的copy问题。

[ian63]

4个不同的子系统，那就把公用部分抽象出来，做成组件，然后再在你的系统中在不同的位置以不同的方式调用这些组件。如果是我我就首先这样考虑。

[Bob_ouyang]

抽象出Interface吧.用Interface好点.
最好是不同继承. 继承破坏封装也不好修改.把接口定义准确点就可以了.(慎重定义接口)

[安优小青和他的程序生活]

先做一个
并且抽象出来接口
再做其他的系统,重构

[王启军]

可后来发现这种方式对包名的定义都很费脑筋，而且数据结构定义，数据操作流程，界面的继承定义都几乎乱成一锅粥，只好放弃了这种模式。


按道理是应该接口,实在想不出怎么会乱成一锅粥

[guoqiangone]

同意5楼的意见，
因为我们项目组（以前的公司）就是采用的这种方式，我们同时在做3个省的名称差不多都是一个样的系统，我们采用的是集中兵力先做完的一个项目，在这个省做项目（项目组是长期驻扎在这个地方，是外省），然后每隔1~2个月项目组就会掉几个人到其他省报告下项目进度（因为其他省也是要做的，都是得罪不的主），也顺便演示下项目，因为这三个省的项目需求是差不多，所以在期间就没有出现太大的问题，有点投机感觉的吧，呵呵。
其实当你做完第一个项目的时候，其他后面的项目也就是在不同的地方改改，因为都是差不多。