第3章命名方案设计.PDFVIP

第 3 章 命名方案的设计 3.0 概 述 在前一章中，我们阐述了命名方案的一种抽象模型。当设计一个实际的命名方案时， 许多工程性的考虑——约束、额外规定或迫切需求、环境压力——影响着设计。用户与计 算机系统交互的主要方式之一是通过名字，系统命名方案的质量可能显著影响用户体验的 质量。同样，由于名字是连接各个模块的黏合剂，命名方案的特性能够显著影响模块性对 系统的作用。 本章探讨命名方案设计相关的工程性考虑因素。主要篇幅介绍各种影响模块性和可用 性的命名考虑因素。对万维网中统一资源定位器（URL ）的案例研究，阐明了命名模型以 及在命名方案设计中出现的一些问题。最后，3.3 节探讨了实际命名方案的一些病态问题。 3.1 命名方案设计中的考虑因素 我们从讨论命名和模块性之间的相互作用开始。 3.1.1 模块化共享 用名字连接各个模块提供了极大的灵活性，但却引入了一种冒险：设计者有时需要处 理预先存在的名字，可能是由设计者无法控制的其他人选择的。每当独立设计模块时，这 一冒险都可能出现。如果为了使用一个模块，设计者就必须了解并避免模块内部为其组件 所用的名字，那么我们就没能实现模块性的主要目标之一，即所谓模块化共享。模块化共 享意味着，人们可以通过其名字来使用一个共享模块，而无须知道该模块所使用的其他模 块的名字。 模块化共享的缺乏以名字冲突的形式显现：由于某种原因，两个或两个以上不同的值 在相同上下文中竞争对同一名字的绑定。当集成两个（或更多个）独立构建的程序组、文 档组、文件系统、数据库或者实际上任何组件的集合，这些组件使用相同的命名方案来实 现面向集成的内部互连，名字冲突就可能会出现。名字冲突可能是个严重问题，因为修复 它需要改变某些冲突名字的使用。实现这样的改变可能是棘手的或者是困难的，因为子系 统的原作者不一定可以找来帮助查找、理解并改变冲突名字的使用。 实现模块化共享的明显方式是为每个子系统都提供自己的命名上下文，然后再设计出 在多个上下文之间交叉引用的某种方法。使得交叉引用能够正确工作是个挑战 。 例如，考虑 图 3.1 所示的两组程序——文字处理器和拼写检查器——每组都包含通过 名字连接 到 一 起 的多个模块，每组都有一个组件称 为 INITIALIZE 。过程 WORD_ 78 计算机系统设计原理 PROCESSOR 的设计者希望使用 SPELL_CHECK 作为一个组件。如果设计者尝试通过在一 个命名上下文中简单地绑定所有它们的名字来集成两组程序，如同 图中所示 （其中箭头显 示了每个名字的绑定），那么将有两个模块竞争对名字 INITIALIZE 的绑定。我们遇到一个 名字冲突。 于是，设计者转而尝试为每组程序 建单独的上下文，如 图 3.2 。这一步本身并没有完 全解决 问题，因为程序解释器现在需要一些规则，以便为名字的每次使用确定所用的上下 文。例如，假设正在运行 WORD_PROCESSOR ，并遇到名字 INITIALIZE 。它如何知道应 该在 WORD_PROCESSOR 的上下文而不是 SPELL_CHECK 的上下文中解析该名字？ 图 3.1 两套独立编写的程序通过只是合并其上下文而实现的过于简单的集成。过程 WORD_ PROCESSOR 调 SPELL_CHECK，但是 SPELL_CHECK 有一个组件具有与 WORD_ PROCESSOR 的一个组件相同的名字。没有单独一组绑定可以正确工作 图 3.2 相同两组程序但是使用分离上下文的集成。为 SPELL_CHECK 拥有一个单 独上下文，消除了这个名字冲突，但是程序解释器现在需要一些基础工作， 选择一个上下文来覆盖另一个上下文 继续第 2 章中的命名模型以及 电子邮件系统的例子，这个问题的一个直接解决办法是 在 WORD_PROCESSOR 上下文中为 SPELL_CHECK 增加一个绑定并把 明确的上下文引用 连接到每个模块，如 图 3.3 。这一增加需要修补模块的表