层内的细分

    分层的思路还可以适用于层的内部。层内的细分并没有固定的方式，其驱动因素往往是出于封装性和重用的考虑。例如，在EJB体系中的业务层中，实体Bean负责实现业务对象，因此一个应用往往拥有大量的实体Bean。而用户端并不需要了解每一个的实体Bean，对它们来说，只要能够完全一些业务逻辑就可以了，但完成这些业务逻辑则需要和多个实体Bean打交道。因此EJB提供了会话Bean，来负责把实体Bean封装起来，用户只知道会话Bean，不知道实体Bean的存在。这样既保证了实体Bean的重用性，又很好的实现了封装。

    面向接口编程

    在前面的章节中，我们提到一个接口设计的例子。为什么我们提倡接口的设计呢？Martin Fowler在他的分析模式一书中指出，分析问题应该站在概念的层次上，而不是站在实现的层次上。什么叫做概念的层次呢？简单的说就是分析对象该做什么，而不是分析对象怎么做。前者属于分析的阶段，后者属于设计甚至是实现的阶段。在需求工程中有一种称为CRC卡片的玩艺儿，是用来分析类的职责和关系的，其实那种方法就是从概念层次上进行面向对象设计。因此，如果要从概念层次上进行分析，这就要求你从领域专家的角度来看待程序是如何表示现实世界中的概念的。下面的这句话有些拗口，从实现的角度上来说，概念层次对应于合同，合同的实现形式包括接口和基类。简单的说吧，在概念层次上进行分析就是设计出接口（或是基类），而不用关心具体的接口实现（实现推迟到子类再实现）。结合上面的论述，我们也可以这样推断，接口应该是要符合现实世界的观念的。

    在Martin Fowler的另一篇著作中提到了这样一个例子，非常好的解释了接口编程的思路：

    interface Person {

    public String name();

    public void name(String newName);

    public Money salary ();

    public void salary (Money newSalary);

    public Money payAmount ();

    public void makeManager ();

    }

    interface Engineer extends Person{

    public void numberOfPatents (int value);

    public int numberOfPatents ();

    }

    interface Salesman extends Person{

    public void numberOfSales (int numberOfSales);

    public int numberOfSales ();

    }

    interface Manager extends Person{

    public void budget (Money value);

    public Money budget ();

    }