来请教一下各位大佬,项目的代码设计模式应该怎么选用

[k.]

例如:
一个项目基础功能点100个功能点,
然后A项目 加了30个特殊的二开需求,
B项目加了20个特殊的二开需求,其中有5个和A项目的需求一样
C项目加了10个特殊需求,和AB项目需求都不重合.

这个项目我预测基本的功能开发完代码量在5W-6W行左右.大概要有500个项目吧.
小弟我第一次接触这样的项目,有什么好的设计模式可以方便以后的代码维护吗?

我现在想好的有两种方式:
1.把所有的功能点都抽象出来,然后看哪个功能点要修改了,我去重写一下然后通过工厂方法去找要用的子类
这种我现在能想到的缺点问别人说后期代码维护成本高.
2.每个项目拷一套代码(反正代码量也不多),然后修改完后,上传SVN.
这种目前想到的缺点是如果要修改一个基类功能要所有的项目都打开一遍修改编译....

现在比较纠结,不知道要选哪种模式,希望各位大佬可以建议一下.谢谢.

[wanghui0380]

更改思路 ，不是你调用我，我调用你。而是我发个消息，有人响应就响应，没人响应就没人响应。 加入eventbus，把东西变成消息驱动 不管你多少项目，都是一样。项目A，有20组消息，80个响应。 项目B需要响应的就响应，不需要响应的不理。 实际上这也是java的人为啥在使用kafaka的原因，全部隔离开。每个模块都没有直接引用，只有发消息，响应消息，他们谁也不认识谁。 你就像你现在一样，我不认识你，你也不认识我。你只是发了一个消息，我只是无聊响应你的消息

[OrdinaryCoder]

我也想知道有什么好的方式 能想到的： 利用插件的形式 每种功能制作成插件 需要哪个插哪个

[k.]

还有一种情况忘记说了: D项目中有10个需求点是在基础需求上修改一下的. 还有是C/S的项目.

[k.]

引用 1 楼 wanghui0380 的回复:

更改思路 ，不是你调用我，我调用你。而是我发个消息，有人响应就响应，没人响应就没人响应。 加入eventbus，把东西变成消息驱动 不管你多少项目，都是一样。项目A，有20组消息，80个响应。 项目B需要响应的就响应，不需要响应的不理。 实际上这也是java的人为啥在使用kafaka的原因，全部隔离开。每个模块都没有直接引用，只有发消息，响应消息，他们谁也不认识谁。 你就像你现在一样，我不认识你，你也不认识我。你只是发了一个消息，我只是无聊响应你的消息

我可以理解为服务端有所有的功能点,然后客户端随便怎么访问吗?

[圣殿骑士18]

1、没有银弹 2、底层抽象，上层模板化 3、掌握如上基本原则，开发中优化（比如哪些是可以抽象的，应该抽象的，不能抽象的）

[以专业开发人员为伍]

设计其实就是“画图”，而“抽象和扩展”的图形，在类型图、状态图、用例图、活动图等等软件工程所需要以来的图纸上都需要有体现。这个不适合本末倒置。

在部署的时候，每一个项目总归有自己的启动代码，手写启动自己的子类的代码就可以了。不同项目的子类可以从公共类库继承父类的功能，但是每一个项目没有必要部署无关的东西，每一个项目的特别的东西应该分开、让其他项目摸不到。

[以专业开发人员为伍]

有一种看似好像“强”实则其实很弱的思路，就是有些人喜欢搞所谓的“集中管理各种类型”的类型，也就是滥用“工厂方法”这个名词儿。实际上是否恰当、有没有能力，做过了才知道。一般人要理解不是喊喊口号就能把一切变数都放到一个巨大且杂乱的类型的。

[以专业开发人员为伍]

我们设计、编程的时候，自然是能少设计类型（包括接口）就少设计类型，能少抽象就少抽象，能少变体就不要替换。真正善于管理大量的“抽象与扩展”特性的人反而知道如何少做，所以你看到的总是高效率、高扩展、特别浅显和“自然而然”的实现，而不是多么纠结“技术化”的东西。这个方面是一种哲学，没有反复走过的道路是不知道深浅的。记住这个经验就行了。

[threenewbee]

开发完代码量在5W-6W行左右.大概要有500个项目吧
这都是什么意思

很久以前，遇到一个人和我说他的程序里有几千个表。我想这个系统很大了，我要好好和他切磋一番。
结果那人说了半天，好像就是做了一个他们厂的员工档案的整理，我就不明白为什么要那么多表了。
他很淡定地说，一个员工一个信息表，我厂几千个人，所以要几千张表。

[圣殿骑士18]

引用 9 楼 贵阳老马马善福专业维修游泳池堵漏防水工程 的回复:

开发完代码量在5W-6W行左右.大概要有500个项目吧 这都是什么意思 很久以前，遇到一个人和我说他的程序里有几千个表。我想这个系统很大了，我要好好和他切磋一番。 结果那人说了半天，好像就是做了一个他们厂的员工档案的整理，我就不明白为什么要那么多表了。 他很淡定地说，一个员工一个信息表，我厂几千个人，所以要几千张表。

他可能指五六百个模块把