设计模式第二章第三四小节课件.pptx

第二章;我们已经解决了文档物理结构的表示问题。接着，我们需要解决的问题是怎样构造一个特殊物理结构，该结构对应于一个恰当地格式化了的文档。表示和格式化是不同的，记录文档物理结构的能力并没有告诉我们怎样得到一个特殊格式化结构。 ;封装格式化算法; 例如，用户也许能忍受稍慢一点的响应速度，以换取较好的格式。这种选择也许导致了比当前算法更适用的彻底不同的格式化算法。又或者很有可能为了缓存更多的信息而降低格式化速度。 ;Compositor和Composition;Compositor和Composition;Composition和Compositor类之间的关系; 一个未格式化的Composition对象只包含组成文档基本内容的可见图元。它并不包含像行和列这样的决定文档物理结构的图元。 Composition对象只在刚被创建并以待格式化的图元进行初始化后，才处于这种状态。当Composition需要格式化时，调用它的Compositor的Compose操作。 Compositor依次遍历Composition的各个子图元，根据分行算法插入新的行和列图元。; 上图显示了得到的对象结构。图中由Compositor创建和插入到对象结构中的图元以灰色背景显示。;策略模式;2.4修饰用户界面;透明围栏;两种组合方法; Border类看起来是什么样的呢？边界有形这个事实说明它的确应该是图元，即Border类应该是Glyph的子类。此外还有一个强制性的必须如此的原因：客户应该一致地对待图元，而不应关心图元是否有边界。当客户画一个简单的、无边界的图元时，就不必对它作修饰。如果那个图元包含于一个边界对象中，客户应该以画出前面简单图元同样的方法画出这个边界对象，而不应该特殊对待该边界对象。;透明围栏的概念;MonoGlyph; 这使得MonoGlyph缺省情况下对客户完全透明。例如， MonoGlyph实现Draw操作如下： void MonoGlyph::Draw(Eindow* w) { _component-Draw(w); } MonoGlyph的子类至少重新实现一个这样的传递操作，例如， Border : : Draw首先激活基于组件的父类操作MonoGlyph : : Draw ，让组件做部分工作—即画出边界以外的其他东西。 Border : : Draw通过调用私有操作Draw Border来画出边界。细节我们这里不赘述了： void Border::Draw(Window* w) { MonoGlyph::Draw(w): DrawBorder(w); };???在我们已经有了给Lexi文本编辑区增加边界和滚动界面所需的一切准备。我们可以在一个Scroller实例中组合已存在的Composition实例以增加滚动界面，然后再把它组合到Border实例中。对象结构如下图所示。 ;注意我们也可以交换组合顺序，把一个带有边界的组合放在Scroller实例中。这样边界可以和文本一起滚动。透明围栏使得试验不同的选择变得很容易，使得客户和修饰代码无关。 ;3 Decorator模式