优先使用组合而不使用继承

Java是一个面向对象的语言。封装、继承、多态是面向对象的三个特征。不管是学习还是工作的时候可能在需要复用的情况下，第一个想到的词汇就是：继承。但是其实在设计模式中，发现组合是一种很好复用方式，它适用于大部分我们需要复用的情况，所以优先使用组合而不使用继承。

继承

继承（Inheritance）是一种联结类与类的层次模型。指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；继承是一种is-a关系。（图片来自网络，侵删。）

组合

组合(Composition)是一种较弱的关系，体现的是整体与部分、拥有的关系，即has-a的关系。

组合和继承的区别

• 在继承结构中，父类的内部细节对于子类是可见的。所以我们通常也可以说通过继承的代码复用是一种白盒式代码复用。如果基类的实现发生改变，那么派生类的实现也将随之改变。这样就导致了子类行为的不可预知性；）
• 组合是通过对现有的对象进行拼装（组合）产生新的、更复杂的功能。因为在对象之间，各自的内部细节是不可见的，所以我们也说这种方式的代码复用是黑盒式代码复用。（因为组合中一般都定义一个类型，所以在编译期根本不知道具体会调用哪个实现类的方法）
• 继承，在写代码的时候就要指名具体继承哪个类，所以，在编译期就确定了关系。（从基类继承来的实现是无法在运行期动态改变的，因此降低了应用的灵活性。）
• 组合，在写代码的时候可以采用面向接口编程。所以，类的组合关系一般在运行期确定。

代码说明

现在我们需要这样一个HashMap，它除了能按常规的Map那样取值，如get(Object obj)。还能按位取值，像ArrayList那样，按存入对象对的先后顺序取值。
对于这样一个问题，我们首先想到的是做一个类，它继承了HashMap类，然后用一个ArrayList属性来保存存入的key，我们按key的位来取值，代码如下：

