一般来说, Builder 常常作为实际产品的静态内部类来实现 (提高内聚性). 故而 Product,Director, Builder 常常是在一个类文件中, 例如本例中的 HotDryNoodlesWithBuilder.java. 这里为了更好的对应 Builder 模式的类图关系, 将 HotDryNoodlesWithBuilder 画了两个~.

相关文章 设计模式（一）设计六大原则设计模式（二）单例模式的七种写法设计模式（三）建造者模式设计模式（四）简单工厂模式设计模式（五）观察者模式设计模式（六）代理模式设计模式（七）装饰模式设计模式（八）外观模式 设计模式（九）模版方法模式设计模式（十）工厂方法模式设计模式（十一）…

基于 Loader 机制的 Google 官方 TODO-MVP 实现的分析探讨，欢迎交流。

上集讲到, 小光利用装饰者模式调校好了饮品加料 (糖, 冰, 蜂蜜…) 的流程. 从此再也不怕客户的各种要求了. 各式饮品也成了小光热干面店的一大特色. 当然, 饮品的试喝也不是无期限了. 试喝期快结束了, 小光跟表妹商量了下, 结合顾客们的反馈, 他们选定了其中三家, 到底使用哪家还需要跟商家再谈判下决定.

MVP 模式是一种架构设计模式，也是一种经典的界面模式。MVP 中的 M 代表 Model, V 是 View, P 是 Presenter。 Model 一部分是处理业务逻辑，一部分是提供 View 显示的数据。 View 代表的是一个接口，一个将 UI 界面提炼而抽象出来的接口。 Presenter Model 和 View 之间的桥梁

动态切换布局控件

MVP： V 层处理 UI 视图操作；P 层实现业务逻辑操作（有设计需要的时候，核心业务甚至可以写到一个核心的 P 里面去）；M 层为数据仓库，后台管理数据来源与数据控制，数据是来自网络、数据库、SP、缓存，示例：你可能会需要这样一个实现，一个数据列表，不需要实时性，但是需要给网络情况有问题时的用户提升用户体验，需要使用网络数据 + 本地缓存数据机制，那么，都可以统一在这个数据仓库做处理，代码逻辑层次很清晰，你应该会喜欢上这个设计。 V-P 之间的调用方式采取依赖倒置原则，俗话就是使用抽象接口（回调）；P 与 V，代码写多了，其实会发现，V 可以正常的调用 P，P 则要尽量少调用 V，或者使用 DataBinding，数据的变化使用绑定方式；P 与 M，M 只与 P 做沟通，数据一般来自后台延时操作，这块也就是使用 RxJava 情况较多的地方，网络请求可以尝试使用 ReTrofit。一般情况下，一个 V 对应一个 P，而 P 和 M，会出现一个 P 对应多个 M 的情况（M 的接口多了，或许会把 M 按模块创建）。

在看到掘金上看了一些资料，然后整理出自己对 android mvp 开发的一写见解。

### 一、MVP 模式优缺点 在说 MVVM 之前，简单回顾一下 MVP 分层，MVP 总共分成三层： a 、View: 视图层，对应 xml 文件与 Activity/Fragment； b 、Presenter: 逻辑控制层，同时持有 View 和 Model 对象； c 、Model: 实体层，负…