MVP架构
之前一直学习和用的都是MVC模式，将业务逻辑（Model）、数据（Controller）、界面显示（View）的分离开来，强制性地使程序的输入、处理和输出分开。这样在修改界面显示和用户交的时候，就不用去改业务逻辑。
- Model（模型）表示应用程序核心（比如数据库记录列表）。
- View（视图）显示数据（数据库记录）。
- Controller（控制器）处理输入（写入数据库记录）。
Model（模型）是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。
View（视图）是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
Controller（控制器）是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。
而MVP就是从经典的MVC模式演变而来的。
M(Model)-V(View)-P(Presenter)
它们最主要的区别就是：
在MVP中View并不直接使用Model，它们之间的通信是通过Presenter（MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过Controller。
因为View如果直接访问Model的话，View里不可避免的也会包含一些业务逻辑，所在在更改View的时候会导致到某些业务逻辑不可以重用。MVP就是把它复杂的逻辑抽离出来，放到Presenter里，Presenter通过定义好的接口与View进行交互，降低了耦合度，方便维护和测试也增强了复用性。
MVP的4个要素
- View: 负责绘制UI元素、与用户进行交互(Activity或Fragment);
- **View interface: **View需要实现的接口，View通过View interface与Presenter进行交互，降低耦合，方便进行单元测试
- Model: 负责业务Bean的操作。
- Presenter: 作为View与Model交互的纽带，承载了大部分的复杂逻辑
MVP的优点
- Model与View完全分离，它们通过接口进行交互，便于维护和测试。
- 可以更高效地使用Model，因为所有对Model的操作都在Presenter内部。
- 可以将一个Presener用于多个视图，只需要在Presenter中为不同的View定义View Interface即可，具体的View实现自己的View Interface，即可使用Presenter中的Model操作等。
开源项目Philm整个架构使用MVP实现
Philm的源码
Philm的github源码
开源项目Philm的MVP架构分析（ 很详细）
开源项目Philm的MVP架构分析
java.util.set 和 java.util.list 区别
对于Set 和 List都是接口 Collection 的子接口
- Set 不允许重复,List允许重复
- Set 没有顺序，List有顺序
另外：对于List当中，有没有重复元素的判断；是依据元素的 equals方法判断是否相等的。对于排序来说，是根据元素实现了Comparable接口compareTo()方法来排序的。