分享
 
 
 

范式的二维平面

王朝other·作者佚名  2006-01-08
窄屏简体版  字體: |||超大  

范式的二维平面

泛式( paradigm)就是编程的一种思维模式,比如面向过程,基于对象,面向对象,泛型,生成型(generative programming)。

面向对象( OO)和泛型(Generic)是目前程序设计方法中最受关注的两颗银弹,不过Frederick Phillips Brooks早就告诉过我们,No Silver!【注1】想要对付软件设计中具体而又频繁,狰狞而又可恶的人狼,那还是需要大量人的经验以及目前计算机所不具有的智慧。不过面向对象和泛型虽然还不足于堪当万灵银弹,但是它们仍然带给我们很多新的理念,新的解决软件人狼的办法。在实际的软件项目中,它们也已经成功的证明了自己。

注 1:其实什么问题又有绝对完美的解决办法呢?这个道理谁都明白,但能够像《人月神话》那样畅销已经快30年,还在继续畅销,能够像Brooks那样将问题讲的让人信服,妙语如珠,畅快淋漓,达到技术之巧与人文之美的几近完美结合,就不是那么容易的了。不过我一直认为翻译是很难的,语言之间的习惯,表达方式相差太大,虽然中文版翻译的非常好(至少我现在是望尘莫及)了,但我还是觉得英文的味道是不好翻译的,建议可以同时买一本英文影印版一起看,更能领略英语的文字之美。

说到面向对象,现在已经不再是新的概念了,虽然很多人言必说面向对象,但是真正知道并会灵活运用封装,继承,多态的实在太少。

面向对象是一个纵向垂直的概念,也就是采用平面几何中的 Y轴方向对软件元素的一种划分。它将要解决的问题域空间中的问题映射成一个个对象(object),然后将各种各样的对象进行归类,抽象出各种类型(class or type)以及类型之间的各种关系,最一般的关系就是继承,比较高级的就要用到各种设计模式(design pattern)来进一步刻划对象之间和类型之间的关系,增加“额外间接层(extra level of indirection)”,封装变化,分离界面与实现,从而采用的更灵活,更容易维护的设计。

虽然继承是我们接触面向对象最先知道的东西,但是却有一个很简明的判断标准:如果一个面向对象的软件用到了大量和很深的继承关系,那几乎毫无疑问是一个失败的设计,继承主要是用来尽可能的消除程序中的 if-else、switch,实现多态,仅仅为了复用代码采用继承那是非常不明智的行为,它只是把更多的麻烦留给不远的未来。要尽可能的采用组合而不是继承(C++中的保护继承和私有继承可以说是一种组合,而不能叫继承)。要用继承,必须要考虑到Liskov原则,很简单的来说,用到父类型的地方,子类型能畅通无阻的使用,也即对于父类型的所有界面(interface)【注2】,子类型都实现了。

注 2:也有翻译为接口的,不过我更喜欢界面。Interface也有人称其为Protocol(协议)的,所谓协议,也即提供的一组服务,在计算机网络中用到的最多,在面向对象中就被实现为类型的成员函数(或者叫方法)。

所谓面向对象,封装,继承,多态,要将其理解,并不太难,我介绍一本书,《 Thinking in Java》,目前最新是第三版。而且它也是学习Java的一本好书,可以用一个星期(7天)的时间好好看一看,基本的Java语言知识和面向对象的基本概念就一定会谙熟于心。【注3】

注 3:在去年(2002年)暑假的时候,我当时为了应聘一个兼职,用不到两天的时间(大概总共12个小时左右)在电脑上将《Thinking in Java》英文第二版看了一大半,并将所有的程序调试通过,感觉很容易上手。只是可惜由于公司的原因,兼职没有去成。当时我的计算机基础不怎么样,自学计算机也还不到一年,学了大概4个月的C++和C(我是学C++的过程中学会C的),而且本人也不怎么聪明,所以我认为你也一定可以7天看完3遍。这本书的英文很浅显,基本上没有什么难句,说理很清晰明白,可惜没有看到什么英文语言之美,这方面感觉不如《Effective C++》和《More Effective C++》,更不用提《The Mythical Man-Month》了。但作为一本Java语言入门教科书那是非常好了。

面向对象的运用与研究目前基本上已经达到了它所能到达的极限,当红明星 Java与C#只支持面向对象一种设计范式(paradigm)【注4】就成功的证明了面向对象的无穷威力,感觉现在在IT媒体就像始皇帝的江山一统【注5】,即使对面向对象来说并不习惯的表达方式,也已经被许多天才横溢的程序员用面向对象实现了。但是削足适履让人并不舒服。比如对程序中“横切关注点(crosscutting concern)”的实现用面向对象来设计就是非常别扭的,一种新的设计范式面向方面(Aspect Oriented)应运而生,并在AspectJ中得到实现。【注6】

