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

06-06-06 banq
本文总结了软件复用的不同层次:设计复用、组件架构复用以及业务模型复用,复用技术 的不断发展正是由于适应变化需求的要求不断提高导致!

http://www.jdon.com/artichect/reuse.html

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

借这个话题,我想和各位探讨几个问题:

1、构件复用&对象复用,前者面向功能,后者面向对象,这两者的使用场景是什么样的?个人初步认为:前者适用于宏观实现,而后者适用微观实现;前者主要用来“整合”,后者主要用来“实现”;

2、面向功能方法&面向对象方法之间的联系是什么?

3、如果面向功能的方法被用在微观实现上面,后果是什么?

注:

“宏观”:指模块级别(之上,包括模块、子系统、系统);

“微观”:指模块内部

背景:

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

zjsun
2006-06-07 16:29
这段时间一直在思考这样的问题:面向构件、面向服务?是否我们正在走退路,回到原先的面向过程思考方式,心里一直在担忧,我们是否被引向偏道?

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

大愚弱智
2006-06-07 18:33
不晓得您说什么了,本来想过来看看有什么好看的东西--我每星期都至少上一次这个网站,而且一次比一次失望:

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的宣传也不合理。而现在要挽回失掉的信心也是不可能了,打个比方,被骗了一次后,难道还想再次尝试一下是否这次还是被骗呢?

banq
2006-06-08 08:33
大愚弱智 需要对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可以很好地帮助我完成软件复用,所以将我的体会写出来,算是理论结合实际吧。

banq
2006-06-08 08:51
zjsun几个观点比较有意思,我说明一下我的想法:

>1.构件复用&对象复用

这个我在文中提出了,最早是面向功能-->对象class复用--->现在的组件复用。这两者区别我认为是架构和细节的区别,组件复用是宏观架构级别的复用,比如Struts+JF+Hibernate可以复用在多个项目中,Struts+JF+Hibernate作为技术组件(组件分业务组件和技术组件)被复用了;而对象复用是我们实现业务组件复用使用的技术,其实技术组件之所以能够复用,也是依赖其框架对象复用和解耦。

>面向功能方法&面向对象方法之间的联系是什么?

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

>如果面向功能的方法被用在微观实现上面,后果是什么?

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

http://www.jdon.com/artichect/coupling.htm

banq
2006-06-08 09:05
>面向构件、面向服务?是否我们正在走退路,回到原先的面向过程思考方式,心里一直在担忧,我们是否被引向偏道?

其实面向组件也就是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中间缺少了一个重要衔接环节,业务模型的复用,如果没有这个环节,确实会让人产生退回到原先的面向过程思考方式。

猜你喜欢