《OOD启思录》—第1章1.2节Frederick Brooks观点:非根本复杂性与根本复杂性

1.2 Frederick Brooks观点:非根本复杂性与根本复杂性
OOD启思录
Frederick Brooks在1987年10月份的IEEE Computer上发表了一篇有趣的文章,标题是Conceptual Essence of Software Engineering or There Is No Silver Bullet [参考文献1]。Frederick Brooks是The Mythical Man-Month [参考文献2]的作者。The Mythical Man-Month记录了他管理软件开发项目的经验,包括担任IBM360项目经理那两年的经验,是软件工程领域的必读书。他的书描述了他的项目中做对和做错的地方,并且解释了为什么。每个同软件生产有关的人,特别是项目经理,都应当读一下这本书。那篇“No Silver Bullet”(没有银弹)文章是关于他对软件工程的洞察的续篇。在该文中,他谈论了我们为什么会遇上软件危机,为什么没有解决所有问题的万能方法,在未来我们能使用什么有潜力的技术来缓解这个危机。

该文提出的一个基本观点是,造成软件危机的有两种复杂性,一种是非根本复杂性(accidental complexity),另一种是根本复杂性(essential complexity)。非根本复杂性来自不适合于应用软件的范型、方法学和/或工具。只要有足够的资源来创建或者购买各种互为补充的工具,这类复杂性是可以消除的。面向对象编程有助于消除非根本复杂性,因为它提供了一种一致的软件开发范型,包容了分析、设计、实现各个阶段。这不是说面向对象的软件项目不包含非根本复杂性。MIS(Management Information Science,管理信息科学)1世界和其他领域面对的是一种特殊类型非根本复杂性。这些组织已经把大笔资金投入到关系数据库技术中去了,而现在正从面向动作往面向对象迁移。关系数据库模式语言的表现力不足以直接描述面向对象世界中数据和行为间的复杂关系。结果就是,面向对象设计者需要把这些复杂的关系翻译成关系数据库中简单的关系。这一翻译带来了非根本复杂性,而大多数MIS公司都愿意接受这一复杂性,因为否则的话他们就需要抛弃已经在用的久经考验的关系数据库产品,而去购买未经严格测试的面向对象数据库。即便在这样的情况下,面向对象范型也使得我们可以通过包装器(wrapper)来控制这种复杂性2。包装器是指把应用软件的一个部分同其他部分的非根本复杂性隔离开来的抽象层。我们将在第9章再讨论这种包装器机制。第9章覆盖了面向对象的物理设计问题。

软件危机的真正原因是根本复杂性。根本复杂性来自这一事实:软件本质上就是复杂的,没有哪种方法学或者工具可以消除这一复杂性。软件具有根本复杂性的理由如下:

1.从规模上来说,软件应用程序是人类创建的最复杂的实体。

2.软件是难以把握的,而且大部分是无形的。

3.软件不会像具有移动零件的机器那样会在传统意义上磨损折旧。但是,人们常常会以软件编写者从未想到的方式来使用软件(并常常会发现错误),而且最终用户始终希望他们的软件得以扩展。

1译注:现在更多是指管理信息系统。
2译注:现在很多O/R Mapping产品就是这样的wrapper。
本文仅用于学习和交流目的,不代表异步社区观点。非商业转载请注明作译者、出处,并保留本文的原始链接。

时间: 2024-08-04 14:33:51

《OOD启思录》—第1章1.2节Frederick Brooks观点:非根本复杂性与根本复杂性的相关文章

《OOD启思录》—第2章2.1节类和对象导引

第2章 类和对象:面向对象范型的建材OOD启思录2.1 类和对象导引面向对象范型使用类和对象的概念作为基本建筑材料.应用程序的分析.设计.实现模型一致地使用这些概念.通过现实世界中的例子来解释这些概念是最佳方案.如果有一屋子的人,你问:"给你们所需的全部零件,谁能装配出一只闹钟"?最多有一两个人会举手.但如果你问他们"这个房间里谁能够把闹铃设到早上9点",那么我可以放心地和你打赌,大多数人都会举手.大多数人会使用闹钟,但不会装配闹钟,这难道不荒谬吗?对这个问题,你最

《OOD启思录》—第2章2.5节 抽象类

2.5 抽象类OOD启思录除了我们已经讨论过的类,还有一种重要的抽象类型是我们需要探讨的.请思考下列问题:你曾经吃过水果吗?你曾经吃过开胃菜吗?你曾经吃过甜点吗?很多人对这3个问题的答案都是"是".只要你对这3个问题中的任一个回答了"是",请你接着思考下面的问题:水果尝起来味道如何?一份甜点有多少卡路里的热量?一份开胃菜价格是多少? 我可以说,没有人吃过"水果".很多人吃过苹果.香蕉或者桔子,但没有人吃过一个3斤重的.红色的就叫做"水果

