2. instanceof檢查鏈

這個問題是連續使用if ... else + instanceof檢查來判斷一個對象的類型，并采取不同的處理邏輯。示例代碼如下：

public void method(Fruit fruit) {
  if (fruit instanceof Apple) {
    ...
  }
  else if (fruit instanceof Orange) {
    ...
  }
  else if .....
}

這不是面向對象的方法，完全沒有利用到多態的面向對象特性。我相信一個合格的程序員是不會寫出這樣的編碼的，這一般是新手程序員，特別是對面向對象理解不深刻的程序員會犯的毛病。改正的方法就是在Fruit類中增加一個方法，并在Apple、Orange等子類中實現此方法：

public abstract class Fruit {
  public int m();
}

當然，在環境允許的情況下，盡可能使用protected而不是public來定義這個方法。

現在我們來看一個復雜一點的，同樣還是instanceof檢查的問題，但這個檢查只涉及了Fruit諸多子類中的一部分，而其他的子類，行為是一致的。這時候我們需要在Fruit中引入一致行為的實現：

public abstract class Fruit {
  public int m() {
    //一般的實現。
    ...
  }
}

而更加復雜的行為需要對應復雜的設計，通過對具體水果的抽象，可以發現這些水果可以抽象為幾個較為一般的類：

public abstract class Fruit {
  public int m(){
    ...
  }
}

public class TypeAFruit extends Fruit {
  public int m(){
    //特定類型的實現。
  }
}

public class TypeBFruit extends Fruit {
  public int m(){
    // 特定類型的實現。
  }
}

...

關于類的繼承層次的問題，有一種說法是“原則上”控制在一定的數量之內。一般來說 這個說法是有道理的（特別是對初學者，它可以有效的避免“濫繼承”），但不是放之四海皆準的道理，不要把它教條化。

說到繼承層次，不得不提到抽象層次。我們總是在一定的抽象層次上解決問題，抽象層次決定了你解決問題的實現的復雜程度。設計以簡潔為美，不要把設計復雜化。但簡潔并不意味著“少”，簡潔的真正涵義是：模型不比模型所表達的事物更加復雜，不要把“本來簡單”的東西復雜化，也不要把本來復雜的東西簡單化。

我所要表達的是，設計應該是簡潔的，但不是“簡單”的。“設計應該簡單”的說法，是來自翻譯的問題，還是來自理解的問題？簡單會導向“偷工減料”，而簡潔則要求不要在設計中加料（特別是廢料）。

一個繼承結構有多少層才是合適的？最上層的類或接口對應著“一般概念”，最下層的類一定可以實例化為具體的對象，這中間有多少“層”，就有多少抽象層次。決定抽象層次，也就是決定你的繼承層次的原則有二：

• 客戶代碼的需要：客戶代碼是指調用你的類繼承層次中的某些類的代碼，客戶代碼需要知道某個層次的細節。此外需要注意的是，客戶代碼應該盡量使用最上層的“一般概念”。
• 重用的需要：在具體的不同類中存在相同代碼的時候，就要考慮有沒有可能進行抽象，形成一個用于重用目的的父類。

類繼承層次的設計也不是一成不變的，按照上面這兩個原則，當客戶代碼不再需要某個層次時，或者當重用代碼不可能（一般標志就是大量的override）時，就要考慮改變繼承體系的設計。


汗，感覺后面有點越扯越遠了。。。

instanceof, inheritance, abstraction