注 4:你一定会说:“Stop,你遗漏了一点,Java还有Generic Java,它还支持泛型编程。”但请注意两点:

A. Generic Java并不是由官方支持的,至少目前它还没有能够溶入正统的Java血液之中。

B. Generic Java的泛型实现采用的是擦拭法(Erasure),也就是由编译器将泛型代码改头换面为面向对象代码,最后在编译为.class文件。可以参考《程序员》杂志2002.8-2002.9期,侯捷先生的《Java泛型技术之发展》。

注 5:“夷平六国是谁?哪个统一称霸?谁人战绩高过孤家?高高在上,诸君看吧,朕之江山美好如画。登高踏步,指天笑骂,秦是始,人在此,夺了万世潇洒!” ——《秦汉建筑》。

注 6:请参考《程序员》2002.11期的AOP专栏。

AOP是一个比较新的设计泛式,我也只看了几篇文章,不敢胡乱发表意见,有兴趣的读者可以到 http://aosd.net 去领略一次异境之旅。

言归正传,面向对象编程语言对类型的语言支持非常丰富,有 encapsulation、class、interface、inheritance、polymorphism、aggregate、RTTI。现实生活中问题域中的各种概念在解域空间中有了很好的映射,所以具体用程序语言来实现就比较轻松了。

可惜完美就像天堂一样,可以想象,但不能达到。我们的空间也不是只有一维,有许多问题用面向对象的纵向垂直 Y轴是独木难成林,即使实现了也是一种违反常识的蹩脚方法。比如ADT(Abstrct Data Type)的实现。具体比如栈(Stack),它表现的是体现一组功能(先进后出,弹出,压入)的集合。它的所有具现物(对象)并不需要有一个共同的基类(base class),具现物可以彼此至死不相往来,但在面向对象中实现却必须有一个共同的基类,然后每个具现物的类型都从这个基类继承,有多少种不同具现物,就有多少个类。下面一段简短的代码表现的更清晰:

class Stack

{

void push();

void pop();

Stack top();

//……

};

class IntStack : public Stack

{

……

};

class PlateStack : public Stack

{

……

};

//许多不同类型的Stack类。

不过在 Java中几乎所有类都是从Object class继承,它单独实现了一个Stack类,可以将各种类型的对象压入Stack,取出的时候再由Object向下转型为具体类。

示例代码:

//Java代码

Stack s = new Stack();

s.push(“string”);

String str = (String)s.top();

这是以损失效率和类型安全为代价的。

总之,这两种解决方法都很扭曲!如果能够像这样用 stack<int>,stack<string>,……就好了,效率的熊掌、类型安全的鱼都得到了。而面向对象缺少的就是这样一种对软件组件的横向切分。它们有同样的ADT,但除此之外,可以没有任何联系,Y轴与X轴是正交的,所以Y轴不可能实现X轴的功能。

这个时候就应该轮到姗姗来迟的泛型 X轴粉墨登场了。C++中的STL就是这一轴的杰出成就。请记住,模板(template)并不是泛型,只是C++中的泛型采用了模板来实现。STL中用模板实现了各种常用算法和数据结构,并保证了效率的高效,比你自己实现要安全的多和快的多(一般来说是这样的),现在的C++程序员比以前要幸福的多,再也不用一遍又一遍的重复造轮子了。

但是在泛型设计的洪荒年代(这个年代可以说到现在还没有结束),用泛型技术实现的代码异常的难于调试。软件总会是有错误的,程序员所能做的就是尽快的找到 bug,并修正它。由于泛型技术出现的时间并不太长,而且受到的礼遇是远远不如面向对象,所以它到现在仍然不是很成熟。语言本身缺少很多对它的支持。

面向对象中的一些概念, Interface(C++中用ABC,Abstract Base Class来模拟),Instantiation,Implementation(extends in Java,inheritance in C++)。在语言级(language level)都得到了很好的支持,所谓语言级支持就是:比如你实现的函数参数类型不匹配的话,例如对于签名(signature)为void fun(ClassA a);的函数,你这样调用它

ClassB b;

fun(b);

编译器会给你很清晰的报错“ conversion from `ClassB' to type `ClassA' requested, type is mismatched.”

但是对应于面向对象中的这些概念,泛型也有相应的一些概念,下面我用泛型中的几个学术术语,对应于 Interface的是Concept,在下面的例子中

template <typename T>

class Stack;

就像上例中的 fun函数引数(argument)必须符合类ClassA的Interface一样,T必须符合一个Concept——AssignableConcept。也就是说模板类型参数T必须是可以赋值(assignable)而不变的对象类型,你也许会奇怪,还有不可赋值的东西,有的,具有拥有权(owership)转移的智能指针(smart pointer)就不行,恰好标准中唯一的一个智能指针auto_ptr就是这样。Concept可以说是T的种类(category),T必须满足Concept的要求。

