<b>本文讲的是如何创建高度模块化的 Android 应用，</b>
<b></b>
Android 中构建 UI 的职责通常委派给一个类（比如 Activity、Fragment 或 View/Presenter）。这通常涉及到以下任务：
填充 View（xml 布局）
View 配置（运行时参数、布局管理、适配）
数据源连接（DB 或者 数据存储的监听/订阅）
加载缓存数据
新数据的按需请求分派
监听用户事件（tap、scroll）然后响应事件
除此之外，Activity 和 Fragment 通常还会委派一些额外的职责：
App 导航
Activity 结果处理
Google Play 服务连接和交互
过渡动画配置
这不是单一职责，当前的处理方式包括了继承或组合，这太复杂了。
对于这种复杂的结构，如 UI 构建，继承能让它很快变成一坨 x。看看下面的模拟案例：
据此继承树构建代码会很快变得难于管理 （"继承地狱"）。要避免这种情况，开发人员应遵循"组合而非继承"的原则。
组合优于继承原则是个很棒的想法，无疑可以帮助我们解决上面提出的问题。然而，几乎没有库、示例代码或者教程来教你如何在 Android 上实现这原则。一种实现它的简单方法就是使用运行时参数（又叫 intent extras）来组合功能，但是，仍会导致形成一个巨大的难以管理的怪物类。
开发者们每天都要面对这些提出的问题， EyeEm Android 团队开始开发一种模式，以一种更加灵活的方式来解决该问题，而不是直接附加到一个组件上如 Activity 或 Fragment 。该模式可以用来对任何开发者希望通过组合来模块化的类进行解耦。
该模式和 LightCycle/Composite 的方法非常相似，由三个类组成：
基本类，称为 DecoratedObject（装饰对象），调度其继承和额外的方法给一个调度对象。
DecoratorsObject 实例化，保存所有组成对象的列表并分派方法给它们。
Decorator 抽象类，所有方法和额外接口都只声明未实现。由创建此类的开发人添加单一职责的具体实现。
使用这种方式开发人员获得的直接好处
职责分离
功能动态运行置换
并行开发
为了让开发者能毫无障碍的实现上述模式，一个在编译时生成代码的工具被创造了出来，接下来我们会看到，将之前提交的那些职责分解成单一职责类是多么简单。
要实现装饰模式首先创建应生成的代码蓝图，在这里我们将使用一个带 RecyclerView 的 Activity 作为例子，但同样能用在 Fragment、Presenter 甚至 View 。这这个例子中，我们将使用 activity 生命周期中的 onCreate/onStart/onStop/onDestroy ，但是也会额外创建几个适合 RecyclerView 案例的回调。
这个简单的蓝图使用 <code>@Decorate</code> 注解，将会生成完整的修饰模式实现，<code>Serializable</code> builder 类可以作为参数传递。为了完成 Activity 的实现，我们扩展了生成类，并将 received builder 绑定上去。
现在可以方便的将职责分发到可绑定的修饰类上。每个修饰器包含所有生命周期的回调，可以实现任何可选接口。最后，可以组合得到一个简单的建造者模式：
上面展示的代码大部分都是出自示例。你会发现一个用 Realm 和 Retrofit 真正实现的修饰器列表，就是这篇文章开始提到的 UI 构建任务。
CoordinatorLayoutInstigator，重写了 CoordinatorLayout 的默认布局，可选实例化一个 header
ToolbarInstigator，接管 toolbar，并且应用一个标题
ToolbarUp 和 ToolbarBack 修饰器，导航工具栏上图标的行为
加载更多的修饰器，添加一个无限滚动的功能到 RecyclerView
PhotoList 和 PhotoRequest 修饰器，本地数据存储和 API 请求图片列表 API 调用
上面所示的代码和实现纯粹只是示例，仅作为指导。
当我们为 Android 创建这个库时，该模式是开放给任何用例的。这个库是一个纯 Java 实现，它在编译时生成代码，可用于任何 Java 类，我们鼓励开发人员在他们任何 Java 项目中编写模块化的单一职责的代码！来
<b>原文发布时间为：2016年08月13日</b>
<b>本文来自云栖社区合作伙伴掘金，了解相关信息可以关注掘金网站。</b>