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

08-07-10 bloodrate

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

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

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

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

banq

2008-07-10 17:53

很理解你的重用心情。

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

bloodrate

2008-07-20 21:22

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

freebox

2008-07-21 01:44

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