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