Favor composition over inheritance.

#示例圖

圖畫的有點丑，見諒。簡單說一下，Presenter就是Mvp中的P，View即MVP中的V需要什么功能都由Presenter提供，事實上Presenter也是借助Usecase來完成相應功能的，Presenter持有完成所有功能的Usecase（注：每一個Usecase完成一個功能，比如登錄就是LoginUsecase，注冊就是RegisterUsecase）。

? ? ? ? ? 為什么一個Usecase只完成一個功能？

1，單一職責原則。這個不多說。

2，我傾向于使用組合去完成功能的復用，而不是繼承。就像積木，需要哪個材料就選取哪個材料，精簡、高效。因為最小功能單位的復用性才算最大的。

事實上，不管View層需要什么功能，直接調用presenter.execute（BaseRequest request）方法即可。當然request是具體的請求對象，繼承BaseRequest。也就是說一個request對應Usecase。我們可以在Presenter中維護一個UsecaseManager實現通過request得到對應的Usecase。

Usecase是一個抽象類，上代碼

```

public abstract class Usecase<Q extends BaseRequest,R extends BaseResponse>{

privateSubscriptionmSubscription= Subscriptions.empty();

public void execute(Q request,Observer<R> subscriber){

unsubscribe();

mSubscription= buildUsecaseObservable(request)

.subscribeOn(Schedulers.io())

.observeOn(AndroidSchedulers.mainThread())

.subscribe(subscriber);

}

protected abstractObservable<R>?buildUsecaseObservable(Q request);

public voidunsubscribe(){

if(!mSubscription.isUnsubscribed()){

mSubscription.unsubscribe();

}

}

}

```

所以實現一個Usecase的步驟是繼承Usecase，覆寫buildUsecaseObservable方法，通常Usecase需要一個Repository來完成相應的操作，就在構造函數中通過Dagger2注入進來。若是明確只需要通過網絡發起請求，可以直接注入一個Api，然后再Api中完成相應操作。

本片可能寫的很沒有邏輯，但是中心思想是使用組合而非繼承，希望對你有所啟發。