Android 常用设计模式

除了让你的客户和老板满意，对于一名开发者来说，还有一件更重要的东西能够让你保持职业生涯的愉悦：Future You！（Future You 这首歌的意思正隐喻着无法保证不久的未来每个开发者都会有喷气背包）。

说不准什么时候你会将曾经写过的代码遗留到后来，很可能那时你已经不知道这些代码是怎么写的，以及为什么要这么写。但是，除了在代码中留下大量让人头疼的注释外，更好的方式是使用某种常见的设计模式。

开始

“在这个项目中，有什么东西是我不得不在许多地方进行修改 – Future You

Future You 们会尽量少做一些“探查工作” 查看复杂的项目依赖，他们更愿意尽可能地让项目可重用、可读、可识别。他们的目标包括从各种单一对象到整个项目，这些设计模式可以分为下面几类：

• 创建模式：你创建对象的方式。
• 结构模式：你是如何组合对象的。
• 行为模式：你是如何协调对象的交互的。

你可能用过这些模式的一种或几种，只是没有一个喊得出来的名字，但是 Future You 先生会鼓励你这种将设计方案和直觉保持一致的做法。
在接下来的章节，你将学习每个类别中包含的设计模式，以及如何在 Android 中使用它们：

创建模式

• Builder 建造者
• Dependency Injection 依赖注入
• Singleton 单例

结构模式

• Adapter 适配器
• Facade 装饰

行为模式

• Command 命令
• Observer 观察者
• Model View Controller MVC模式
• Model View ViewModel MVVM模式

创建模式

“如果我需要一个特别复杂的对象，我如何获得它 – Future You

Future You 先生不想要这种答案：“每当需要一个对象实例时，就复制粘贴一遍同样的代码”。 相反，创建模式让对象的创建过程简化并容易重复。
有几个例子：

建造者模式

在我们街口的三明治店中，我用一小支铅笔在一张清单上勾上我喜欢的面包、食材和作料。尽管列表的标题告诉我“制作自己的”三明治，但我真正需要做的仅仅是填完清单并递给收银员而已。我其实不会做三明治，我只会定制……然后吃三明治。:]

类似地，建造者模式将复杂对象（面包片、菜酱馅）的构建和它的实体（一个很好吃的三明治）分开；这样，不同的构建过程能够筹建出不同的实体。
在 Android 中，当你使用到 AlertDialog.Builder 之类的对象时，就使用了建造者模式：

构建者负责一步步处理并允许你指定你关心的 AlertDialog 的部件。看一下 AlertDialog.Builder 的文档，你会看到在构造 alert 时有许多命令可用。 y

上面的代码块创建了一个如下样子的 alert：

装饰

装饰模式提供了一个更高级的接口，以便让一系列别的接口更容易使用。下图显示了这个概念：

一个 Event 是一个命令式的对象，能够由用户输入、服务器数据或 app 中的其他更合适的东西所触发。你可以创建一个子类用于传递数据：

定义好你的 Event，你获得一个 EventBus 实例并将一个对象注册为订阅者：

现在这个对象是一个订阅者了，告诉它要订阅什么类型的事件，以及当它受到一个事件后怎么处理：

最后，根据你的条件创建一个这种类型的事件并 post 出去：

因为这种模式的许多工作是通过运行时进行的，Future You 先生要调试这种模式有点困难，除非你的测试覆盖率很好。同样，一个设计良好的命令流需要在可读性和将来的易用性之间做平衡。

观察者

观察者模式在对象之间定义一种一对多的依赖。当一个对象改变状态，所有它的依赖对象都会被通知并自动更新。

这种模式用途广泛，你可以用于时间不确定的操作，比如 API 调用。还可以用于响应用户输入。

RxAndroid 框架 (即 Reactive Android) 允许你在 app 中实现这种模式：

简单说，你定义了会发送值的 Observable 对象。这些值可能会立即发送值，就像连续的流，或者在任意频率和周期发送。

Subsriber 对象会监听这些值并在接收到值时进行处理。例如，你可以在进行一次 API 调用的时候打开一个订阅，监听来自服务器的响应，并进行对应的处理。

MVC

MVC 是当下盛行的跨服务平台的架构模式；它尤其容易用到你的 Android 项目。在这种模式中，将类划分为 3 种类型：

• Model: 你的数据类。例如 User 对象或 Product 对象，它们“模拟”了真实世界中的对象。
• View: 你的可视化类。用户能够看到的所有东西都属于这个类别。
• Controller: 二者之间的粘合剂。它负责刷新 View，获取用户输入，修改 Model。

将你的代码划分为这 3 个类别，将对代码的解耦和可重用有很大益处。

Future You 先生最终从客户获得一个需求，要在 app 中添加一个新的 UI，但新的 UI 仅仅是使用 app 中原有的数据；如果用 MVC 模式，Future You 先生就可以重用同一个 Model 并只需修改 view。客户还会要求 Future You 从主页面上将一个 widget 移动到详情页面。如果视图和逻辑分离，这将很会好办得多。

另外，尽可能将布局和资源放到 Android XML 中，这将保持你的 View 层干净和整洁，非常好！

有时候你偶尔会用 Java 绘图，这时将绘图操作从 activty 和 fragment 类中分离出来将大有帮助。

随着时间的流逝，你会发现在 MVC 模式下进行架构设计非常容易，Future You 先生能够更轻易地解决它们所带来的问题。

MVM

这种不幸的名字很容易混淆的架构模式和 MVC 模式很像；Model 和 View 组件是相同的。ViewModel 对象是 Model 和 View 之间的粘合剂，但和 Controller 又不同。它向 view 暴露命令，并将 view 和 model 绑定。当 model 改变，对应的 view 通过数据绑定自动刷新。类似地，当用户和 view 交互时，数据绑定进行反向操作，自动修改 model。这种响应式模式能够消除大量胶水代码。

MVVM 模式是未来的趋势，但将它添加到模式库中仍然是非常短的时间。Future You 非常高兴你能关注它！

结束

在和最新的光鲜靓丽的 API 保持同步的同时，不断修改你的 app 会很快导致过渡重构。早一点讨论软件设计模式会减少你的开发时间，你会发现事半功倍。

我建议你阅读永恒的经典比如“四人帮”的 设计模式。相较于 Material Design 或 Android Wear，这本书有点“古老”，但介绍了许多有用的设计模式，这些设计模式比 Android 还早。