面向对象软件构造 (Bertrand Meyer 著)

Part A: The Issues 议题

第一章 软件品质

第二章 面向对象的标准

Part B: The Road To Object Orientation 通向面向对象之路

第三章 模块性

第四章 复用性方法

第五章 走进对象技术

第六章 抽象数据类型

Part C: Object-Oriented Techniques 面向对象技术

第七章 静态结构: 类

第八章 运行时结构: 对象

第九章 内存管理

第十章 泛型

第一章 软件品质

　　1.1 外部和内在的因素

　　1.2 外部因素介绍

　　1.3 关于软件维护

　　1.4 摘要

　　1.5 资源

第二章 面向对象的标准

　　2.1 标准

　　2.2 方法和语言

　　2.3 实现和环境

　　2.4 库

　　2.5 更多的秘密预告

　　2.6 资源

第三章 模块性

一旦模块编程被采用,就意味着程序的构造如同散件组装,这些散件通常是些子程序。但是这样的技术不能够带来真正的扩充性和复用性的利益,除非我们有更好的方法来保证最终的散件－模块(modules)－在稳定的架构中是独立的和组织化的。任何完整的模快性定义都必须确保这些属性。

那么,如果一个系统是由独立的元素以连贯简单的结构所连接而成,一个软件构造方法帮助设计者产生了这样的软件系统,那么这个方法就是模块化的。通过研究什么样的精确属性（如一个方法）能够贴上”模块化”的标签,来改善这个非正式的定义,这是本章的目的。焦点会集中在设计方式上,但是其思想也适用于系统构造(分析,规格)的早期阶段,当然也必须在实现和维护阶段继续保持。

对于一个专业的软件开发者,原则和规则是同标准一样的重要。不同之处仅是一个因果关系: 标准是互相独立的－对于一个方法而言,确实可能满足了其中的一个却违犯了其它的标准－然而规则从标准中得出,原则从规则中而来。

　　3.1 五条标准

　　　　模块分解性　　Modular decomposability

如果一个软件构造方法能把一个软件问题分解成很多较简单的子问题,并把这些子问题用一个简单的架构连接起来,而且能够完全独立的在每一个子问题上再更进一步的分解,那么,这个方法就满足模块的分解性
由于每个子问题可能仍然十分复杂,需要进一步的分解,这个过程就将不断的循环往复

分解性需求的必然结果是劳动力的分工: 一旦您已经把一个系统分解成子系统,您应该能够把这些子系统的工作分配给不同的人或组。由于在各个子系统之间存在的关联的限制,这会是一个困难的目标:

• 您必须把这样的关联尽可能的减小到最少；否则每个子系统的开发会受制于其它子系统的工作进度。
• 关联必须要清楚: 如果您不能列出子系统之间的所有关系,您可以在项目结束的时候得到一系列的软件元素,这些组件看上去能独立工作,但是却不能够被整合成一个完整的系统来满足最初问题的全部需求。

合分解性标准的方法中最明显的例子是由上而下设计(top-down design)。这种方法指导设计者由系统函数的一个最抽象描述开始,然后经过连续的步骤精炼这个描述,在每个步骤中把每个子系统分解成几个更简单的子系统,直到所有的元素抽象化程度都足够低到可以直接实现。这个过程可以模拟成树状.

一个典型的反例是,在您创造的每个软件系统中,所有的方法都鼓励您包括一个全局的初始化模块。一个系统中的许多模块需要多种多样的初始化－如打开某个文件或初始化某些变量之类的行为,在运行第一个直接有效的任务之前,模块必须要运行这些初始化。把所有的初始化行为都集中起来,在一个模块中为系统的所有部分做初始化,这看上去是个不错的主意。所有的这些动作都在系统执行的相同阶段执行,这样的模块将会展示良好的“时间性内聚(temporal cohesion)”。但是为了获得这种时间性内聚,这种方法会危及模块的自治:您将不得不授权初始化模块访问许多独立的数据结构,这些数据结构属于系统的各种不同的模块而且需要特定的初始化行为。这意谓初始化模块的作者将会经常地看到其它模块的内部数据结构,而且和它们的作者交互。这与分解性标准不相容。

