面向接口编程

在前面的章节中，我们提到一个接口设计的例子。为什么我们提倡接口的设计呢？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 ();
}

可以看到，为了表示现实世界中人（这里其实指的是员工的概念）、工程师、销售员、经理的概念，代码根据人的自然观点设计了继承层次结构，并很好的实现了重用。而且，我们可以认定该接口是相对稳定的。我们再来看看实现部分：


public class PersonImpFlag implements Person, Salesman, Engineer,Manager{
// Implementing Salesman
public static Salesman newSalesman (String name){
  PersonImpFlag result;
  result = new PersonImpFlag (name);
  result.makeSalesman();
  return result;
};
public void makeSalesman () {
  _jobTitle = 1;
};
public boolean isSalesman () {
  return _jobTitle == 1;
};
public void numberOfSales (int value){
  requireIsSalesman () ;
  _numberOfSales = value;
};
public int numberOfSales () {
  requireIsSalesman ();
  return _numberOfSales;
};
private void requireIsSalesman () {
  if (! isSalesman()) throw new PreconditionViolation ("Not a Salesman") ;
};
  private int _numberOfSales;
  private int _jobTitle;
}

这是其中一种被称为内部标示（Internal Flag）的实现方法。这里我们只是举出一个例子，实际上我们还有非常多的解决方法，但我们并不关心。因为只要接口足够稳定，内部实现发生再大的变化都是允许的。如果对实现的方式感兴趣，可以参考Matrin Fowler的角色建模的文章或是我在阅读这篇文章的一篇笔记。

通过上面的例子，我们可以了解到，接口和实现分离的最大好处就是能够在客户端未知的情况下修改实现代码。这个特性对于分层技术是非常适用的。一种是用在层和层之间的调用。层和层之间是最忌讳耦合度过高或是改变过于频繁的。设计优秀的接口能够解决这个问题。另一种是用在那些不稳定的部分上。如果某些需求的变化性很大，那么定义接口也是一种解决之道。举个不恰当的例子，设计良好的接口就像是我们日常使用的万用插座一样，不论插头如何变化，都可以使用。

最后强调一点，良好的接口定义一定是来自于需求的，它绝对不是程序员绞尽脑汁想出来的。