快速适应需求变化的软件复用

banq分析的非常精彩。最近也一直在关注有关复用方面的资料，今天让我澄清了以前一直模糊的概念。

借这个话题，我想和各位探讨几个问题：
1、构件复用＆对象复用，前者面向功能，后者面向对象，这两者的使用场景是什么样的？个人初步认为：前者适用于宏观实现，而后者适用微观实现；前者主要用来“整合”，后者主要用来“实现”；
2、面向功能方法＆面向对象方法之间的联系是什么？
3、如果面向功能的方法被用在微观实现上面，后果是什么？

注：
“宏观”：指模块级别（之上，包括模块、子系统、系统）；
“微观”：指模块内部

背景：
最近由于看到一片报道 普元CTO与IBM CTO的采访 所引发的思考＆疑问

这段时间一直在思考这样的问题：面向构件、面向服务？是否我们正在走退路，回到原先的面向过程思考方式，心里一直在担忧，我们是否被引向偏道？

希望和各位共同探讨这个问题！

不晓得您说什么了，本来想过来看看有什么好看的东西－－我每星期都至少上一次这个网站，而且一次比一次失望：
1.这个网站广告特别烦人，上这个网站感觉简直就是被人强奸。
2.整天反反复复的鼓吹JF框架如何如何好，将JF和ruby、spring进行比较，然后得出所谓的结论。

JF我只大概看了一下，实际的好处可能并不如这个论坛鼓吹的那么强大或者易用，原因：
1.没有学过Struts，您说谁敢上你的JF么？绝对不敢，谁上谁就死。
2.没有学过EJB，您说谁敢上你的JF么？假如一个人懂得了如何配置声明性的事务，那他早就理解EJB了，懂EJB的人一般都不是什么菜鸟，既然不是菜鸟，就没有必要使用JF了。

J2EE应用开发应该是组合了很多的非常复杂的技术，大型应用开发也绝对不是什么论坛软件。假如不对一个框架熟悉，那是绝对搞不来了，而且我敢保证斑竹也未必敢拿JF来做大型项目。

假如要做小型项目，用ASP不就可以了吗？如果觉得ASP不熟悉，JSP总该可以吧？

BTW：JF发展得如何我是没有心思关注了，POJO也罢，继承自XXXModel也罢，总而言之，我第一次下载时就大失所望。我认为：斑竹是过于心急了，文档都没有做好就发布，而且关于POJO的宣传也不合理。而现在要挽回失掉的信心也是不可能了，打个比方，被骗了一次后，难道还想再次尝试一下是否这次还是被骗呢？

大愚弱智 需要对JF多些谅解，JF不是商业产品，所以各方面比较唐突，一开始推出时是作为EJB的Proxy，这时JF1.0相当于最近TSS网站反复推荐的Crispy（http://www.theserverside.com/news/thread.tss?thread_id=40699）

JF1.2版本开始支持POJO的Service，1.4开始无需继承XXXMODEL，可以使用ModelIF接口了，这些都是发展变化，不能用僵化不变的观点来看待技术。是不是。

你觉得被骗，还是你期初希望很大，JF1.4也许满足你当初一部分期望，该贴不是谈JF，而是主要谈软件复用，JF可以很好地帮助我完成软件复用，所以将我的体会写出来，算是理论结合实际吧。

zjsun几个观点比较有意思，我说明一下我的想法：
>1.构件复用＆对象复用
这个我在文中提出了，最早是面向功能-->对象class复用--->现在的组件复用。这两者区别我认为是架构和细节的区别，组件复用是宏观架构级别的复用，比如Struts+JF+Hibernate可以复用在多个项目中，Struts+JF+Hibernate作为技术组件（组件分业务组件和技术组件）被复用了；而对象复用是我们实现业务组件复用使用的技术，其实技术组件之所以能够复用，也是依赖其框架对象复用和解耦。

>面向功能方法＆面向对象方法之间的联系是什么？
面向功能方法是过程的，面向对象的方法是动态的，面向功能方法是将功能实现按顺序一五一十的写下来；而面向对象的方法则因为对象粒度细化，会将功能拆得面目全非，单看代码无法了解功能了，通过运行时动态组装。

>如果面向功能的方法被用在微观实现上面，后果是什么？
很显然，这是我们一般程序员最容易范得错误，这些程序员脑海里只有功能展现，没有设计考量，因此就会用面向对象的方法这个载体来实现一系列功能，不进行细分‘解耦，所以要改变这一思考习惯，在其编程生涯和思考习惯中必须切入解耦这个课程，如何培养自己解耦的朴素思维，无疑从设计模式开始训练，我在软件最大追求中写得比较清楚：
http://www.jdon.com/artichect/coupling.htm

>面向构件、面向服务？是否我们正在走退路，回到原先的面向过程思考方式，心里一直在担忧，我们是否被引向偏道？

其实面向组件也就是CBD是上个世纪90年代以EJB为代表的思潮，CBD必须是基于OO概念上，现在说白了，必须基于框架概念上，没有框架支持的CBD如无本之木。

在CBD和SOA之间其实还有一个中间状态，就是我在本文提出的第三个层次复用：业务复用；或者称业务Model复用。

通过四色图以及各个大师解析，大家都承认在业务分析领域有一些基本的原型或分析模式，而且这些原型是跨领域跨组织的（这也是SOA的基础），所以现在MDA和DSM正是在这个方向努力，正如我在文中举例一样，我将JiveJdon3的Message四色模型结构拷贝到一个新的目录下，然后再进行裁剪就成为一个办公新闻消息系统，我这个拷贝其实很原始，MDA工具就是一种自动拷贝机。

所以，以我的观点看，SOA提出就象当初的EJB提出时，太超前了，技术美奂美仑主义总是将超前的概念提出，而不考虑大众接受程度。

所以，MDA和DSM等概念才被很多人接受，MDA/DSM无需改变现有的软件分销模式（通过一项技术改变传统软件分销模式谈何容易，历史上都是几十年，这也反映技术狂想主义的梦想）。又因为DSM有微软的盖茨参与，估计DSL/DSM这条路线比较实际。

所以，个人认为MDA/DSL/DSM才是CBD的延续，见"模型驱动软件开发实战步骤"
http://www.jdon.com/mda/mda.html
就是SOA成了气候，也只是技术上的相对成熟，是原来概念和实际的妥协。

从CBD到SOA中间缺少了一个重要衔接环节，业务模型的复用，如果没有这个环节，确实会让人产生退回到原先的面向过程思考方式。