软件最大的追求是什么?

banq 05-12-19
              

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

松耦合一个反义词“紧耦合”,从我们学会玩编程这个玩具开始起,我们就面临两种选择:一种朴素的、无需训练的、近似自然的“紧耦合”路线;一种是经过科学培训的“松耦合”道路。

              

yuxie
2005-12-19 13:53

介个标题起的……
软件最大的追求就是卖给用户,拿到钱,发到奖金,回答完毕。

看到banq给的公式,突然想起Yin兄以前说过的,为什么关系数据库理论比OO理论更正统(当然原话8是这么说的)。banq的公式相信计算机系的学生都知道……它的最大特点就是啥都解决不了……呵呵。不过关系理论就不一样了,它在告诉你你的关系模型不是很好的同时,给了你完善的方案(或者说定理,范式定理,范式公式)来完善你的模型。虽然实际开发我们往往需要降范式话,但是我们同时也可以知道降范式化带来的优点和缺点,而且这些都是可计算的。

与上面所说相反的,所谓OO的“松耦合”能带来多大的意义,我们却不可能很清楚的了解到。几年前号称面向组件编程,耦合度确实比面向对象编程还低,貌似就要大量出现软件组装工厂的局面……但是现在看呢,意义是在有限的紧。原因很简单,耦合度降低的同时:
1、开发成本不可避免增高……别说什么灵活的可维护性、可适应性,我们没有权利替用户想需求,用户只要一个轮子,你给他造出一个汽车,用户认为这就是浪费。
2、最大的问题,“构件”(请原谅我用这个词)的粒度应该多大?……

不写了,上班先,

banq
2005-12-19 14:32

>“构件”(请原谅我用这个词)的粒度应该多大?……
粒度是不能量化到用数字来表达的,这不是方向,它外界标准是:无论你的组件粒度粗细,但是该构件自身必须是可替换的。

无论是面向对象或面向构件/面向组件/基于组件,衡量他们先进与否的一个重要指标是:其任一对象或构件/组件是否可替换?只有实现完全可替换,才能实现高度可扩展性和维护性。

因为这个尺度,迫使我们必须使组件粒度细化,就象我们必须将一个墙体再次细化成砖块一样,粒度越是细化,可替换性更强,细化到沙粒,则毫无疑问是最好,但是有时没有必要,只要细化到这个构件可以被替代即可。

这又是一种依据具体问题具体分析的典型思维方式,而不是有一个放之四海皆准的数学公式。


banq
2005-12-19 14:50

>软件最大的追求就是卖给用户,拿到钱,发到奖金,
完全同意,但是如何做到呢?就是以最低成本提供最好质量的商品。考虑到你这个思考方向,我特地修改文章,在最后加了一句:

所以,对于编程这个玩具,不在于你是否会玩,而在于你怎么玩?玩的水平。如果不明白这个道理,中国软件的萧条永远不会结束。

只有快速地、低成本地、玩出高水平的的软件,才能卖给一个个用户,而不是只能永远卖给第一个用户;才能持续拿到钱,而不是一锤子买卖,拿到钱,以后就没有了,最后,似乎有这个印象:搞软件的人象“披着高科技羊皮搞诈骗”一样。

yuxie
2005-12-19 14:58

> 粒度越是细化,可替换性更强,细化到沙粒,则毫无疑问是最好,但是有时没有必要,只要细化到这个构件可以被替代即可

这句话有很大的问题。什么样的东西是可以被替代的?一个类webservice可以被替代,一个类可以被替代,一个函数(方法)可以被替代,一个语句可以被替代,一个变量当然也可以被替代……
虽然粒度越是细化,可替换性更强,但是从复用的角度看,显然不是越细越好。
我们看一下程序演化的历史:
打孔纸带编程:好像不大好复用一个纸带,这个偶不了解
过程式的编程:用goto跳到程序某一个地方,可以实现语句级别的复用,事实证明这种方式是极其糟糕的;
模块式编程:复用提高到方法级别……到这个时候,软件才开始进入大规模的应用;
面向对象的编程:类级别的复用。很8错的一种东西。
面向构件的编程:构件级别的复用,比类更高级的复用。号称可以让编程像工厂组装那样,但是从来没有出现过这样的工厂和所谓的构件市场。
面向服务的编程:……好像有点意思,了解不深,不乱发表评论。

综上可以得到两点结论:
1、复用的粒度跟生产率相关,但具体关系不明,并不是说复用级别越高生产率就越高。
2、sorry,突然想不起来了



6Go 1 2 3 4 ... 6 下一页