设计模式3教材.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * 1) 比静态继承更灵活 与对象的静态继承（多重继承）相比， D e c o r a t o r模式提供了更加 灵活的向对象添加职责的方式。可以用添加和分离的方法，用装饰在运行时刻增加和删除职 责。相比之下，继承机制要求为每个添加的职责创建一个新的子类（例如， B o r d e r S c r o l l a b l e Te x t Vi e w, BorderedTe x t Vi e w）。这会产生许多新的类，并且会增加系统的复杂度。此外，为一 个特定的 C o m p o n e n t类提供多个不同的 D e c o r a t o r类，这就使得你可以对一些职责进行混合和 匹配。 使用D e c o r a t o r模式可以很容易地重复添加一个特性，例如在 Te x t Vi e w上添加双边框时， 仅需将添加两个B o r d e r D e c o r a t o r即可。而两次继承 B o r d e r类则极容易出错的。 2) 避免在层次结构高层的类有太多的特征 D e c o r a t o r模式提供了一种“即用即付”的方 法来添加职责。它并不试图在一个复杂的可定制的类中支持所有可预见的特征，相反，你可 以定义一个简单的类，并且用 D e c o r a t o r类给它逐渐地添加功能。可以从简单的部件组合出复 杂的功能。这样，应用程序不必为不需要的特征付出代价。同时也更易于不依赖于 D e c o r a t o r 所扩展（甚至是不可预知的扩展）的类而独立地定义新类型的 D e c o r a t o r。扩展一个复杂类的 时候，很可能会暴露与添加的职责无关的细节。 * * * * * * * * * * * * * * * * * 3.7 FLYWEIGHT（享元） 代码示例 为了避免给每一个Glyph的字体属性都分配存储空间，我们可以将该属性外部存储于GlyphContext对象中。 GlyphContext是一个外部状态的存储库，它维持 Glyph与字体（以及其他一些可能的图形属性）之间的一种简单映射关系。对于任何操作，如果它需要知道在给定场景下Glyph字体，都会有一个 GlyphContext实例作为参数传递给它。然后，该操作就可以查询GlyphContext以获取该场景中的字体信息了。这个场景取决于 Glyph结构中的 Glyph的位置。因此，当使用Glyph时， Glyph子类的迭代和管理操作必须更新 GlyphContext 。 3.7 FLYWEIGHT（享元） 代码示例 在遍历过程中， GlyphContext必须它在 Glyph结构中的当前位置。随着遍历的进行， GlyphContext::Next增加_index的值。 Glyph的子类（如， Row和Column）对 Next操作的实现必须使得它在遍历的每一点都调用 GlyphContext::Next。 GlyphContext ::GetFocus将索引作为 Btree结构的关键字， Btree结构存储 glyph到字体的映射。树中的每个节点都标有字符串的长度，而它给这个字符串字体信息。树中的叶节点指向一种字体，而内部的字符串分成了很多子字符串，每一个对应一种子节点。 下页上图是从一个glyph组合中截取出来的： 字体信息的BTree结构可能如下： 内部节点定义 Glyph索引的范围。当字体改变或者在Glyph结构中添加或删除 Glyph时，Btree将相应地被更新。例如，假定我们遍历到索引102，以下代码将单词“except”的每个字符的字体设置为它周围的正文的字体（即，用Time 12字体，12-point Times Roman的一个实例）: 3.7 FLYWEIGHT（享元） 代码示例 原来字体映射 设置为Time 12 新的字体映射 3.7 FLYWEIGHT（享元） 代码示例 假设我们要在单词“ expect ”前用12-point Times Italic字体添加一个单词 D o n’t（包括一个紧跟着的空格）。假定g c仍在索引位置1 0 2，以下代码通知g c这个事件： B t r e e结构变为如下图所示： 3.7 FLYWEIGHT（享元） 代码示例 FlyweightFactory是我们需要的最后一个对象，它负责创建 Glyph并确保对它们进行合理共享。GlyphFactory类将实例化 Character和其他类型的 Glyph。我们只共享Charater对象；组合的Glyph要少得多，并且它们的重