在面向对象的方法中,每个模块将会负责它自己数据结构的初始化.

　　　　模块组合性　　Modular composability

一些软件元素在不同于它们最初被开发的环境中,彼此之间可以自由组合以产生新的系统,如果一个方法支持这种编写方式,那么这种方法满足模块的组合性

分解性关注于从完整的系统中推导出子系统,而组合性从事相反的过程:从原始设计的环境中提取出现存的软件元素,使得在不同的环境中再一次使用它们

组合性直接地与复用性的目标相关联:目标是要找到方法来设计软件元素以完成明确定义的任务和在广泛不同的环境中使用。这一个标准反映了一个以往的梦想:把软件设计过程转换成一个建筑箱体预制板的行为,这样我们就能组合标准预制元素来建造程序

例1:子程序库。子程序库被设计成一组可组合的元素。一个成功的领域是数值计算,它通常依靠那些仔细设计的子程序库来解决线性代数,有限元,微分方程等等之类的问题

例2: Unix Shell定义。基本的Unix指令把输入操作看成一个连续的字符流,而且用同样的标准结构产生一个输出。通过命令行语言(“shell”)中的操作符| 使它们潜在的组合起来: A | B表示一个程序得到A的输入,让A运行，并把结果输出到B。这个系统的定义证实了软件工具的组合性

　　　　模块理解性　　Modular understandability

如果用某个方法帮助编写软件,读者能在不必了解其它模块的情况下理解每个模块,或者,最差的情况下也只须了解少数其它的模块，那么,这个方法就支持模块的理解性

这个标准的重要性得自于它对维护过程的影响。大多数的维护行为,不管是重要的或是不重要的,都不得不深入理解已存在的软件元素。如果软件读者(维护人员)不能够独立地理解这些元素,那么这个方法很难被称之为模块化的

和其它的一样,这个标准适用于任何层次的系统描述模块:分析,设计,实现

反例: 顺序的关联 假设一些模块由于设计的原因,以至于它们只能在特定的命令顺序下才正确地动作 举例来说,如果您在A之后C之前运行B,它才能正确地工作,也许因为这就是在先前遇到的Unix符号中”管道(piped)”的使用形式:A | B | C那么,不了解A和C的情况下,也不可能理解B

　　　　模块连续性　　Modular continuity

在使用某个方法产生的软件结构中,如果在一个问题规格方面的微小改变将只会引起一个模块的变化,或少量模块的变化，那么,这个方法满足模块的连续性

这个标准直接地结合了扩充性的一般目标 连续性意味着微小的变化应该影响系统结构中的个别的模块,而并非结构本身

术语”连续性”是从数学分析里的连续函数观念的类推中描绘出来的。如果参数的微小改变会引起结果中的等比例地微小变化,那么这个数学函数就是连续的。现在所考虑的函数是软件构造方法,您能观察到从规格中获取系统的机制:

由于我们缺乏软件尺寸大小的观念,因此这个数学术语只是提供一个类推的结果。更精确的,对于程序的一个”小的”或”大的”变化程度,它将尽可能地定义一个一般的可接受的衡量标准；但是对规格来说做相同的事却有更多的挑战。然而,如果我们并没有要求那么严格的话,这个概念应该是直观清晰的并且符合在任何的模块方法上的基本需求

例1: 符号常数。一条合理的规则禁止把任何数字或文本常数直接地使用在程序的指令中；作为替代的是依赖于符号名,并且真实的数值只出现在常数定义中(Pascal或Ada的常数(constant),C的预处理程序宏, Fortran 77的参数(PARAMETER),在本书符号中的常数属性)。如果数值变化,唯一要做的就是更新其常数定义。不管它们的名字,由于常数都有显著地改变倾向,所以这条小的但重要的规则对于连续性是一种明智地预防措施

反例1:使用实际表示法。一个方法,在其中程序设计会在数据实际实现之后被模式化,这将会产生对环境方面轻微的改变都非常敏感的设计

　　　　模块保护性　　Modular protection

如果一个方法产生的结构,在其中一个运行的模块里发生的反常状态将保持限制在当前的模块中,或最坏也只将会影响到少数附近的模块,那么,这个方法满足模块的保护性

