Adapter設計模式,容許客戶端使用接口不兼容的類。java
昨天收拾一些之前的東西,發現了藏在櫃子裏的一條線,這條線叫作OTG。這條線的一端是micro-usb的輸出口,另外一端是usb的輸入口。這條線,就是Adapter。手機若是想要使用U盤,會發現這個U盤的usb輸出口太大了,根本插不進手機的接口。怎麼辦呢?使用適配器就好!android
只要手機插上OTG,U盤再接上OTG,這樣手機就能夠歡快地使用U盤啦。設計模式
這是硬件的適配器,手機做爲客戶端,本來不能使用接口不兼容的U盤。手機只認它能認的接口,micro-usb也好,type-c也好,只要是同一個接口,它都認。OTG做爲適配器,它要有一端,能讓手機認識,還要有另外一端能接受它想認得的東西(U盤)。數組
在軟件開發中,OTG能給咱們帶來什麼啓示呢?dom
1, 手機認得OTG的一端。ide
明確客戶端須要的類,讓Adapter去繼承/實現客戶端須要的類,這樣客戶端就能認Adapter了。ui
2, OTG能認到U盤。設計
Adapter能獲取到被適配對象的信息,方法有二:在Adapter中放置一個對象;讓Adapter繼承被適配類。code
3, 手機經過OTG讀取U盤的信息。對象
Adapter須要爲客戶端實現特定的調用,讓其能夠操做被適配對象。
Java中Arrays.asList()返回一個適配器。
客戶端能使用的是List
Arrays實現了一個內部類ArrayList,這個有別於java.util.ArrayList,Arrays.ArrayList不能對List進行add,remove等操做。這麼作能夠保證數據的一致性,在數組中作出的修改,在Adapter中對應作出修改。同時還節省空間/時間,不須要新建一個數組,由於Arrays.ArrayList內部存儲了一個指向這個數組的成員,既不須要開闢新的空間,又不須要複製操做。
用Adapter設計模式來看,List
如下代碼去掉了Arrays.ArrayList的部分實現:
@SafeVarargs @SuppressWarnings("varargs") public static <T> List<T> asList(T... a) { return new ArrayList<>(a); } private static class ArrayList<E> extends AbstractList<E> implements RandomAccess, java.io.Serializable { private static final long serialVersionUID = -2764017481108945198L; private final E[] a; ArrayList(E[] array) { a = Objects.requireNonNull(array); } @Override public E get(int index) { return a[index]; } @Override public E set(int index, E element) { E oldValue = a[index]; a[index] = element; return oldValue; } ... }
安卓中使用的Adapter符合Adapter設計模式嗎?好比Adapter,ListAdapter,ArrayAdapter。
不是。正如[1]中所指出的
There are plenty of classes in the world named similarly to GoF that have nothing to do with those patterns
雖然名字是XXXAdapter,實際上它扮演的更像是MVP中的Presenter。其中還使用了觀察者的設計模式。想要自定義ListView的item樣式,能夠使用這個Adapter,它會幫你處理數據,幫你處理View。這裏Adapter的做用是:讓模型adapt視圖。