Pattern-Oriented Software Architecture v1巨详细读书笔记 4

本笔记不同于《面向模式的软件体系架构 卷1 模式系统》的翻译，而是从《Pattern-Oriented Software Architecture vol.1 A system of patterns》原书［page 287-295］直接做的山寨翻译：），包括了command processor剩余部分，以及View Handler模式的前半部。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

［287］

［变体］
分散的controller功能。在此变体中，controller的角色被分散到多个组件中。如菜单按钮这样的每个用户界面元素都能在激活的时候创建命令对象，但controller的角色并不限制在图形用户界面组件中。
同Interpreter模式结合。在此变体中，一种脚本语言为应用程序提供可编程接口，此脚本的解析器扮演了controller的功能，应用Interpreter模式［GHJV95］从command对象构建抽象语法树。command processor是Interpreter模式中的客户端，通过激活command执行解析操作。

［已知应用］
    ……
［288］
    ……




［291］
View Handler
帮助软件系统管理视图(view)，允许客户打开、操作、排列视图，协调相互依赖的视图，并组织他们更新。
［例子］
多文档编辑器允许多个文档同时在一起工作，每个文档显示在它自己的窗口中。
［图］
要使这种编辑器便于使用，需要提供多种操作窗口的功能，例如：为了使一个文档上的多个独立视图能在一起工作，需要提供窗口克隆功能；为了在退出编辑器时关闭所有已经打开的窗口，需要保存并跟踪所有已经打开的窗口，在编辑器关闭时关闭这些窗口；为了让一个窗口中的修改能在另一个窗口中反应出来，需要实现窗口间有效的更新机制传播这种变化。
［环境］
提供特定数据的多视图软件系统或支持多文档的软件系统。
［问题］
支持多视图的软件系统通常需要附加功能来管理这些视图，客户能打开、操作、排列视图，如：窗口及窗口中的内容管理，视图间相互协作，其中一个视图改变时能自动将这种变化传播到相关的其他多个视图。
Serveral forces drive the solution to this problem:
    － 从用户直观的操作和客户端组件的调用角度出发，应该很容易地在系统中管理多个视图。
    － 视图的实现不应该彼此依赖，也不应该和管理视图的代码混合在一起。
    － 视图的实现不同，在系统的生命周期中都可以添加附加类型的视图。

［解决方案］
从特定视图的表示或控制代码中分离出管理视图代码。
View Handler组件管理系统中提供的所有视图，提供视图管理的所有必要功能，能打开、关闭、协调、处理视图，如：命令‘排列’，能按顺序将视图排列起来。
(??)Specific View、表示和操控他们的功能一起被封装在分离的视图组件中，supplier给视图提供他们所表示的数据。
View Handler模式像Model－View－Controller模式建议的一样，采用了从功能核心中分离出表示(presentation)的思想，但它不提供软件系统中所有的结构，它只是从Model和View组件中分离出管理所有View的职责，以及分离出他们之间的相互依赖关系，将这些职责赋予View handler，例如：视图不需要管理他的子视图。因而，View Handler模式比Modle－View－Controller模式的粒度更佳，它能为精化Modle和相关的View之间的关系提供帮助。
可以用Abstract Factory［GHJV95］和Mediator［GHJV95］来考虑View Handler组件。client是独立于如何创建Specific View的，这就如同Abstract Factory一样；同样client也独立于View之间的协作，这也如同mediator一样。
［293］
在文档编辑器的例子中，我们为每种文档窗口提供了一个View组件，系统提供窗口用来：编辑文档，打印预览，浏览文档页缩略图，一个View Handler将用来管理这些View，除了创建和删除窗口，View Handler还提供了：将特定窗口显示到最前端，克隆最前端的窗口，排列窗口让他们不重叠等等功能。窗口的supplier就是被显示的文档，同一个文档可以同时有多个View，而且还能同时显示多个文档。


［结构］
View Handler是此模式的中心组件。它负责打开client指定需要的特定新View，它会实例化相应的View组件，并保证他们的正确初始化，然后请求新的View把它自己显示出来；如果请求的View已经打开，View Handler会将这个View显示到最前端；如果请求的View已经打开，但是被最小化了，View Handler会让此View将它自己用全尺寸的方式显示出来。
View Handler也提供关闭View的功能，它会根据退出应用程序时的需要选择是关闭一个View或者是所有当前已经打开的View。
View Handler的主要职责是提供View管理服务，包括功能如：将特定View显示到最前端，排列所有的View，将一个View分割成多个部分，刷新所有View，一个文档上View的克隆。这些管理功能，如果被分散在很多不同的View组件中将很难组织起来。
［图］
［page 294］
协作是View Handler的一个附加职责。View间也许有依赖关系，就像ET++［WGM88］中的VObjectText对象一样，多个View显示了一个组合文档的不同部分。在排列这些View时，应该将他们逐个排列。如果用户在此文档的一个View中做了更改，则应该按照某种预定的次序更新其他View，比如：显示最全局信息的View应该第一个被更新。

Abstract View组件定义所有View的公共接口，View Handler用这个接口来创建、关闭、协调所有的View，此系统之下的平台用此接口执行用户事件响应，如：调整窗口大小。Abstract View接口必须提供View所有可能执行的操作函数。

Specific View组件从Abstract View继承，并实现它的接口。此外每个View实现它自己的显示函数，此函数从View的supplier获取数据，把数据准备好并呈现给用户，此函数在打开和更新View时会被调用。
［图］

Supplier组件为View组件的显示提供数据。它给客户端(如：View)提供了获取及更改数据的接口，在内部状态被修改时，它会通知依赖于它的组件，这些组件可以是独立的View，也可以是组织更新的View Handler。

［page 295］
［图］

以下的OMT类图显示了View Handler模式的结构：
［图］