《OOD启思录》—第1章1.1节革命家、改革家与面向对象范型

第1章 面向对象编程的动因OOD启思录1.1 革命家.改革家与面向对象范型在学习面向对象范型以及相关知识的过程中,你首先必须知道我们社区中的很多对立观点.每组对立观点意味着两个或者多个阵营,他们对自己的观点一般都具有宗教般的热情.最重要的对立观点之一是革命家与改革家之争.革命家相信,有一群开发者某一天在凌晨3点醒来,并发现以前我们一直都在用错误的方式开发软件.他们相信,他们找到了解决软件危机的方法,并且把这种方法叫做"面向对象编程".或许读者已经猜到,我是属于改革家阵营的. 改革家认为

《OOD启思录》—第2章2.4节动态语义

2.4 动态语义OOD启思录除了固定的数据和行为的描述之外,对象在运行时还随着其数据描述的动态取值具有局部状态(即当时的"快照").类的对象的所有可能状态的集合以及状态间合法的变换称为类的动态语义(dynamic semantics).动态语义允许对象对其生命期的两个不同时候发来的相同消息作出不同的回应.例如,看这个抽象例子: Method junk for the class X if (local state #1) then do something else if (local

《OOD启思录》—第2章2.2节消息和方法

2.2 消息和方法OOD启思录对象应当被看作机器,机器只为提出恰当请求的人执行公有接口所定义的操作.因为对象独立于使用者,也因为一些实现了面向对象概念的早期语言的语法,术语"发送消息"用于描述执行对象的行为.当消息被发送至对象,它必须判断是否理解该消息.如果理解,那么对象就把消息映射为一个函数调用,并把自身作为隐含的第一个参数传递过去.对解释语言而言,判断是否理解一个消息是在运行时完成的,而编译语言则是在编译时完成的. 对象行为的名称(或者原型)被称作消息(message).许多面向对

《OOD启思录》—第2章2.3节 类耦合与内聚

2.3 类耦合与内聚OOD启思录一些经验原则用于解决类的耦合与内聚问题.我们努力让类更紧密地内聚,并尽量降低类间耦合程度.这和在面向动作范型中试图让函数更紧密地内聚并尽量降低函数间的耦合程度的努力是一致的.函数中的紧密内聚意味着组成函数的所有代码都是紧密相关的.函数间的松耦合意味着当一个函数想要使用另一个函数时,它应当在总是从同一点进入该函数,并从同一点退出.这样,我们就可以得出这样的面向动作的经验原则:"函数应当只有一条返回语句." 在面向对象范型中,我们把松耦合和紧内聚的目标映射到

《OOD启思录》—第1章1.4节迭代模型

1.4 迭代模型OOD启思录软件开发的迭代模型看上去和瀑布模型差不多,区别只在于迭代模型允许开发者沿项目流程往返(见图1.2).如果我们在为系统的某个部分编写代码时发现了一个设计缺陷,我们可以回到设计阶段来分析并改正它.或者,如果我们在测试系统的一部分时发现了新的系统需求,我们可以回到分析阶段来修正这个问题.在面向动作范型中,迭代模型会带来很多问题.面向动作的软件常常会有很多位于数据和行为之间的隐含依赖关系.再同集中控制机制一结合,你就会发现自己处于这样一个境地:如果触动了已经存在的应用程序的部

《OOD启思录》—第2章2.6节角色与类

2.6 角色与类OOD启思录经验原则2.11确保你为之建模的抽象概念是类,而不只是对象扮演的角色. "母亲"或者"父亲"是不是类,还是某个"人"对象所扮演的角色?答案取决于设计者为之建模的领域是什么.如果在给定的领域中,母亲和父亲具有不同的行为,那么或许他们应当被建模为类.如果他们的行为相同,那么他们只是"人"类的对象所扮演的不同角色.例如,我们可以把家庭看作"父亲"类的对象."母亲"类

《OOD启思录》—第1章1.7节优秀设计者阶层

1.7 优秀设计者阶层OOD启思录Brooks在"No Silver Bullet"一文中提到的作为控制根本复杂性方法的最后一个话题是在企业中建立一个优秀软件设计者阶层,让他们从大批初级设计者中选拔接班人.这可以同管理者阶层类比:高级经理位居顶端,并且从大批初级经理中选拔接班人.这触及了软件开发者间"艺术还是科学"这一争论的核心.软件开发能力是后天习得的,还是需要天赋?我不想参加这一争论,但我想做个类比.如果有人拿枪指着我的脑袋逼我在一年内学会弹钢琴(我之前从未学过