设计模式-递归控制模式

递归控制模式对用来实现数千个需求的复杂系统来说是非常有价值的。
5.1摘要
递归控制模式的基本概念就是将构造一个非常复杂的系统看成是在一系列在不同层次上相互关联的部分，就像不同显示比例的显微镜。在一个给定层次的抽象上，一个对象给它的对应体提供不透明的接口，同时和它们相互协作来提供远大于他们自身所能提供的行为。这个对象在内部通过代理给自身更小的部分对象实现了自己的行为（对外部对象不可见），这些小对象和对象通过组合关系聚合在一起。每个部分小对象通过比它更小的部分对象实现了自己的不透明接口。通过递归使用这种方式， 能够创建越来越小的对象，直到一种容易编程和任务单一的叶对象为止。

5.2 问题
我们需要一种策略来分解大而复杂的系统，这种分解方式必须是非常直接的，而且是可扩放的。同时允许大的抽象用户实例的映射能在分解过程中的每个阶段可验证。

5.3 模式结构
下图描述了递归控制模式的简单结构。系统被认为是一个包含部分对象的复杂对象。这些部分对象是由更小的对象组成的子系统。这个分解过程一直持续到只有简单结构和提供简单服务的叶对象为止。这个图将模式看成是具有2个相连联系的简单对象：容器联合角色和附属联合角色。

5.4 协作角色

• element(元素)

      在模式中的原色有2个基本特点，第一个，它通过一个或者多个不透明接口提供了一系列服务；第二个，内部来说，它提供这些服务主要依赖于小的部分对象的代理和协调。

5.5 结论
这个简单模式的重要性在于协作可以从多个层次上的抽象角度来看待。对大型和复杂系统来说，这意味着系统行为可以在不同层次的细节上来观察。在每个细节上，元素都能提供一系列的用户实例。

5.6 实现策略
这个模式的实现包含了简单模式的重复应用。两个对立的工作流被用来创建这个模式的实例。自顶向下的工作流方式开始自系统层，用来识别那些用来实现协作的服务的结构对象。在嵌入式和实时系统上，有许多标准方式来将系统组织为子系统。这种组织方式，即使先前系统不是面向对象的，也能通过这种方式被集成进来。它能利用那些在子系统专家上能被发现的那些专业技巧。
这个方式的另一个优点在于它易于保证，当开发人员在不断具体化过程中，它能持续实现用户实例。通过在高层次上创建场景，我们很容易识别系统角色的交互。通过用系统的部分对象集来替代系统，我们仍然能够通过测试来保证我们仍然满足相同的场景。这些部分能够被它们的部分集合来替换，而且这个场景仍能延续下去。这使得开发人员能够保证在分解的每个步骤，他们都做对了事情。
另一种方式则是专注于领域的构造：识别那些在领域中的关键类和关系。因为有着先前的广泛经验，识别跨领域的协作，并把它们构筑进更大的块对象是可能的。这种方式可以一直演进到子系统层次。这种方式是对专注于一个或多个领域的开发人员来说是自然的，但它也可能存在问题，因为它不能很清楚的表明正确的部分正在构造，这个需要足够多的控制块能够用来实现一个已知的用户实例的时候才行。

5.7 相关模式
这个模式类似于组合模式。组合模式提供的行为只在最小的层次的分解上。整体-部分模式在层分解层次上提供服务，但是它没有作用在高层的结构上。进一步来说，它们的工作专注于UML解释上，并没有集成用户实例的概念和它们的实现。

5.8 样例模型
在最高层次上，用户实例表现为系统的行为而不是部分的行为。一个航天飞机也许会提供一个用户实例例如“拍摄星球表面”这个功能。这个用户实例如下图所示：

我们可以分解这个航天飞机为相互协作的子系统来实现上述系统层次的用户实例，如下图所示：

这些子系统都是大的对象，它们通过许多更小的对象来实现了它们的行为。然而，通过这些子系统的协作，实现了系统层次的用户实例。

系统层次的用户实例可以被进一步分解为更小的用户实例通过< 和 <>用户实例关系。如下图所示，这些用户实例都被向下分解到能够被下一层的简单对象来实现为止。

这些用户实例到子系统的映射关系如下图所示：

这些子系统本身都是些组合对象，包含了很多小的部分。例如，科学子系统对象毫无疑问包含了一个或者多个相机，镜头，滤波器等。这些对象相互协作来实现 拍照  这个用户实例。相似的，电源子系统包含例如电池，太阳能，交换机，中继器等。导航子系统包含飞行仪，太阳系的多维图等。下图显示了这些子系统的详细细节。