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中完成相应操作。
本片可能写的很没有逻辑，但是中心思想是使用组合而非继承，希望对你有所启发。
网友评论