常用8種設計模式最後三個:介面卡模式、合成模式、訪問者模式    -----文章部落格園整理而來，尊重原創

對於android開發者來說起，介面卡模式簡直太熟悉不過，有很多應用可以說是天天在直接或者間接的用到介面卡模式，比如ListView。
ListView用於顯示列表資料，但是作為列表資料集合有很多形式，有Array，有Cursor，我們需要對應的介面卡作為橋樑，處理相應的資料（並能形成ListView所需要的檢視）。
正是因為定義了這些介面卡介面和介面卡類，才能使我們的資料簡單靈活而又正確的顯示到了adapterview的實現類上。
介面卡模式，Adapter Pattern，勇敢的去適配，大量的資源可以重用。

1.意圖

介面卡模式，把一個類的介面變換成客戶端所期待的另一種介面，從而使原本不匹配而無法在一起工作的兩個，類能夠在一起工作。

介面卡模式分為類介面卡模式和物件介面卡模式。
關於類介面卡模式，因為java的單繼承，如果繼承一個類，另外的則只能是介面，需要手動實現相應的方法。
熱門詞彙：類的介面卡模式 物件的介面卡模式 預設介面卡模式 源類 目標介面

2.結構圖和程式碼


為了簡明直接，我省略了相關的其他介面卡 ，只以此兩個介面卡為例。
ListViews做為client，他所需要的目標介面(target interface)就是ListAdapter，包含getCount(),getItem(),getView()等幾個基本的方法，為了相容List<T>,Cursor等資料型別作為資料來源，我們專門定義兩個介面卡來適配他們：ArrayAdapter和CursorAdapter。這兩個介面卡，說白了，就是針對目標介面對資料來源進行相容修飾。
這就是介面卡模式。
其中BaseAdapter實現瞭如isEmpty()方法,使子類在繼承BaseAdapter後不需要再實現此方法，這就是預設介面卡，這也是預設介面卡的一個最明顯的好處。 
我們以最簡單的若干個方法舉例如下，ListAdapter介面如下（，為了簡單，我省略了繼承自Adapter介面）：

public interface ListAdapter {
    public int getCount();
    Object getItem(int position);
    long getItemId(int position);
    View getView(int position, View convertView, ViewGroup parent);
    boolean isEmpty();
}

抽象類BaseAdapter,我省略其他程式碼，只列出兩個方法，以作示意:

public abstract class BaseAdapter implements ListAdapter, SpinnerAdapter {
    // ... ...
    public View getDropDownView(int position, View convertView, ViewGroup parent) {
        return getView(position, convertView, parent);
    }
    public boolean isEmpty() {
        return getCount() == 0;
    }
}
 

ArrayAdapter對List<T>進行封裝成ListAdapter的實現，滿足ListView的呼叫：

public class ArrayAdapter<T> extends BaseAdapter implements Filterable {
    private List<T> mObjects;
    //我只列出這一個建構函式，大家懂這個意思就行
    public ArrayAdapter(Context context, int textViewResourceId, T[] objects) {
        init(context, textViewResourceId, 0, Arrays.asList(objects));
    }
    private void init(Context context, int resource, int textViewResourceId, List<T> objects) {
        mContext = context;
        mInflater = (LayoutInflater)context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
        mResource = mDropDownResource = resource;
        mObjects = objects; //引用物件，也是表達了組合優於繼承的意思
        mFieldId = textViewResourceId;
    }
    public int getCount() {
        return mObjects.size();
    }
   public T getItem(int position) {
        return mObjects.get(position);
    }
    public View getView(int position, View convertView, ViewGroup parent) {
        return createViewFromResource(position, convertView, parent, mResource);
    }
    // ... ...
}

我們就如此成功的把List<T>作為資料來源以ListView想要的目標介面的樣子傳給了ListView，同理CursorAdapter也是一模一樣的道理，就不寫具體程式碼了。
    介面卡本身倒是不難，但是提供瞭解決不相容問題的慣用模式。 
    關於什麼時候使用介面卡模式,大概有三種情況：
    (1). 你想使用一個已經存在的類，而它的介面不符合你的需求，這個在處理舊系統時比較常見。
    (2). 你想建立一個可以複用的類，該類可以和其他不相關的類或不可預見的累協同工作，這就是我們android開發者經常碰到的情況：我們常常自定義一個新的Adapter。
    (3). 你想使用一些已經存在的子類，但是不可能對每一個都進行子類化以匹配他們的介面，物件介面卡可以適配他的父類介面。 

3.效果
1. 結構性模式 
2. 上面論述的主要是物件介面卡，關於類介面卡除了實現目標埠外，還要實現你要相容的源類，
這樣可以少寫幾行程式碼，但是從組合優於繼承的角度看，它總則沒有那麼的乾淨。
3. 對同一個介面卡（即同一個物件）對同樣的源進行雙向甚至多向的適配，則能使其適用兩個甚至多個客戶呼叫。


Android中對組合(合成)模式的應用，可謂是氾濫成粥，隨處可見，那就是View和ViewGroup類的使用。在android UI設計，幾乎所有的widget和佈局類都依靠這兩個類。
組合模式，Composite Pattern，是一個非常巧妙的模式。幾乎所有的面向物件系統都應用到了組合模式。


1.意圖
將物件View和ViewGroup組合成樹形結構以表示"部分-整體"的層次結構(View可以做為ViewGroup的一部分)。
組合模式使得使用者對單個物件View和組合物件ViewGroup的使用具有一致性。
熱點詞彙: 部分-整體 容器-內容 樹形結構 一致性 葉子 合成 安全性 透明性

2.結構

針對View和ViewGroup的實際情況，我們選擇安全式的組合模式(在組合物件中新增add,remove,getChild方法)，新增少許的註釋，我們把上圖修改為：

3.程式碼
View類的實現：

public class View{ 
        //... ... 
       //省略了無關的方法 
 
} 

ViewGroup的實現：

public abstract class ViewGroup extends View{ 
 
    /** 
   * Adds a child view.  
 
    */ 
 
   public void addView(View child) { 
 
       //... 
 
    } 
   public void removeView(View view) { 
 
        //... 
 
    } 
   /** 
 
     * Returns the view at the specified position in the group. 
 
    */ 
   public View getChildAt(int index) { 
 
       try { 
 
           return mChildren[index]; 
 
      } catch (IndexOutOfBoundsException ex) { 
          return null; 
 
      } 
   } 
  
    //other methods 
 
} 

4.效果 (1).結構型模式
(2).定義了包含基本物件和組合物件的類層次結構。這種結構能夠靈活控制基本物件與組合物件的使用。
(3).簡化客戶程式碼。基本物件和組合物件有一致性，使用者不用區分它們。
(4).使得更容易新增新型別的元件。

(5).使你的設計變得更加一般化。

訪問者模式請參看