面向對象的六大原則
- 單一職責原則
- 開閉原則, 對于擴展開放, 對于修改封閉
- 里氏替換原則, 所有引用基類的地方必須能透明地使用其子類對象(抽象類)
- 依賴倒置原則, 解耦(高層次的模塊不依賴于低層次的模塊實現)
- 接口隔離原則, 拆分接口
- 迪米特原則, 一個對象對其他對象應該有最少的了解
設計模式
- 代理模式
- 單例模式
- Builder模式
- 原型模式
- 工廠模式
- 抽象工廠模式
- 策略模式
- 狀態模式
- 責任鏈模式
- 解釋器模式
- 命令模式
- 觀察者模式
- 備忘錄模式
- 迭代器模式
- 模板方法模式
- 訪問者模式
- 中介者模式
- 組合模式
- 適配器模式
- 裝飾模式
- 享元模式
- 外觀模式
- 橋接模式
- MVC, MVP, MPPM
代理模式
代理模式就是給某一個對象提供一個代理對象，并由代理對象控制對源對象的引用。就是一個人或者一個機構代替另一個人或者另一個機構去采取一些行動，以控制對這個對象的訪問。
所謂代理，是指具有與代理元（被代理的對象）具有相同的接口的類，客戶端必須通過代理與被代理的目標類交互，而代理一般在交互的過程中（交互前后），進行某些特別的處理。
代理模式分為8種, ActivityManagerNative 用到的是 Remote 代理, 外界通過ActivityManagerNative.getDefault();方法創建 IActivityManager 的實現, 而 ActivityManagerNative 和 ActivityManagerProxy 都在 ActivityManagerNative.java文件中
public abstract class ActivityManagerNative extends Binder implements IActivityManager{
static public IActivityManager asInterface(IBinder obj) {
if (obj == null) {
return null;
}
IActivityManager in =
(IActivityManager)obj.queryLocalInterface(descriptor);
if (in != null) {
return in;
}
return new ActivityManagerProxy(obj);
}
static public IActivityManager getDefault() {
return gDefault.get();
}
private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
protected IActivityManager create() {
IBinder b = ServiceManager.getService("activity");
if (false) {
Log.v("ActivityManager", "default service binder = " + b);
}
IActivityManager am = asInterface(b);
if (false) {
Log.v("ActivityManager", "default service = " + am);
}
return am;
}
};
}
class ActivityManagerProxy implements IActivityManager{
public ActivityManagerProxy(IBinder remote)
{
mRemote = remote;
}
public IBinder asBinder()
{
return mRemote;
}
}
單例模式
Builder模式
類似AlertDialog.builder
public class MyBuilder{
private int id;
private String num;
public MyData build(){
MyData d=new MyData();
d.setId(id);
d.setNum(num);
return t;
}
public MyBuilder setId(int id){
this.id=id;
return this;
}
public MyBuilder setNum(String num){
this.num=num;
return this;
}
}
public class Test{
public static void main(String[] args){
MyData d=new MyBuilder().setId(10).setNum("hc").build();
}
}
工廠模式
根據傳入的參數決定產生的是什么對象
public Object getSystemService(String name) {
if (getBaseContext() == null) {
throw new IllegalStateException("System services not available to Activities before onCreate()");
}
//........
if (WINDOW_SERVICE.equals(name)) {
return mWindowManager;
} else if (SEARCH_SERVICE.equals(name)) {
ensureSearchManager();
return mSearchManager;
}
//.......
return super.getSystemService(name);
}
抽象工廠模式
public class BaseService extends Service{
@Nullable
@Override
public IBinder onBind(Intent intent){
return new Binder();
}
}
策略模式
屬性動畫的插值器, 可以從一個方法中實現很多種
狀態模式
wifi 行為由狀態決定, 不同狀態啟動不同方法
責任鏈模式
點擊事件的傳遞
解釋器模式
AndroidManifest.xml 中對<Activity>, <Service>的解析
命令模式
事件傳遞中, 每次的按鍵事件都會被封裝成 NotifyKeyArgs 對象, 通過 InputDispatcher 封裝具體的事件操作.
觀察者模式
ListView 的 Adapter 的notifyDataSetChange()
備忘錄模式
Activity 的 onSaveInstanceState 和 onRestoreInstanceState
迭代器模式
Iterator 類, SQLiteDataBase 的 query 方法, 返回的 cursor 對象, 通過如下方式去遍歷
cursor.moveToFirst();
do{
//cursor.getXXX(int);
}while(cursor.moveToNext);
模板方法模式
Activity 的 onCreate, onStart方法
訪問者模式
編譯器的注解, APT(Annotation Processing Tools), ButterKnife, Dagger, Retrofit
中介者模式
Binder
系統啟動時, 各種系統服務會向 ServiceManager 提交注冊, 即 ServiceManager 持有各種系統服務的引用, 當我們需要獲取系統的 Service 時, 比如 ActivityManager, WindowManager等(它們都是 Binder), 首先是向 ServiceManager 查詢指定標志符對應的 Binder, 再由 ServiceManager 返回 Binder 的引用, 并且客戶端和服務端之間的通信是通過 Binder 驅動來實現, 這里的ServieManager 和 Binder 驅動就是中介者.
組合模式
View, ViewGroup
適配器模式
把一個類的接口變成客戶端所期待的另一個類的接口, 從而使得原本接口不匹配而無法在一起工作的兩個類能夠在一起工作
ListView 的 adapter:
- ListView 只關心 它的每個ItemView, 不關心ItemView具體顯示什么.
- 數據源和 ListView 之間也沒有什么關系
- 通過適配器提供給ListView getView()方法, 每次 ListView 只需要提供位置信息給getView(), 然后 getView 根據位置信息向數據源獲取對應的數據, 根據數據返回不同的View.
裝飾模式
通過內部類, 內部類的實例既有外部類的實例, 還有自己在內部類添加的方法
ContextWrapper 內部有個 Context的引用, 并且 ContextWrapper 對 Context的每個方法都有實現, 在實現中調用的就是mContext的方法
享元模式
池來重用對象, 避免頻繁創建對象, 常量池, 線程池.
Message.obtain()就是從消息池中取出可重復使用的信息, 避免產生大量 Message 對象.
外觀模式
一個子系統的外部與內部的通信必須通過一個統一的對象進行.
Context, Android的很多操作, 比如 StartActvity, BindService(), sendBroadCast都通過 Context 實現.
橋接模式
將抽象和實現部分分離, 使它們能獨立的進行變化.
比如 View ,可以將其寫成ButtonView, TextView 進行描述上的變化, 也可以將其作為 DisPlay, Canvas 的操作對象.
MVC, MVP MVVM
MVC
Model: 下載下來的數據
View: View
Controller: Activity
MVP
Model:
View:
Presenter:
MVVM
Model: 數據
View: View
ViewModel: ViewHolder
RecyclerView 中的 ViewHolder 就是, 通過ViewHodler, 不用每次都寫 findViewById.
