使用mvp深度解耦
如图所示 我们可以看到 View 和 Model 没有任何联系，在我们传统的 mvc设计模式中，view 经常会去操作Model.
而在MVP里，Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现。而且，Presenter与具体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，即重用！ 不仅如此，我们还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试--而不需要使用自动化的测试工具。 我们甚至可以在Model和View都没有完成时候，就可以通过编写Mock Object（即实现了Model和View的接口，但没有具体的内容的）来测试Presenter的逻辑。
整个类图分为3块区域
左边
IBaseView,IWeatherView,WeatherActivity划分为View层。
IBaseView是为了定义一些公用的操作方法，比如showLoading这样的方法
IWeatherView实现IBaseView并定义了天气界面要操作的方法。
WeatherActivity实现了IWeatherView
中间
BasePresenter,WeatherPresenter,DataCallback属于Presenter层
BasePresenter是所有 presenter 的父类。
WeatherPresenter定义并实现了对应View 要具体操作的事项。
DataCallback是一个泛型接口，定义要获取的数据类型，在presenter 和 Model 两层之间解耦。
最右边
BaseModel,WeatherModel,ResultCallback属于model层
BaseModel是所有 Model 的父类。
WeatehrModel主要是封装view传递过来的参数并向业务服务器发送request，当然还要负责返回数据的解析。
HttpHelper主要是封装了网络请求。
ResultCallback是在model 层和 http层进行解耦。
在整个设计中，用了两个 interface 来解耦。ResultCallback让httpHelper 独立出来，让它完全作为一个工具类，只负责发送请求，我们随时可以替换这一层的实现而不会有别的影响。Datacallback 让Model 变成正在的数据持久层，入参的封装，返回数据的封装，都可以放在这一层，在Presenter直接拿到界面想要的 javabean。
