无辜的RAD（RAD是让你去创造和使用可复用的组件，不是让程序员“变白痴”）good

Posted 2020-08-28 朝闻道

无辜的RAD

2005-3-21

说实话，RAD很无辜。从出生的那天其就被骂，天天被指着鼻子说“不就是拖个控件嘛”，就好像当年说学电脑“不就是插个鼠标嘛”。也怪程序员大都天性犯贱，就爱一遍又一便的写基础代码库，什么字符串类啦、智能指针啦、动态集合啦，能写的都自己写一遍，要是用现成的啊，你都不好意思跟人说。天天重复重复再重复地做着重复重复再重复的事情，还以为自己做着多么伟大的事情，直到哪天一位民工叔叔拍拍他的肩膀说道：“省省吧，我们早就不用砖头盖大楼哩！”

复用性是软件开发的核心之一，从函数到类，到组件，到中间件，复用的规模逐渐加大。RAD的核心就是复用。至于控件，其实就是可视组件。

函数是最早，也是最简单的复用单元，代表语言C。你一定认为我重复这个old的基本概念是在浪费带宽，那么为数不少的程序员仍然在写超过1000行的单个函数，是不是该把他们拖出去斩了？

类随着面向对象概念而出现，作为包含一组操作函数和数据的复用单元，代表语言C++，经过当年MFC若干年的努力，终于广为接受。而随着现在Unix的复兴，反对派也有了一定声强。原因很简单，连设计可复用的函数都有很多人做不到，更别说类了。很多人只是把所有要用的函数堆到一个类里，结果还不如不用。

组件随RAD概念而出现，作为包含共同完成一项功能的一组类的复用单元。代表语言Delphi，到不是说Delphi提供了多少组件，而是它提供了一种方便的实现组件的方式，开发人员利用这种方式创造的大量的良好可复用组件。Borland的组件化设计同样造就了JavaBean，也延伸到dotNet。如果有人还不明白，简单的说就是：RAD是让你去创造和使用可复用的组件，不是让程序员“变白痴”。

中间件就是半成品，是比组件更大的复用单元，而且不再强调用什么方式实现，不强调使用什么样的接口。在这种规模下，一般开发工作与设计工作已经分离由不同的专职人员完成。

比起函数和类，组件和中间件都更为抽象，不拘泥于某种实现形式，而且由于问题规模更大，往往要伴随相关文档来构成一个完整的整体。这些方式没有哪种是最好的，使用哪种方式完全取决于需求和问题规模。

不少RAD反对者认为使用组件就远离了底层，就好像把厕所改叫盥洗室就有人找不到大号，无非都是些函数和类，和底层不底层有什么关系。其实只不过是VB不支持指针，所以VB的组件大都只提供高级接口，就被以偏概全。还有反对者认为用封装好的东西就不能了解底层，非要自己写一遍才行，就好比要重新证明力学三定律。如果是为了专研学习确实精神可嘉，如果是做工作就是神经。枉费了文档和源码还都理解不了底层，还要在这点问题上浪费生命。于是，有人用for(int *p = src, *q = dst, *e = src + count; p < e; *q = *p, p++, q++);重写memcpy，还自诩比系统的快，我@#$%^&*。人家XBox的广告说得好，“人生苦短，及时行乐”，何不把时间花在赚钱的事情上。

当然，C的领地内是不提组件的，因为广为接受的组件的概念是基于类的。正如OO传道者说的，OO只是一种概念，如果说能够做OO设计的语言都是面对对象的语言的话，C也是面对对象的，Ada也是。同样，组件也是一种概念，它只是一个独立可复用的模块，由于C的纯粹性，在C里实现这样一个东西比在C++里容易。C++上很难发展组件的原因是，可复用的组件必须有易于模块对接的接口，而C++偏偏没有统一的基础库，就连个字符串都每个类库一套实现。组件又是相对高层的结构，只得依附某一代码框架，也就只能在同一框架下复用，也就大大限制了组件的发展。也由此催生了COM，作为和语言框架无关的接口。可惜COM认的老大是VB，C++要是想和COM打个照面啊，那个难啊。

总的来说，很多人还处在旧PC时代，那时候一个人就能写出个WPS，一个人就能写出个CCDOS，而现在这些只能是唐吉诃德的美梦。手机软件的兴起让很多人重温了一下旧梦，不过最终还是要回到现实。

 

http://blog.csdn.net/nightmare/article/details/353337