　　3.2 五件规则

　　　　直接映射 Direct Mapping

在构建一个软件系统的过程中所设计的模块结构应该与在问题域模型化的过程中所设计的模块结构保持兼容

　　　　少量接口 Few Interfaces

每个模块应该尽可能少的与其它模块沟通

更精确地说,如果一个系统由n个模块组成,那么模块之间的连接数目应该尽量保持接近最小量n-1, 如(A)图所示,而不是如(B)所示的最大值n(n-1)/2

在上图中,情况(A)显示了通过一个非常集中的结构, 达到最小链接数目n–1的方法:一个主模块；每个模块只能和它对话。但是也有更加"平行"的结构,如(C)图,有几乎相同数目的链接。在这个方案中,每个模块仅仅和它的二个紧邻的邻居对话,而没有中央的集权。由于它并不符合功能性的,由上而下的传统设计模型,所以这样的设计风格起先有点令人惊讶。但是它能产生健壮的,易扩充的架构；这种结构,适当地加工就可以产生面向对象技术的结构类型

　　　　小型接口(弱耦合) Small Interfaces

如果二个模块通讯,它们应该交换尽可能少的信息

　　　　精确接口 Explicit Interfaces

只要 A 和 B 两个模块通讯, 在 A 或 B 或两者之间的代码必须要有明确的说明

假设模块A和模块B使用相同的数据项目x.那么,事实上A和B是通过x的强耦合,即使它们之间可能没有像程序调用那样的明显的连接

　　　　信息隐藏 Information Hiding

每个模块的设计者必须选择模块属性的一个子集作为有关此模块的正式信息,其可以让客户端模块的作者有效使用

一个模块的公共属性也即是模块的接口

　　3.3 五项原则

　　3.4 摘要

　　3.5 资源

第四章 复用性方法

　　4.1 复用性的目标

　　4.2 我们应该复用什么?

　　4.3 软件开发中的重复

　　4.4 非技术障碍

　　4.5 技术问题

　　4.6 模块结构上的五个需求

　　4.7 传统的模块结构

　　4.8 重载和泛型

　　4.9 摘要

第五章 走进对象技术

　　5.1 计算的要素

　　5.2 函数分解

　　5.3 基于对象的分解

　　5.4 面向对象软件构造

　　5.5 议题

　　5.6 摘要

第六章 抽象数据类型

　　6.1 标准

　　6.2 实现变体

　　6.3 有关对象的抽象观点

　　6.4 形式化规格

　　6.5 从抽象数据类型到类

　　6.6 超越软件

　　6.7 主题补充

　　6.8 摘要

第七章 静态结构: 类

　　7.1 对象不是主题

　　7.2 避免一般性的混乱

　　7.3 类的角色

　　7.4 一个统一的类型系统

　　7.5 一个简单的类

　　7.6 基本约定

　　7.7 计算的面向对象式样

　　7.8 选择性输出和信息隐藏

　　7.9 组合一切

　　7.10 讨论

　　7.11 摘要

第八章 运行时结构: 对象

　　8.1 对象

　　8.2 作为模型工具的对象

　　8.3 操作对象和引用

　　8.4 创建过程

　　8.5 有关引用的更多介绍

　　8.6 引用上的运算

　　8.7 组合对象和扩展类型

　　8.8 附属: 引用和值的语义

　　8.9 引用处理: 优缺点

　　8.10 讨论

　　8.11 摘要

第九章 内存管理

　　9.1 在对象上发生了什么

　　9.2 宽松方式

　　9.3 回收内存: 议题

　　9.4 程序员控制的归还

　　9.5 组件层次的方式

　　9.6 自动内存管理

　　9.7 引用计数

　　9.8 垃圾收集

　　9.9 垃圾收集的实际议题

　　9.10 一个带有内存管理的环境

　　9.11 摘要

　　9.12 资源

第十章 泛型

　　10.1 水平和垂直类型的概括

　　10.2 参数类型化的需求

　　10.3 泛化类

　　10.4 数组

　　10.5 泛型的代价

　　10.6 讨论: 仍未完成

　　10.7 摘要