设计模式-层次模式

1.层次模式

层次模式基于抽象的层次把领域组织为层次结构

1.1 摘要

许多系统领域可以看成是一系列在某个特定层次抽象上的语义概念。抽象的概念被它具体的概念来实现的。

1.2 问题

一个抽象域内的系统必须被比它具体的（或者说次级别抽象）的域系统来实现。在许多系统上，必须考虑应用系统的在多平台上的可移植性或者说我们需要提供一个抽象的平台或者可执行环境层来使得应用程序能够更好的适配上来。

1.3 模式结构

下图描述了层次模式的结构。注意，它仅包含单个主元素（领域包）和它的接口。限制解释了这个模式的结构。

1.4.协作角色

这是个简单的模式，其中单角色被递归使用

  *领域

领域角色是UML的包概念的一种术语使用。在UML中，一个包可以认为是包含模型元素的容器。UML没有提供任何指导来确定哪个元素被放进哪个包的准则。一个准则是根据公共的主题事务来分组模型元素。单个主题事务的所有概念共享公共的词汇。这个主题事务就被称作“领域”。比如说“用户界面”这个领域，用户就希望找到“窗口，对话框”等层次的类或者概念。

1.5. 结论

分层模式允许系统提供更高层次的抽象概念，更紧密的切合应用的需求和应用域的概念，即使这些服务最终是由一系列更具体的类提供的简单服务组合而成。在一个紧合分层的结构中，同一层的类只能调用同一层或临接下一层类的服务。 在一个开放层次结构中，某一层次的类可以截获同层的类或者低于它的任意下层的类的服务。 换句话说，紧合分层的结构提供了更好的抽象，而且更容易被正确的修改，因为你的修改只会影响到本层或者临接的上层。

层次逻辑结构非常便于移植。越是上层，越是应用相关，反之则越是平台相关。一个分层的结构易于双向的可移植性。应用变得更容易移植，因为底层能容易的被相似的平台层次所替换。同时，上层也能容易的被其他平台的应用所替换。

 

1.6.实现策略

分层结构的实现是非常直接的。层与层之间的依赖是存在的，最重要的是它们的关系最终是单方向的C/S关系（同层和同层与紧临接的下层）。最关键的是，层与层之间的关系是单向的，这使得消息可以从上层传递到下层，反之，则不行。底层的抽象不依赖于使用它们的上层。