<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>