2.实例研究：设计一个文档编辑器

• 1.设计问题

  • 1.0 用户界面

    
    image.png
  • 1.1 文档结构
    对文档内部表示的选择几乎影响Lexi设计的每个方面。所有的编辑、格式安排、显示和文本分析都涉及到这种表示。
  • 1.2 格式化
    Lexi是怎样将文本和图形安排到行和列上的？哪些对象负责执行不同的格式策略？这些策略又是怎样和内部表述相互作用的？
  • 1.3 修饰用户界面
    Lexi的用户界面包括滚动条、边界和用来修饰WYSIWYG文档界面的阴影。这些修饰有可能随着Lexi用户界面的演化而发生变化。因此，在不影响应用其他方面的情况下，能自由增加和去除这些修饰就十分重要了。
  • 1.4 支持多种视感标准；
  • 1.5 支持多种窗口系统；
  • 1.6 用户操作：按钮，菜单
  • 1.7 拼写检查和连字符：Lexi是怎么样支持像检查拼写错误和决定连字符的连字点这样的分析操作的？

• 2 文档结构
  从根本上来说，一个文档只是对字符、线、多边形和其它图形元素的一种安排。这些元素记录了文档的整个信息内容。然而，一个文档作者通常并不将这些元素看作图形项，而是看作文档的物理结构——行、列、图形、表和其他子结构。而这些子结构也有自己的子结构。

  • 2.1 递归组合
    层次结构信息的表述通常是通过一种被称为递归组合的技术来实现的。递归组合可以由简单元素逐渐建立复杂的元素。

    
    image.png
  • 2.2 图元
    为出现在文档结构的所有对象定义一个抽象类的图元，它的子类既定义了基本的图形元素（字符、图像），又定义了结构元素（行、列）
    图元有三个基本责任，它们是 1 )怎样画出自己，2 )它们占用多大空间，3 )它们的父图元和子图元是什么。
  • 2.3 组合模式
    递归组合不仅可用来表示文档，我们还可以用它表示任何潜在复杂的、层次式的结构。Composite模式描述了面向对象的递归组合的本质。
• 3. 格式化
     文档物理结构表示和格式化是不同的，记录文档物理结构的能力并没有告诉我们怎样得到一个特殊格式化结构。我们将“格式化”的含义限制为将一个图元集合分解为若干行。
  • 3.1 封装格式化算法
    L e x i是一个所见即所得编辑器，所以一个必须考虑的重要权衡之处在于格式化的质量和格式化的速度之间的取舍。我们通常希望在不牺牲文档美观外表的前提下，能得到良好的反映速度。这种权衡受许多因素影响，而并不是所有因素在编译时刻都能确定的。例如，用户也许能忍受稍慢一点的响应速度，以换取较好的格式。这种选择也许导致了比当前算法更适用的彻底不同的格式化算法。另一个例子，更多实现驱动的权衡是在格式化速度和存储需求之间：很有可能为了缓存更多的信息而降低格式化速度。因为格式化算法趋于复杂化，因而可以考虑将它们包含于文档结构之中，但最
    好是将它们彻底独立于文档结构之外。理想情况下，我们能够自由地增加一个 Glyph子类而不用考虑格式算法。反过来，增加一个格式算法不应要求修改已有的图元类。

未完待续。。。