1.2 面向对象设计

本书的许多见解都受到应用计算机科学领域最近的发展（称为面向对象的分析和设计）的启发（Meyer，1988； Rumbaugh等，1991； Booch，1994）。 面向对象设计（OOD）涉及大量的技术和原理，这些技术和原理通常会使受过经典过程编程语言和软件设计培训的人员感到困惑。 其方法类似于寻找在柏拉图洞穴壁上投下阴影的物体。 好东西很难找到。

1.2.1 什么是面向对象设计

OOD使用多种策略来使软件灵活且可重复使用：

• 对象是系统的基本组件。他们代表了相对自治的代理，他们从事业务时彼此之间和对组成系统的对象的整个社区有用。当代OOD系统中一些使用最广泛的对象的名称表达了这种实用主义的观点：工厂，装饰器，立面，代理，迭代器，观察者，访客（Gamma等，1995）。这些对象执行的工作由其名称恰当地描述。工厂造东西。装饰器将模式应用于事物。观察者寻找消息。一位访客漫游并带来礼物。
• 对象通过简单的消息相互通信。这些消息分布在整个系统中。因为它们可以在整个系统中自由浮动，而不是局限于经典程序的严格协议，所以它们类似于居住社区中的通信。
• 对象相对愚蠢。他们做得很好，龙虾也做得很好。
• 智能驻留在系统中，而不是对象中，因为协同活动具有自己的生命，无法用单独的，不协调的活动来解释。对于OOD而言，对于生命本身，整体不仅仅是其各个部分的总和。
• 因为对象相对愚蠢，所以即使在新系统中，它们也相对简单且可用于多种用途。对象通常是可重用的，尽管OOD的这一方面已被某些支持者推销。
• 因为对象仅响应少量消息，并通过自己的简单消息与其他对象对话，所以它们的作用被封装。其他对象不知道它们如何工作。而且他们不在乎。他们只需要知道如何处理消息。
• 面向对象系统的组件是相对模块化的。如果系统的某些部分被丢弃或出现故障，则系统的其余部分通常可以继续运行。
• 对象可以从其他对象继承属性和行为。这可以节省组织良好的系统中的时间和空间，因为我们可以从更通用的事物类派生事物的实例。
• 对象通常是多态的。即，可以促使不同的对象以不同的方式响应相同的消息。他们的响应甚至可能是设计师无法预料的，​​但是在一个优雅的系统中，它们的响应通常不会有害。多态还意味着对象不在乎它们处理的数据类型。它们足够灵活，可以对各种数据返回合理的响应。这包括最简单的响应，即不响应。这种鲁棒性与经典过程系统完全不同，经典过程系统在馈送非法或意外数据时会崩溃或导致其他例程崩溃。设计良好的多态对象不是错误的。
• OOD促使设计师抽象化。 SPSS的面向对象程序员和设计师Nate Kirby指出，糟糕的程序员会忽略细节，而糟糕的设计师会迷失细节。对于设计者而言，每当对象的类别或类看起来合适时，就会引起人们对它作为实例的更一般类别的思考。由于这种普遍趋势，面向对象的系统本质上是分层的。

什么不是OOD？

1.2.2.1 OOD不是语言

OOD不是一种编程语言。 某些语言（例如Simula，Smalltalk和Java）使实现对象变得容易，而过程却难以实现。 其他语言（例如C ++）支持对象和过程的开发。 而其他语言，例如C，Pascal，Ada，BASIC，Algol，Lisp，APL和FORTRAN，则使得开发对象变得困难（但并非不可能）。 但是，使用有助于对象规范的语言并不能保证系统将是面向对象的。 确实，一些商业C ++图形和数字库是旧版FORTRAN和C过程的翻译。 这些较旧的例程伪装在包装器中，其名称旨在使它们看起来像对象。 根据本书中的定义，具有名为PieChartModel，PieChartViewer和PieChartController的类的Java库比具有三个同名子例程的FORTRAN程序更面向对象。

1.2.2.2 OOD不是GUI

OOD与现代图形用户界面（GUI）的开发相关联，因为它最容易通过定义明确的对象实例化图标或图形控件的行为。 OOD可以在脚本或基于命令的系统中实现，但是可以通过直接调用操作系统工具包来编程行为与对象驱动的GUI不可区分的GUI。 通过系统的行为来推断系统的设计是极其困难的（尽管并非不可能）。

1.2.2.3 OOD不是交互式系统

虽然现代桌面系统倾向于允许用户以灵活的方式与其组件进行交互，但这与OOD无关。 例如，Data Desk是最具交互性的商业统计数据包（Velleman，1998年），它不是基于OOD的。 这不一定是缺点。 确实，这可能是一个优势。 Data Desk的设计很好地满足了该程序包的需求，因为它的构想是密切关注其所在操作系统的功能。 OOD系统交互的程度取决于控制器类的实现方式。 没有用户控制，OOD系统可能是相对自治的。

1.2.3 为什么是OOD？

在过去的十年中，OOD未能实现其支持者的一些更为奢侈的主张。根据我们的经验，OOD并未为开发过程带来更高的可靠性。系统的可靠性更多地取决于开发过程早期的整洁设计和密集测试，而不是特定的设计方法。 OOD也没有给我们增加程序的可移植性。在过去的几年中，操作系统的发展比以往任何时候都快。制造商承诺他们的对象框架（程序员用于日常任务的对象）将保持不变，或者至少向上兼容。 OOD也没有为我们提供更快速，响应更快的软件。在执行时很难击败汇编语言或C程序。尽管有例外，但OOD最吸引人的元素（封装和多态性）通常会损害性能，这是事实。 OOD也没有给我们更快的开发进度。确实，OOD会延迟开发，因为对象通常很难正确地构想，并且修改现有对象比更改程序更困难。尽管市场上对OOD进行了大肆宣传，但很难击败二十年前在某些APL和Lisp系统中实现的开发周期。

仍然，OOD范例是考虑图形的最佳方法。 APL是一种矩阵函数语言，因此非常适合开发小型矩阵代数函数。 对于数字方法原型来说，它是无与伦比的。 Lisp是一种用于处理单词和符号列表的理想选择，因为它是一种列表处理语言。 相反，OOD是思考图形的自然框架，因为图形是对象（Hurley和Oldford，1991）。 我们可以看到并触摸这些对象。 拥有自然实现这些对象的语言是一个额外的好处。 但是，如果这些工作都没有出现在计算机上，那么我们仍然会发现值得付出的努力。 定义对象有助于组织思想。