這個系列，結合IDEA的Inspection和我自己的理解編寫。

抽象問題

1. 把實例造型（cast）成具體的類型

這個問題的含義是，當得到一個實例時，把它cast到一個更加具體的類型使用。這個問題存在于以下場景：

• 出于個人原因，比如只熟悉這個具體的類型、不動腦筋的編碼。

這是新手常見的問題。比如可能程序員只熟悉ArrayList，并不知道其上的更加抽象的接口；或者個人感覺ArrayList更加“好用”。這是不應該出現的問題，有經驗的程序員應該指導初學者，避免犯錯。

• 需要的方法不在更抽象的類型中，只在具體類型中才有定義。

這個問題更多的表示了設計層面考慮的不充分。比如組織本身的代碼（非外來代碼），接口定義的類型不能滿足接口實現者的具體需求；返回值的類型過于泛化；本地變量（Local variable）定義的類型過于泛化等等。這些問題一般意味著在設計上考慮不周，導致了對象交互過程中的“對接不順利”，這是設計上的不一致，需要對設計進行仔細評估。以下是幾個這樣的例子：

public Collection aMethod(Collection c) {
  List list = (List)c;
  Object o = list.get(0); // Collection中沒有get方法。導致實現者必須cast。
  ...
}

public void test() {
  // 返回值必須cast才能使用更加具體的方法。
  List alist = (List)aMethod(Arrays.asList(new String[]{"1", "2"}));
  Object obj = alist.get(0);
  ...
}

public someMethod() {
  MyInterface mi = new MyImplementation();
  ...
  // 大部分時間調用MyInterface中的方法，但忽然發現有某個地方需要調用特定的非接口實現：
  int count = ((MyImplementation)mi).specialMethod();
  ...
}

最后這個例子，可能是方法的實現本身的問題，比如完全可以直接使用MyImplementation來定義變量mi；也可能是抽象問題，即沒有把本來具有普遍性的方法放到接口中，而是放到了具體實現中。

• 受環境約束，必須安全的使用造型。

上面談到的設計問題，是指的組織內部的設計。在很多時候，需要使用外部的接口和實現，這些接口因為考慮了更加廣泛的使用環境而采用了更加泛化的接口。這就需要順應已經存在的設計來實現，不得不使用cast。但同時也要注意，在不得不cast的時候，一定要安全的使用cast，比如安全檢查或者安全的類型轉換，下面是示例：

public boolean equals(Object o) {
  if (o == null) return false;
  if (o instanceof MyClass) { // 安全檢查！
    MyClass mc = (MyClass)o;
    // 調用MyClass中的特定方法。
    ...
}

public method() {
  Collection c = aMethodReturnsCollection();
  List list = new ArrayList(c); //安全的類型轉換，把Collection轉換成List。
  ...
}

Coding, issue, abstract, cast