public class ListMap extends HashMap {  
private List list;  
public ListMap() {  
         super();  
          this.list = new ArrayList();  
}  
public Object put(Object key,Object value)  
{  
         if(list.contains(key))  
          {  
                 list.remove(key);  
          }  
         this.list.add(key);  
          return super.put(key,value);  
}  
public Object getKey(int i)  
{  
          return this.list.get(i);  
}  
public Object getValue(int i)  
{  
          return this.get(getKey(i));  
}  
public int size()  
{  
          return this.list.size();  
}  
}  
这个ListMap类对HashMap作了一定的扩展，很简单就实现了上面我们所要求的功能。然后我们对该类做一下测试：  
ListMap map = new ListMap();  
         map.put("a","111");  
         map.put("v","190");  
         map.put("d","132");  
          for(int i=0;i

测试结果为：
111
190
132
正是我们所需要看到的结果。如此说来，这个ListMap类就可以放心的使用了吗？有实现了这样功能的类，你的同事或朋友也可能把这个类拿来使用一下，他可能写出来如下的代码：

ListMap map = new ListMap();  
         map.put("a","111");  
         map.put("v","190");  
         map.put("d","132");  
         String[] list = (String[])map.values().toArray(new String[0]);  
          for(int i=0;i<list.length;i++)  
          {  
                 System.out.println(list[i]);  
          }  

运行的结果如下：
132
111
190
哎哟，怎么回事啊？与上面的顺序不对了。你朋友过来找你，说你写的代码怎么不对啊？你很吃惊，说把代码给我看看。于是你看到了上面的代码。你大骂道，混蛋，怎么不是用我的getValue方法啊？你朋友搔搔头道，values方法不是一样的吗？你也没告诉我不能用啊？
通过上面的例子，我们看到了继承的第一个危害：继承不分青红皂白的把父类的公有和受保护的方法统统继承下来。如果你的子类没有对一些方法重写，就 会对你的子类产生危害。上面的ListMap类，你没有重写继承自HashMap类的values方法，而该方法仍然是按HashMap的方式取值，没有 先后顺序。这时候，如果在ListMap类的对象里使用该方法取得的值，就没有实现我们上面的要求。
接上面的那个例子，你听了朋友的抱怨，摇摇头，想想也是，不能怪他。你只得把values方法在ListMap类重写一遍，然后又嘀咕着，我是不是该把HashMap类的公有方法在ListMap类里全部重写？很多方法根本没有必要用到啊？……
对了，很多方法在ListMap里根本不必用到，但是你用继承的话，还不得不在ListMap里重写它们。如果用组合的话，就没有上面的烦恼了：

public class MyListMap {  
private HashMap map;  
private List list;  
public MyListMap()  
{  
         this.map = new HashMap();  
          this.list = new ArrayList();  
}  
public Object put(Object key,Object value)  
{  
         if(list.contains(key))  
          {  
                 list.remove(key);  
          }  
         this.list.add(key);  
          return this.map.put(key,value);  
}  
public Object getKey(int i)  
{  
          return this.list.get(i);  
}  
public Object getValue(int i)  
{  
          return this.map.get(getKey(i));  
}  
public int size()  
{  
          return this.list.size();  
}  
}  

这样，你的朋友就只能使用你的getKey和getValue方法了。如果他向你抱怨没有values方法，你尽可以满足他的要求，给他添加上那个方法，而不必担心可能还有方法没有被重写了。
我们来看Adapter模式，该模式的目的十分简单：我手里握有一些实现了WhatIHave接口的实现，可我觉得这些实现的功能不够用，我还需要从Resource类里取一些功能来为我所用。Adapter模式的解决方法如下：

public interface WhatIHave  
{  
          public void g();  
}  
public class Resource  
{  
          public void f()  
          {  
               ……  
          }  
          public void h()  
          {  
               ……  
          }  
}  

上面是两个基础类，很明显，我们所要的类既要有g()方法，也要有f()和h()方法。

Public class WhatIWant implements WhatIHave  
{  
          private Resource res;  
          public WhatIWant()  
          {  
                 res = new Resource();  
}  
public void g()  
{  
       ……  
}  
public void f()  
{  
         this.res.f();  
}  
public void h()  
{  
         this.res.h();  
}  
} 

上 面就是一个Adapter模式最简单的解决问题的思路。我们主要到，对于Resource类，该模式使用的是组合，而不是继承。这样使用是有多个原因：第 一，Java不支持多重继承，如果需要使用好几个不同的Resource类，则继承解决不了问题。第二，如果Resource类还有一个方法：k()，我 们在WhatIWant类里使用不上的话，继承就给我们造成多余方法的问题了。
如果说Adapter模式对组合的应用的目的十分简单明确，那么Decorator模式对组合的应用简直就是令人叫绝。
让我们还是从Decorator模式的最佳例子说起，咖啡店需要售卖各种各样的咖啡：黑咖啡、加糖、加冰、加奶、加巧克力等等。顾客要买咖啡，他可以往咖啡任意的一种或几种产品。
这个问题一提出来，我们最容易想到的是继承。比如说加糖咖啡是一种咖啡，满足ia a的句式，很明显，加糖咖啡是咖啡的一个子类。于是，我们马上可以赋之行动。对于咖啡我们做一个咖啡类：Coffee，咖啡加 糖：SugarCoffee，咖啡加冰：IceCoffee，咖啡加奶：MilkCoffee，咖啡加巧克力：ChocolateCoffee，咖啡加糖 加冰：SugarIceCoffee……
哎哟，我们发现问题了：这样下去我们的类好多啊。可是咖啡店的老板还不放过我们，他又逼着我们增加蒸汽咖啡、加压咖啡，结果我们发现，每增加一种新的类型，我们的类好像是成几何级数增加，我们都要疯了。
这个例子向我们展示了继承的第二个缺点，会使得我们的子类快速的膨胀下去，达到惊人的数量。
怎么办？我们的Decorator模式找到了组合来为我们解决问题。下面我们来看看Decorator模式是怎么来解决这个问题的。
首先是它们的共同接口：

package decorator;  

interface Product {  
public double money();  
}  

//咖啡类：  
class Coffee implements Product {  
public double money() {  
    return 12;  
}  
}  

//加糖：  
class Sugar implements Product {  
private Product product;  

public Sugar(Product product) {  
    this.product = product;  
}  

public double money() {  
    return product.money() + 2;  
}  
}  

//加冰：  
class Ice implements Product {  
private Product product;  

public Ice(Product product) {  
    this.product = product;  
}  

public double money() {  
    return product.money() + 1.5;  
}  
}  

//加奶：  
class Milk implements Product {  
private Product product;  

public Milk(Product product) {  
    this.product = product;  
}  

public double money() {  
    return product.money() + 4.0;  
}  
}  

//加巧克力：  
class Chocolate implements Product {  
private Product product;  

public Chocolate(Product product) {  
    this.product = product;  
}  

public double money() {  
    return product.money() + 5.5;  
}  
}  
public class DecoratorModel{  
public static void main(String [] args){  
    Product coffee = new Coffee();  
    Product sugarCoffee = new Sugar(coffee);  
    Product sugarmilkCoffee = new Milk(sugarCoffee);  
    System.out.println("加糖咖啡："+sugarCoffee.money());  
    System.out.println("加糖加奶咖啡："+sugarmilkCoffee.money());  
}  
}  

我们来看客户端的调用。
如果顾客想要黑咖啡，调用如下：
Product prod = new Coffee();
System.out.println(prod.money());
如果顾客需要加冰咖啡，调用如下：
Product prod = new Ice(new Coffee());
System.out.println(prod.money());
如果顾客想要加糖加冰加奶加巧克力咖啡，调用如下：
Product prod = new Chocolate(new Milk(new Ice(new Sugar())));
System.out.println(prod.money());
通过上面的例子，我们可以看到组合的又一个很优越的好处：能够在运行期创建新的对象。如上面我们的加冰咖啡，我们没有这个类，却能通过组合在运行期创建该对象，这的确大大的增加了我们程序的灵活性。
如果咖啡店的老板再要求你增加加压咖啡，你就不会再担心了，只给他增加了一个类就解决了所有的问题。

优缺点对比

组 合 关 系	继 承 关 系
优点：不破坏封装，整体类与局部类之间松耦合，彼此相对独立	缺点：破坏封装，子类与父类之间紧密耦合，子类依赖于父类的实现，子类缺乏独立性
优点：具有较好的可扩展性	缺点：支持扩展，但是往往以增加系统结构的复杂度为代价
优点：支持动态组合。在运行时，整体对象可以选择不同类型的局部对象	缺点：不支持动态继承。在运行时，子类无法选择不同的父类
优点：整体类可以对局部类进行包装，封装局部类的接口，提供新的接口	缺点：子类不能改变父类的接口
缺点：整体类不能自动获得和局部类同样的接口	优点：子类能自动继承父类的接口
缺点：创建整体类的对象时，需要创建所有局部类的对象	优点：创建子类的对象时，无须创建父类的对象

总结

相信通过代码例子的方式，我们得知为何组合优先于继承，或者说多用组合少用继承，因为组合确实比继承更加灵活，也更有助于代码维护。那么继承是否就一无是处，也不见得。

在面向对象的程序设计中，创建和使用代码最可能采取的一种做法是：将数据和方法统一封装到一个类里，并且使用那个类的对象。有些时候，需通过“合成”技术用现成的类来构造新类。而继承是最少见的一种做法。因此，尽管继承在学习OOP的过程中得到了大量的强调，但并不意味着应该尽可能地到处使用它。相反，使用它时要特别慎重。只有在清楚知道继承在所有方法中最有效的前提下，才可考虑它。为判断自己到底应该选用合成还是继承，一个最简单的办法就是考虑是否需要从新类上溯造型回基础类。若必须上溯，就需要继承。但如果不需要上溯造型，就应提醒自己防止继承的滥用。《Java编程思想》