一.为什么需要软件设计模式？
我们先来定义什么是好的软件架构：
- 软件架构上具有明确的分工，各个模块的功能职责平衡分配，且明确。
- 可测试性，通常良好的软件架构都具备良好的可测试性。
- 良好的易用性，维护成本低。
为什么需要模块分工？
良好的模块分工，可以大大简化我们对代码的理解难度。虽然通过大量的开发工作，可以训练我们的大脑去分析越来越复杂的逻辑，但是人总有极限，而且简单的逻辑更容易理解、不容易出错，所以，遵循单一职责原则，将复杂的业务逻辑分解。
为什么需要良好的可测试性？
对于深知单元测试好处的开发者来说，这并不是一个问题。单元测试可以大大地减少程序运行时才能发现的问题，这通常可以节省「用户反馈」->「Bug修复」->「新版本发布」->「用户安装新版本」这个耗时长达一周以上的过程。所以，程序的可测试性对于程序的稳定性是异常重要的。
为什么需要良好的易用性？
毋庸置疑，最好的代码是还没被写出来的代码。因此，越少的代码，意味着越少的 bugs。这也意味着尽量以最少的代码实现相同的功能，并非意味着这个开发者懒惰，同时，也不能不看维护成本而盲目赞同一个看似聪明的方案。
二.什么是MVP架构？
MVP是单词Model View Presenter的首字母的缩写，分别表示数据层、视图层、发布层，它是MVC架构的一种演变。作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过 Controller。
首先我们先看下传统的MVC架构Model View Controller，我们把业务逻辑放到C层（ios的ViewController,android的Activity&Fragment），但是这里会引入另外一个问题，所有的逻辑都在C层，不可避免的会造成C层非常复杂，如果项目越来越大，C层的代码会更加臃肿，维护起来也非常麻烦，而且也没办法==简单的==做单元测试，试想做一个单元测试我们要加入多少逻辑代码？
综上所述我们总结下，现有的MVC模式存在以下问题：
- 视图与控制器间的过于紧密的连接
视图与控制器是相互分离，但却是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
- 视图对模型数据的低效率访问
依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
- 不太友好的单元测试
特别是App上做单元测试的时候很多东西依赖与系统框架，没法脱离用户接口来测试这些逻辑单元。使用MVP对Presenter的测试--不需要使用自动化的测试工具。 我们可以在Model和View都没有完成时候，就可以通过编写Mock Object（即实现了Model和View的接口，但没有具体的内容的）来测试Presenter的逻辑。
基于以上几点问题，就衍生了出了一些软件设计模式如MVP，MVVW。为什么是MVP？我们先看下面这张图
- MVP分离了view和model层，Presenter层充当了桥梁的角色，View层只负责更新界面即可，这里的View我们要明白只是一个viewinterface，它是视图的接口，这样我们在做单元测试的时候可以非常方便编写Presenter层代码。关于mvp的代码测试，我们可以参考google给出的代码，google现在也在推行mvp，为此google发布了一些案例，大家可参考这里android-architecture
mvp-clean.png
- 厚重的Controller层代码也得到了释放，之前我们开发的时候会对UIViewController、Activity、Fragment编写很多的业务逻辑，尽管大家会将Service层做分离，如net层，DB层等，但还是无法避免类似的问题，activity uicontroller无法重复利用是非常难以忍受的。
- 有一点还需要注意，presenter是双向绑定的关系，因此，在设计的时候就要注意接口和抽象的使用，尽可能的降低代码的耦合度，这也是mvp的宗旨。
so，转向mvp吧！我们先看下MVP几个单词的意思，以下是我个人的理解：
- View: 是显示数据（model）并且将用户指令（events）传送到presenter以便作用于那些数据的一个接口。View通常含有Presenter的引用。在Android开发中通常将Activity或者Fragment作为View层。
- Model: 对于Model层也是数据层。它区别于MVC架构中的Model，在这里不仅仅只是数据模型。在MVP架构中Model它负责对数据的存取操作，例如对数据库的读写，网络的数据的请求等。
- Presenter:对于Presenter层他是连接View层与Model层的桥梁并对业务逻辑进行处理。在MVP架构中Model与View无法直接进行交互。所以在Presenter层它会从Model层获得所需要的数据，进行一些适当的处理后交由View层进行显示。这样通过Presenter将View与Model进行隔离，使得View和Model之间不存在耦合，同时也将业务逻辑从View中抽离。
三.实例
接下来我们看一个使用的用例吧，这个demo相对来说非常简单，下面是项目的架构，一个Activity，一个Fragment，Data层主要负责获取App已安装的应用列表，AppListPresenter负责业务逻辑处理
我们先看下presenter，viewinterface的结构
!
- AppListFragment的代码
public class AppListFragment extends Fragment implements AppViewInterface {
private Presenter presenter;
private List<PackageInfo> packageInfoList = new ArrayList<>();
private RecyclerView recyclerView;
private MyAppListRecyclerViewAdapter myAppListRecyclerViewAdapter;
@Override
public void showAppList(List<PackageInfo> packageInfos) {
if (packageInfos.isEmpty())
return;
packageInfoList.clear();
packageInfoList.addAll(packageInfos);
myAppListRecyclerViewAdapter.notifyDataSetChanged();
}
@Override
public void setPresenter(Presenter presenter) {
this.presenter = presenter;
}
}
代码比较容易理解，AppListFragment实现了AppViewInterface接口，我们需要在Activity中把AppListPresenter和AppViewInterface双向绑定。
- 接下来看下AppListPresenter层的代码，这里只列出了几个关键方法
public class AppListPresenter implements Presenter, LoaderManager.LoaderCallbacks<List<PackageInfo>>{
private AppViewInterface viewInterface;
private AppClassLoader appClassLoader;
private LoaderManager loaderManager;
private final int id = 0;
public AppListPresenter(AppViewInterface viewInterface, AppClassLoader appClassLoader,
LoaderManager loaderManager) {
this.viewInterface = viewInterface;
this.appClassLoader = appClassLoader;
this.loaderManager = loaderManager;
viewInterface.setPresenter(this);
}
@Override
public void loadInstallApps() {
//通过loadmanager提供的方法获取安装的应用列表
loaderManager.initLoader(id, null, this);
}
@Override
public void destory() {
loaderManager.destroyLoader(id);
}
@Override
public void onLoadFinished(Loader<List<PackageInfo>> loader, List<PackageInfo> data) {
//获取到已安装的应用列表，调用AppViewInterface的showAppList方法
viewInterface.showAppList(data);
}
@Override
public void launchApp(PackageInfo packageInfo) {
Intent intent = appClassLoader.queryLaunchIntent(packageInfo);
if (intent != null)
appClassLoader.getContext().startActivity(intent);
else
Toast.makeText(appClassLoader.getContext(), "Can not start the app", Toast.LENGTH_SHORT).show();
}
}
关键方法是loadInstallApps，这个方法在MainActivity的onCreate中调用
private Presenter appListPresenter;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
setSupportActionBar(toolbar);
FragmentTransaction fragmentTransaction = getSupportFragmentManager().beginTransaction();
AppListFragment appListFragment = AppListFragment.newInstance();
fragmentTransaction.add(R.id.fm, appListFragment);
fragmentTransaction.commit();
appListPresenter = new AppListPresenter(appListFragment, new AppClassLoader(getApplicationContext()),
getSupportLoaderManager());
//调用loadInstallApps
appListPresenter.loadInstallApps();
}
首先，我们获取一个AppListFragment的实例，在AppListPresenter构造函数里面我们传入AppViewInterface，同时在AppPresenter的构造函数中又将presenter注入到了AppViewInerface里面，这样就实现了Presenter和ViewInerface双向绑定，之后调用AppPresenter的loadInstallApps方法，在onLoadFinished回调里面又调用了AppViewInterface的showApps方法，这样数据就显示在界面。整个Activity和Fragment的代码精简了很多。
四.缺点
由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。还有一点需要明白，如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了
