在前一篇文章《android專案重構之路:架構篇》中已經簡單說明了專案的架構，將專案分為了四個層級：模型層、介面層、核心層、介面層。其中，最上層的介面，是變化最頻繁的乙個層面，也是最複雜最容易出問題的乙個層面，如果規劃不好，很容易做著做著，又亂成一團了。
要規劃好介面層，至少應該遵循幾條基本的原則：
保持規範性：定義好開發規範，包括書寫規範、命名規範、注釋規範等，並按照規範嚴格執行；
保持單一性：布局就只做布局，內容就只做內容，各自分離好，每個方法、每個類，也只做一件事情；
保持簡潔性：保持**和結構的簡潔，每個方法，每個類，每個包，每個檔案，都不要塞太多**或資源，感覺多了就應該拆分。
每個人的編碼習慣和風格都不同，不說那些缺乏良好編碼習慣的開發人員，就連那些已經養成良好編碼習慣的人員，很多方面都會不同。比如縮排，有的喜歡4個空格，有的喜歡兩個空格；比如變數名，有的喜歡m開頭，例如mvalue，有的喜歡直接就命名為value。如果不設定好規範，讓每個人都按照自己的習慣和風格去編碼，久了肯定亂，尤其當團隊中存在還沒養成良好編碼習慣的人員時，更容易亂。所謂無規矩不成方圓，若無規範，久必亂。定義好規範，才能統一風格，才可提高**可讀性，同時也提高了維護性，還減低了引入bug的機會。開發規範並沒有統一的標準，在這裡，我只是根據自己的經驗對一些點提供一點建議，僅供參考。
最重要的並不在於規範怎麼定義，而是在於規範的嚴格執行。如果規範定義好了，但卻不遵守，那規範就等於形同虛設，因此，規範一旦設定，就要嚴格執行。
我們都知道，物件導向設計中，有乙個基本原則就是單一職責原則，它規定乙個類應該只有乙個發生變化的原因。而這裡說的單一性，不只是規定類，也規定了方法、包，甚至到最大層面的分層架構。保持單一性是減低耦合度的關鍵標準，其目的就是各方面的解耦。架構上的分層就是最大層面的解耦，而方法上的單一就是最小層面的解耦了。要保持單一性，必定伴隨著重構。需求總會變動，**總會擴充套件，擴充套件了慢慢就會破壞原有的單一性，因此就需要重構，再次保持單一性。不斷擴充套件，不斷重構，這樣才能不斷保持良好的單一性。
**最怕的就是臃腫，臃腫的**可讀性差，維護麻煩，擴充套件更不用說了。沒有人會喜歡看臃腫的**，去維護更痛苦。我看到臃腫的**，都恨不得即刻進行重構。讓**保持簡潔，會讓人看得舒服，一目了然，維護和擴充套件起來也都非常方便。簡潔的**，甚至不需要寫注釋，只從**就能讓人一眼看懂其做了什麼。簡潔也並不只表現在**上，類、包、資源檔案等的命名和組織結構等也同樣需要保持簡潔。如何保持簡潔？這個問題並沒有乙個標準的答案，但有乙個判斷是否簡潔的簡單標準，那就是：直接閱讀**就能夠理解**的意圖，如果意圖不夠明顯，那就說明這段**還不夠簡潔。類、包、資源檔案等等，也是同樣的評判標準。下面是我覺得對保持簡潔有一定作用的一些操作方法。
規範性、單一性、簡潔性，這三個基本原則是相輔相成的。單一性和簡潔性是規範定義的標準，不能脫離這兩個原則去定義規範。而對規範的嚴格執行，則保證了後兩個原則的有效性。嘮叨了這麼多，還沒講到具體的實現，下一次就說說實現篇吧。
**：
Android專案重構之路 介面篇
寫於2015 06 19 android專案重構之路 架構篇 android專案重構之路 介面篇 android專案重構之路 實現篇 在前一篇文章 android專案重構之路 架構篇 中已經簡單說明了專案的架構，將專案分為了四個層級 模型層 介面層 核心層 介面層。其中，最上層的介面，是變化最頻繁的...
ANDROID專案重構之路 架構篇
寫於2015 06 05 我將專案分為了四個層級 模型層 介面層 核心層 介面層。模型層定義了所有的模型 介面層封裝了伺服器提供的api 核心層處理所有業務邏輯 介面層就處理介面的展示。幾個層級之間的關係如下圖所示 這裡寫描述 介面層封裝了網路底層的api，並提供給核心層呼叫。剛開始，為了簡單，該層...
Android專案重構之路 架構篇
我將專案分為了四個層級 模型層 介面層 核心層 介面層。模型層定義了所有的模型 介面層封裝了伺服器提供的api 核心層處理所有業務邏輯 介面層就處理介面的展示。幾個層級之間的關係如下圖所示 下面展開說明具體的每個層次 介面層封裝了網路底層的api，並提供給核心層呼叫。剛開始，為了簡單，該層的核心類我...