### 15.3 提高程序的可維護性 本節所講述的內容是Android的程序設計思想，主旨是如何提高代碼的可維護性和可擴展性，而程序的可維護性本質上也包含可擴展性。本節的切入點為：代碼風格、代碼的層次性和單一職責原則、面向擴展編程以及設計模式，下面圍繞著它們分別展開。 可讀性是代碼可維護性的前提，一段別人很難讀懂的代碼的可維護性顯然是極差的。而良好的代碼風格在一定程度上可以提高程序的可讀性。代碼風格包含很多方面，比如命名規范、代碼的排版以及是否寫注釋等。到底什么樣的代碼風格是良好的？這是個仁者見仁的問題，下面是筆者的一些看法。 * （1）命名要規范，要能正確地傳達出變量或者方法的含義，少用縮寫，關于變量的前綴可以參考Android源碼的命名方式，比如私有成員以m開頭，靜態成員以s開頭，常量則全部用大寫字母表示，等等。 * （2）代碼的排版上需要留出合理的空白來區分不同的代碼塊，其中同類變量的聲明要放在一組，兩類變量之間要留出一行空白作為區分。 * （3）僅為非常關鍵的代碼添加注釋，其他地方不寫注釋，這就對變量和方法的命名風格提出了很高的要求，一個合理的命令風格可以讓讀者閱讀源碼就像在閱讀注釋一樣，因此根本不需要為代碼額外寫注釋。 代碼的層次性是指代碼要有分層的概念，對于一段業務邏輯，不要試圖在一個方法或者一個類中去全部實現，而要將它分成幾個子邏輯，然后每個子邏輯做自己的事情，這樣既顯得代碼層次分明，又可以分解任務從而實現簡化邏輯的效果。單一職責是和層次性相關聯的，代碼分層以后，每一層僅僅關注少量的邏輯，這樣就做到了單一職責。代碼的層次性和單一職責原則可以以公司的組織結構為例來說明，比如現在有一個復雜的需求來到了部門經理面前，如果部門經理需要給每個員工來安排具體的任務，那顯然他會顯得很累，因為他必須要了解每個員工的工作并最終收集每個員工的完成情況，這個時候整個工作過程就缺少了層次性，并且也違背了單一職責的原則，畢竟經理的主要工作是管理團隊而不是給員工安排任務。如果采用分層的思想要怎么做呢？首先經理可以將復雜的任務分成若干份，每一份交給一個主管處理，然后剩下的事情經理就不用管了，他只需要管理主管即可。對于主管來說，分配給他的任務相對于整個任務就簡單了不少，這個時候他再拆解任務給組員，這個時候真正到達組員手里的任務其實就沒有那么復雜了，這其實類似于分治策略。這樣一來整個工作過程就具有了三層的結構，并且每一層有不同的職責，一旦出現了錯誤也可以很方便地定位到具體的地方。 程序的擴展性標志著開發人員是否有足夠的經驗，很多時候在開發過程中我們無法保證已經做好的需求不在后面的版本發生變更，因此在寫程序的過程中要時刻考慮到擴展，考慮著如果這個邏輯后面發生了改變那么需要做哪些修改，以及怎么樣才能降低修改的工作量，面向擴展編程會使程序具有很好的擴展性。 恰當地使用設計模式可以提高代碼的可維護性和可擴展性，但是Android程序容易有性能瓶頸，因此要控制設計的度，設計不能太牽強，否則就是過度設計了。常見的設計模式有很多，比如單例模式、工廠模式以及觀察者模式等，由于本書不是專門介紹設計模式的書，因此這里就不對設計模式進行詳細的介紹了，讀者可以參看《大話設計模式》和《Android源碼設計模式解析與實戰》這兩本書，另外設計模式需要理解后靈活運用才能發揮更好的效果。