另一种分层方法是利用继承：

    该图中也是来自于分析模式一书。不同的部门有着差异点和共性，将共性提取到父类中是继承的基本概念。这时候我们可以把父类看作是较低的层次，而把子类看作是较高的层次。对于一组层次结构很深的类来说，也可以从某一个水平线上分离层次。

    最后一种方法需要分解并抽象对象的行为。C++的STL中为不同的数据类型和不同的容器实现了Iterator的功能。它的实现是典型的降低层次的行为。我们不考虑它对不同数据类型的支持，因为它使用了比较独特的模板(Template)技术，只考虑它对不同的容器的实现。首先是对共性的分析，不论是数组(Array)还是向量(Vector)，要执行遍历操作，都需要知道三个条件：容器的起始点、容器的长度、匹配值。这就是一种抽象。通过这种方式，就可以统一不同容器的接口。

    以上我们讨论了细分层次的好处和实现策略。下面我们回到前例中，继续讨论层中的各个部件。

    业务实体指的是企业中的一些单独的对象。例如订单、客户、供应商等。由于业务实体可以被很多的业务流程(业务会话)所使用，因此我们把业务实体放在业务实体层中。企业中的业务实体大多是需要持久性的。因此在我们的设计中，业务实体将持久性的职责委托给下一个层次中的持久性包，而不是直接调用数据库方法。另一种常用的方法是使用继承――业务实体继承自持久类。EJB中的Entity Bean就是典型的业务实体，它可以支持自动的持久性机制。

    在我们的系统中，规则是一个尴尬的存在。部分的规则处于旧系统中，并使用旧系统的持久性机制。而新系统中有需要支持新的规则。对于上层的用户来说，并不需要知道新旧系统的规则。如果我们在使用规则时做一个新旧规则的判断并调用不同的系统函数，那就显得太傻了。我们的设计对上层而言应该是透明的。

    所以我们总共设计了三个包来实现规则的处理。包装器包装了旧系统中的规则，这样做处于几点考虑：首先，旧系统是面向过程的，因此我们需要用包装器将函数(或过程)封装到类中。其次，对旧系统的使用需要额外的程序(或平台服务)的支持，因此需要单独的类来处理。最后，我们可以使用Adapter模式[GOF 94]将新旧系统不同的接口给统一起来，以使他们能够一起工作。新的规则类实现了新的规则，较好的做法是定义一个虚协议，具体的表现形式可以是虚基类或接口。然后由其子类实现虚协议。再结合前面介绍的把旧规则的接口转换为新的接口的方法，就能够统一规则接口。从图中我们看到，业务实体需要使用规则，通过统一的接口，业务实体就能够透明的使用新旧两种规则。

    在定义了规则和标准的规则接口之后，上一层的规则控制器就可以通过调用规则，来实现不同规则组合。因此这个规则控制器就类似于应用规则。在业务交易处理中需要调用规则控制器来实现部分的功能。

    请注意，这里讨论的思路虽然非常的简单、清晰，但是现实中的处理却没有这么容易。因为为新旧规则制定统一的接口实在是太难了。要能够使接口在未来也相对的稳定更是难上加难。而在应用已经部署之后，对已发布的接口的任何一个小改动都意味着很高的成本。在这个问题上，并没有什么好的策略，经验是最重要的。在实际中的一个比较实用的方法是为接口增加一些额外的参数。即便可能这个参数当前并没有使用到，但是如果为了有可能使用的话，那还是加上吧。举个例子，对于商业应用软件而言，数据库，或者说是关系数据库一定是不可缺少的部分。大量的操作都需要和数据库结合起来，因此，可以考虑在方法中加入一个数据库连接字符串的参数。虽然这对于很多方法而言是没什么必要的，但是为将来的实践提供了一个可扩展的空间。国内的某个知名的ERP软件的设计就采用了这种思路。

    本章的主要精力都放在实例的研究上，在有了一个基本的概念之后，我们再回来谈谈分层的一些原则和需要注意的问题。

    (待续)