2.8 小结
我们已经将模式应用于文件系统设计的各个方面。COMPOSITE模式的贡献在于定义了递归的树状结构，打造出了文件系统的主干。PROXY对主干进行了增强，使它支持符号化链接。VISITOR为我们提供了一种手段，使我们能够以一种得体的、非侵入性的方式来添加与类型相关的新功能。
TEMPLATE METHOD在基本层面（即单个操作层面）为文件系统的保护提供了支持。对于单用户保护来说，我们只需要该模式就足够了。但为了支持多用户，我们还需要更多的抽象来支持登录、用户以及组。SINGLETON在两个层面为我们提供了帮助：对机密的登录过程进行封装和控制，以及创建了一个可以为系统中任何对象所访问和替换的隐式用户。最后，MEDIATOR为我们提供了一种灵活和非侵入性的方式，来将用户和它们隶属的组关联起来。
图2-7对我们使用的模式以及体现了这些模式的类进行了总结。其中使用的表示方法是Erich多年前构想出来的，他称之为“pattern:role注解”。这种表示方法给每个类附加一个阴影框，其中包含了相关模式和参与者的名字。为了简洁，如果一个模式很显而易见而且没有歧义，那么图中只显示参与者的名字。通过避免增加连接线，以及使用具有醒目背景的阴影框，我们把混乱和干扰减到最少——类结构和对模式的注解看上去是位于两个不同的平面上。由于有些标注因为是模式本身的一部分而可以被省略掉，因此这种表示方法实际上减少了连接线的数量。例如，请注意图中省略了Directory和Node之间的聚合关系，因为它是COMPOSITE模式中内在的Component-Composite关系。
我发现Erich的表示方法具有高度的可读性和伸缩性，而且提供了许多有用的信息。如果将图2-7和我自己的类维恩图⑭表示方法（参见图2-4）进行比较，那么这一点就特别明显。它唯一的缺点是灰色的背景在传真时效果不太好。因此传真时请注意！
①Object Modeling Technology，对象建模技术。——译者注
②客户代码可以通过一种众所周知的方法（比如对Node类的一个静态操作）得到当前目录。访问众所周知的资源正是SINGLETON模式的职责。我们稍后就会用到该模式。
③好吧，近乎完美地执行。我必须承认在这个例子中，我忽略了内存管理的问题。具体说来，当客户代码在叶节点上调用adopt时可能会有潜在的内存泄漏，这是因为客户代码把所有权转让给了一个不会接受所有权的节点。对adopt来说这是一个非常普遍的问题，因为即便是Directory对象该操作仍然有可能会失败（比如客户代码没有足够的权限）。如果对Node进行引用计数就不会有这个问题了，因为adopt会在失败的时候递减引用计数（或者不递增引用计数）。
④这里指《设计模式》英文版原书的页码。后同。——编者注
⑤getSubject()是Link类特有的，只有Link类声明和实现了该操作。因此，如果我们把符号化链接当作节点来处理的话，是无法访问该操作的。但是，当使用Visitor的时候，这就不是什么问题了，因为符号化链接在访问节点的时候恢复了类型信息。
⑥与高级文件系统的“预防或撤销”相对。——译者注
⑦注意，我在其中为getName和getProtection加入了相应的set…操作。它们执行的操作和我们的预期完全一样。
⑧但把析构函数声明为private是不行的，因为那样子类就不能对析构函数进行扩展，来删除它们的子节点或它们包含的任何其他对象。
⑨这个名字确实没有遵守前面提到的规则，但doIsWritable实在是不合适。
⑩英文“Don’t call us, we’ll call you.”的意思是：“不要给我们打电话，我们会给你打电话。”此处的“call”一语双关，既指好莱坞原则中的打电话，又指软件中的函数调用。——译者注
⑪Unix用户应该很快就能指出还存在第三种类型，即“group”。我们稍后会考虑它。
⑫Doug Schmidt正确地指出，在C++中这样的定义是难以通过任何强制性的方法实现的[Schmidt96a]。例如，只要用一条简单的#define语句来把private定义为public，我们就可以让所有私有成员变成公有成员。避免这种篡改的一种方法是根本不在头文件中定义成员变量。相反，我们把成员变量和其他机密的实现细节定义在另一个单独的、不公开的头文件中。一个与此紧密相关的模式是BRIDGE，但这部分内容已经超出了这个脚注所允许的篇幅。
⑬这意味着User对象被存放在共享内存中，或者可以在程序之间传送。诚然，这是一个非常重要的细节，但它的实现既不会影响我们已经定义的接口，也不会影响我们采用的方法。
⑭Venn diagram，在集合论中用圆圈代表运算的图表，圆圈的位置和重叠表示了集与集之间的关系。——译者注
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。