实例研究：设计一个文档编辑器（9）

支持多种视感标准
获得跨越硬件和软件平台的可移植性是系统设计的主要问题之一。将L e x i重新定位于一
个新的平台不应当要求对L e x i进行重大的修改，否则的话就失去了重新定位L e x i的价值。我
们应当使移植尽可能地方便。
移植的一大障碍是不同视感标准之间的差异性。视感标准本是用来加强某一窗口平台上
各个应用之间用户界面的一致性的。这些标准定义了应用应该怎样显示和对用户请求作出反
映。虽然已有的标准彼此差别不大，但用户还是可以清楚地区分它们—一个应用程序在
M o t i f平台上的视感决不会与其他某个平台上的完全一样，反之亦然。一个运行于多个平台的
应用程序必须符合各个平台的用户界面风格。
我们的设计目标就是使L e x i符合多个已存在的视感标准，并且在新标准出现时要能很容
易地增加对新标准的支持。我们也希望我们的设计能支持最大限度的灵活性：运行时刻可以
改变L e x i的外观和感觉。

对象创建的抽象
我们在L e x i用户界面看到的和操作的是一个图元，它被组合于诸如行和列等不可见的图元之中。而这些不可见图元又组合了按钮、字符等可见图元，并能正确的展现它们。界面风格关于所谓的“窗口组件”（Wi d g e t s）有许多视感规则。窗口组件是关于用户界面上作为控制元素的按钮、滚动条和菜单等可视图元的另一个术语。窗口组件可以使用像字符、圆、矩形和多边形等简单图元来表示数据。
我们假定用两个窗口组件图元集合来实现多个视感标准：
1) 第一个集合是由抽象G l y p h子类构成的，对每一种窗口组件图元都有一个抽象G l y p h子类。例如，抽象子类S c r o l l B a r放大了基本的G l y p h接口，以便增加通用的滚动操作； B u t t o n是用来增加按钮有关操作的抽象类；等等。
2) 另一个集合是与抽象子类对应的实现不同视感标准的具体的子类的集合。例如，S c r o l l B a r可能有M o t i f S c r o l l B a r和P M S c r o l l B a r两个子类以实现相应的M o t i f和P M ( P r e s e n t a t i o nM a n a g e r )风格的滚动条。
L e x i必须区分不同视感风格的窗口组件图元之间的差异。例如，当L e x i需要在界面上放一个按钮时，它必须实例化一个有正确按钮风格的G l y p h子类( M o t i f B u t t o n、P M B u t t o n或M a c B u t t o n等)。
很明显L e x i的实现不能够直接通过调用C + +构造器来做这些工作，那会把按钮硬性编定为一种特殊风格，而不能在运行时刻选择风格。当L e x i要移植到其他平台时，我们还不得不进行代码搜索以改变所有这些构造器调用。并且按钮还仅仅是L e x i用户界面上众多窗口组件之一。对特定视感类进行构造器调用会使代码混乱，产生维护困难—只要稍有遗漏，你就可能在M a c应用程序中使用了M o t i f的菜单。
L e x i需要一种方法来确定创建合适窗口组件所需的视感标准。我们不仅必须避免显式的构造器调用，还必须能够很容易地替换整个窗口组件集合。可以通过抽象对象创建过程来达到上述两个要求，我们将用一个例子来说明。