求问banq大人,求组件开发思路

故事背景:比如一个系统让我实现一个功能,我总是想能不能多花点时间做个通用得jar包,能把这个功能用到其他系统中,而不是仅仅完成这个项目得这个功能而已。

主要困境:缺乏思路,不知道怎么划分类,怎么划分职责

阐述:如果我就完成当前功能,那我把实现全写在一两个类里,很简单的,一做成组件,立刻从1,2个类变成1,2十个类。

并非过度设计:我这样做并非过度设计,举个例子:比如struts,从反向思维讲,我们项目就用到struts包里的几个类而已,但是struts包里有几十个类。我想把这个思维反过来,比如事先没有struts,我就用了那几个需要的类,随着使用,我返现这个东西有希望能运用到别的项目,同时想把其组件化,我怎么才能从那几个类设计出struts包里得几十个类。(以上为我追随开源组件得设计思维)

很理解你的重用心情。

根据我个人经验,重用是设计重构后的自然结果,就开花后必然结果一样自然,因此重用是良好设计的一个结果,你的目标不能直接对准重用,应该瞄准设计重构,对现有代码按照变和不变等模式原则进行分类组合,形成良好的松耦合结构,到那时你发现,重用变成水到渠成的产物。

现在我逐渐在培养组件意识,比如项目中用到的东西,有意地提成专门的包不和具体业务代码混在一起等等,不过还是很难写出什么有实际价值的东西

业务上的东西很难做到通用,就算同一个行业,比如销售电脑,对待打折等问题也有不同的策略。
有些业务比较稳定的东西是可以通用的,比如股票走势(不包括分析),这些不管谁来做,应用什么技术,中间采取什么手段,结果应该是一样的,用的人也不可能对结果改动,除非他想要一个不实的结果(不实还有什么意义?)
假设一个派送礼品的系统,要求打出礼品单并邮件,送货员照单取货并送出,但是碰上第二天是雨天可不打单。可以花高价买天气预报设备并做一个天气预报系统来支持,也可以选用廉价的web服务来支持,找到某个.net服务,这个服务在派送礼品的系统里应该处在dao的级别吧。开发的天气预报服务就达到了组件化重用的目的。我想除军事等部门对这组件不信任外,应付一般的民众性应用应该没问题。
但是我开发了一个计费系统组件,按照我们的规则来计费,没错也可以发布出去,但除了自己的分公司拥有同样的业务规则,没人用这东西,人家的规则和我们的不一样,也就是这些不一样才构成了各个企业软件的核心。