【转】深入浅出OOD(一)

深入浅出OOD(一)
撰文/透明
有物昆成,先天地生。萧呵!谬呵!独立而不改,可以为天地母。吾未知其名,字之曰
道。吾强为之名曰大,大曰逝,逝曰远,远曰反。道大,天大,地大,王亦大。
——《道德经》,第二十五章
软件不软
从 60 年代的软件危机,到今天传统软件工程方法处处碰壁的处境,都说明一个问题:
软件不软(Software is Hard)[Martin, 95]。说实话,软件是一块硬骨头,真正开发过软
件的人都会有此感觉。一个应用总是包含无数错综复杂的细节,而软件开发者则要把所
有这些细节都组织起来,使之形成一个可以正常运转的程序,这实在不是一件简单的事。
为什么会这样?举个例子来说:用户可以很轻松地说“我要一个字处理软件”,他觉得
“字处理软件”这样一个概念是再清楚不过的了,根本不需要更多的描述;而真正开发
一个字处理软件却是一件困难无比的事情——我曾经亲眼看到开发字处理软件的人们
是怎样受尽折磨的。为什么表述一个概念很容易,而实现一个概念很困难?因为人们太
擅长抽象、太擅长剥离细节问题了。
软件不软,症结就在这里:用户很容易抽象地表达自己的需求,而这种抽象却很难转化
为程序代码。软件不软,因为很简单的设想也需要大量的时间去实现;软件不软,因为
满足用户的需求和期望实在太困难;软件不软,因为软件太容易让用户产生幻想。
而另一方面,计算机硬件技术却在飞速发展。从几十年前神秘的庞然大物,到现在随身
携带的移动芯片;从每秒数千次运算到每秒上百亿次运算。当软件开发者们还在寻找能
让软件开发生产力提高一个数量级的“银弹”[Brooks, 95]时,硬件开发的生产力早已提
升了百倍千倍。这是为什么?
硬件工程师们能够如此高效,是因为他们都很懒惰。他们永远恪守“不要去重新发明轮
子”的古训,他们尽量利用别人的成果。你看到有硬件工程师自己设计拨码开关的吗?
你看到有硬件工程师自己设计低通滤波电路的吗?你看到有硬件工程师自己设计计时
器的吗?他们有一套非常好的封装技术,他们可以把电路封装在一个接插件里面,只露
出接口。别人要用的时候,只管按照接口去用,完全不必操心接插件内部的实现。
而软件工程师们呢?在 STL成为C++标准之前(甚至之后),每个C++程序员都写过自
己的排序算法和链表,并认为自己比别人写得更好⋯⋯真是令人伤心。
OOD 可以让软件稍微“软”一点
软件不软,不过OOD可以帮助它稍微“软”一点。OOD为我们提供了封装某一层面上
的功能和复杂性的工具。使用OOD,我们可以创建黑箱软件模块,将一大堆复杂的东
西藏到一个简单的接口背后。然后,软件工程师们就可以使用标准的软件技术把这些黑
箱组合起来,形成他们想要的应用程序。
Grady Booch 把这些黑箱称为类属(class category),现在我们则通常把它们称为“组件
(component)”。类属是由被称为类(class)的实体组成的,类与类之间通过关联
(relationship)结合在一起。一个类可以把大量的细节隐藏起来,只露出一个简单的接
口,这正好符合人们喜欢抽象的心理。所以,这是一个非常伟大的概念,因为它给我们
提供了封装和复用的基础,让我们可以从问题的角度来看问题,而不是从机器的角度来
看问题。
软件的复用最初是从函数库和类库开始的,这两种复用形式实际上都是白箱复用。到 90
年代,开始有人开发并出售真正的黑箱软件模块:框架(framework)和控件(control)。
框架和控件往往还受平台和语言的限制,现在软件技术的新潮流是用SOAP 作为传输介
质的Web Service,它可以使软件模块脱离平台和语言的束缚,实现更高程度的复用。
但是想一想,其实Web Service 也是面向对象,只不过是把类与类之间的关联用XML
来描述而已[Li, 02]。在过去的十多年里,面向对象技术对软件行业起到了极大的推动作
用。在可以预测的将来,它仍将是软件设计的主要技术——至少我看不到有什么技术可
以取代它的。
上面,我向读者介绍了一些背景知识,也稍微介绍了 OOD 的好处。下面,我将回答几
个常见的问题,希望能借这几个问题让读者看清OOD 的轮廓。
什么是 OOD?
面向对象设计(Object-Oriented Design,OOD)是一种软件设计方法,是一种工程化规
范。这是毫无疑问的。按照Bjarne Stroustrup 的说法,面向对象的编程范式(paradigm)
是[Stroustrup, 97]:
l 决定你要的类;
l 给每个类提供完整的一组操作;
l 明确地使用继承来表现共同点。
由这个定义,我们可以看出:OOD 就是“根据需求决定所需的类、类的操作以及类之
间关联的过程”。
OOD 的目标是管理程序内部各部分的相互依赖。为了达到这个目标,OOD要求将程序
分成块,每个块的规模应该小到可以管理的程度,然后分别将各个块隐藏在接口
(interface)的后面,让它们只通过接口相互交流。比如说,如果用OOD 的方法来设计
一个服务器-客户端(client-server)应用,那么服务器和客户端之间不应该有直接的依
赖,而是应该让服务器的接口和客户端的接口相互依赖。
这种依赖关系的转换使得系统的各部分具有了可复用性。还是拿上面那个例子来说,客
户端就不必依赖于特定的服务器,所以就可以复用到其他的环境下。如果要复用某一个
程序块,只要实现必须的接口就行了。
OOD 是一种解决软件问题的设计范式(paradigm),一种抽象的范式。使用OOD 这种
设计范式,我们可以用对象(object)来表现问题领域(problem domain)的实体,每个
对象都有相应的状态和行为。我们刚才说到:OOD 是一种抽象的范式。抽象可以分成
很多层次,从非常概括的到非常特殊的都有,而对象可能处于任何一个抽象层次上。另
外,彼此不同但又互有关联的对象可以共同构成抽象:只要这些对象之间有相似性,就
可以把它们当成同一类的对象来处理。
OOD 到底从哪儿来?
有很多人都认为:OOD是对结构化设计(Structured Design,SD)的扩展,其实这是不
对的。OOD 的软件设计观念和SD 完全不同。SD 注重的是数据结构和处理数据结构的
过程。而在OOD 中,过程和数据结构都被对象隐藏起来,两者几乎是互不相关的。不
过,追根溯源,OOD 和SD 有着非常深的渊源。
1967 年前后,OOD 和SD 的概念几乎同时诞生,它们分别以不同的方式来表现数据结
构和算法。当时,围绕着这两个概念,很多科学家写了大量的论文。其中,由Dijkstra
和Hoare 两人所写的一些论文讲到了“恰当的程序控制结构”这个话题,声称goto 语句
是有害的,应该用顺序、循环、分支这三种控制结构来构成整个程序流程。这些概念发
展构成了结构化程序设计方法;而由Ole-Johan Dahl 所写的另一些论文则主要讨论编程
语言中的单位划分,其中的一种程序单位就是类,它已经拥有了面向对象程序设计的主
要特征。
这两种概念立刻就分道扬镳了。在结构化这边的历史大家都很熟悉:NATO会议采纳了
Dijkstra 的思想,整个软件产业都同意goto 语句的确是有害的,结构化方法、瀑布模型
从70 年代开始大行其道。同时,无数的科学家和软件工程师也帮助结构化方法不断发
展完善,其中有很多今天足以使我们振聋发聩的名字,例如Constantine、Yourdon、
DeMarco 和Dijkstra。有很长一段时间,整个世界都相信:结构化方法就是拯救软件工
业的“银弹”。当然,时间最后证明了一切。
而此时,面向对象则在研究和教育领域缓慢发展。结构化程序设计几乎可以应用于任何
编程语言之上,而面向对象程序设计则需要语言的支持1,这也妨碍了面向对象技术的
发展。实际上,在60 年代后期,支持面向对象特性的语言只有Simula-67 这一种。到
70 年代,施乐帕洛阿尔托研究中心(PARC)的Alan Key 等人又发明了另一种基于面向
对象方法的语言,那就是大名鼎鼎的Smalltalk。但是,直到80 年代中期,Smalltalk 和
另外几种面向对象语言仍然只停留在实验室里。
到 90 年代,OOD突然就风靡了整个软件行业,这绝对是软件开发史上的一次革命。不
过,登高才能望远,新事物总是站在旧事物的基础之上的。70 年代和80 年代的设计方
法揭示出许多有价值的概念,谁都不能也不敢忽视它们,OOD 也一样。
OOD 和传统方法有什么区别?
还记得结构化设计方法吗?程序被划分成许多个模块,这些模块被组织成一个树型结
构。这棵树的根就是主模块,叶子就是工具模块和最低级的功能模块。同时,这棵树也
表示调用结构:每个模块都调用自己的直接下级模块,并被自己的直接上级模块调用。
那么,哪个模块负责收集应用程序最重要的那些策略?当然是最顶端的那些。在底下的
那些模块只管实现最小的细节,最顶端的模块关心规模最大的问题。所以,在这个体系
结构中越靠上,概念的抽象层次就越高,也越接近问题领域;体系结构中位置越低,概
念就越接近细节,与问题领域的关系就越少,而与解决方案领域的关系就越多。
但是,由于上方的模块需要调用下方的模块,所以这些上方的模块就依赖于下方的细节。
换句话说,与问题领域相关的抽象要依赖于与问题领域无关的细节!这也就是说,当实
现细节发生变化时,抽象也会受到影响。而且,如果我们想复用某一个抽象的话,就必
须把它依赖的细节都一起拖过去。
而在 OOD 中,我们希望倒转这种依赖关系:我们创建的抽象不依赖于任何细节,而细
节则高度依赖于上面的抽象。这种依赖关系的倒转正是OOD 和传统技术之间根本的差
异,也正是OOD 思想的精华所在。
OOD 能给我带来什么?
问这个问题的人,脑子里通常是在想“OOD 能解决所有的设计问题吗?”没有银弹。
1 我听见有人说“我可以用 C 语言实现面向对象”,不过我希望你不会说“我也喜欢这样做”。很明显,
如果没有语言特性的支持,面向对象方法将寸步难行。其实结构化设计也是一样,不过几乎所有的编
程语言都提供了对三种基本流程结构的支持,所以基本不会遇到这个问题。
OOD 也不是解决一切设计问题、避免软件危机、捍卫世界和平⋯⋯的银弹。OOD 只是
一种技术。但是,它是一种优秀的技术,它可以很好地解决目前的大多数软件设计问题
——当然,这要求设计者有足够的能力。
OOD 可能会让你头疼,因为要学会它、掌握它是很困难的;OOD甚至会让你失望,因
为它也并不成熟、并不完美。OOD 也会给你带来欣喜,它让你可以专注于设计,而不
必操心那些细枝末节;OOD 也会使你成为一个更好的设计师,它能提供给你很好的工
具,让你能开发出更坚固、更可维护、更可复用的软件。
C++是一种“真正的”面向对象编程语言吗?
最后这个问题和我们今天的主题关系不大,不过这是一个由来已久的问题,而且以后也
不一定会有合适的时机说明这个问题,所以今天一起回答了。
很多人都觉得 C++缺少“真正的”面向对象语言所必须的一些特性,例如垃圾收集
(garbage collection)、多分配(multiple-dispatch)之类的。但是,缺少这些特性并不影
响开发者们用C++实现面向对象的设计思路。
在我看来,任何语言,只要它直接支持面向对象设计的实现,那它就是“真正的”面向
对象语言。用这个标准来评价,C++是完全符合的:它直接支持继承、多态、封装和抽
象,而这些才是面向对象最重要的。而VB 和C 这样的语言不能直接支持这些(尽管可
以用特殊的技巧来实现),所以不是“真正的”面向对象语言。
参考书目
l [Brooks, 95] Frederick Brooks, The Mythical Man-Month, Addison-Wesley, 1995.
l [Li, 02] 李维,《Delphi 6/Kylix 2 SOAP/Web Service 程序设计篇》,机械工业出
版社,2002 年。
l [Martin, 95] Robert Martin, Designing Object-Oriented C++ Applications Using
the Booch Method, Prentice-Hall, 1995.
l [Stroustrup, 97] Bjarne Stroustrup, The C++ Programming Language (Special
Edition), Addison-Wesley, 1997.


Total views.

© 2013 - 2018. All rights reserved.

Powered by Hydejack v6.6.1