对应于 Instantiation的泛型术语叫Model,Instantiation是Interface的具体类的具现体,也就是一个个具体对象(object),Model就是Concept的具现体。比如说int,double,string类型都是LessThanComparableConcept的具现体,就像100,200是类型int的具现体,3.4,2.6是类型double的具现体,请再好好体会一下。

对应于 Implementation的是Finement(细化,精化)【注7】,比如对于ConceptIterator, ForwardIterator和RandomIterator都是它的Model,但RandomIterator本身也是ForwardIterator,反过来则不行,所以说RandomIterator是ForwardIterator的一个Finement。

注 7:我总觉得这个对应不太恰当,但想不出一个很好的对应名字。其实Finement相当于一个深类层次(deep class hierarchy),靠近底层的具体类是上层类的细化。比如类层次: |---------------------| |-----------A--------| | | |---------------------| | \|/ |---------------------| |-----------B--------| | |

|---------------------| | \|/ |---------------------| |-----------C--------| | |

|---------------------|

class C就是class B的细化。一直比较遗憾很想看看Matthew H. Austern的名著《泛型编程与 STL》,但是以前是买不到,现在是手中无米,只有以后上班再说了,听说里面讲到了很多泛型的理论,不知道里面对Finement有没有什么恰当的对应。

不过可惜的是,在编译器的实现中,对于这些概念 Concept,Model,Finement并没有相应的检查机制,即缺乏语言本身的支持。所以这些概念就需要程序员本身来维护,如果在程序中由于这些概念本身的错误而导致程序出错的话,编译器会莫名其妙的报错:某某函数没有实现,某某标识符(identifier)不认识,……为找到真正的错误,有时候甚至会耗尽你的精力。比如GCC STL的算法实现中对于stable_sort函数的实现:

template<typename _RandomAccessIter>

inline void

stable_sort(_RandomAccessIter __first, _RandomAccessIter __last)

{…}

stable_sort函数需要两个_RandomAccessIter(随机访问迭代器,比如典型的数组指针),所以它不能用来对list进行排序。List是基于结点(node_based)的容器(container),也就是说是由一个一个的结点(node)串起来的,它的迭代器概念是_BidirectionalIter(双向迭代器)。所以std::stable_sort()函数不能对list进行排序,但这样用:

std::list<int> li;

…//对li充实内容

//试图对li排序

std::stable_sort( li.begin(), li.end() );//错误,应该用li.sort();

编译器应该对 Concept mismatch报错,老一点的编译器都不能找到这个原因。在著名的B面向对象st库中 Jeremy Siek 实现了一个 ConceptCheck库http://www.b面向对象st.org/libs/concept_check/concept_check.htm,专门用于此类错误的检查,GCC STL就直接采用了这个库,VC7.1中也自己实现了类似的库,现在的报错就比较明显了【注8】。但是这类concept检查就应该由语言本身来检查,而不应该借助于外力(专门的库和大量丑陋的宏),所以说泛型的设计范式(paradigm)还不成熟。

注 8:需要寻求STL相关的错误准确定位,可以参考Leor Zolman's STLFilt 错误消息过滤器 http://www.bdsoft.com/t面向对象ls/stlfilt.html

但是如果因为它不成熟就不去用它,那它永远也不会成熟,面向对象的设计泛式不也是这样一步一步走向成熟成功的吗?况且泛型作为对软件元素水平横向 X轴的刻划,它的潜在威力就应该和垂直纵向Y轴一样大,所以即使现在如日中天的Java,C#也都准备在下一版本加入对泛型的支持。毕竟两只脚走路还是比一只脚要舒服的多:)

现在 X轴,Y轴都有了,已经构成了一个完整的欧几里得(Euclid)平面。那是不是还应该有Z轴,甚至除了三维之外,还有n维,欧几里得平面之外的非欧几何?请原谅我的愚钝和无知,这些问题与思索就留给勇敢聪明而又富有想象力的读者你了。

后记:

CSDN上有一篇文章《类型——OOP和GP的核心概念》将面向对象和泛型讲的很清楚,有兴趣的读者可以看看 http://www.csdn.net/Develop/Read_Article.asp?Id=14824 。

最开始我想用的划分是 Matrix(矩阵,母体),它只需要行(row)和列(column)就可以表示所有。但我不敢说泛型和面向对象就是软件Matrix中的行和列,要找到这两颗明珠,实在远非我力之所逮!在下一篇文章我想说说C++中的三位一体(trinity)——关于copy ctor,assignment,destructor。

吴桐写于 2003.5.29

最近修改 2003.6.16

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有