博客封面.jpg
前言
閱讀《Java 編程思想》，《Android 源碼設計模式》這兩本書后，發現了以往編碼過程中有很多代碼可以優化的點，以及當時的優化方案，所以記錄下來。
從事 Android 開發快一年時間了，對編碼有了些感悟，項目需求變更時，我們最好不要直接修改原有代碼，最好使用添加的方式來實現，避免破壞原有代碼的穩定，最好定期進行部分重構，及時清除代碼中的“垃圾”。
單一責任原則
一個類應當包含某功能的全部流程，遵守該選擇可提高代碼的邏輯清晰度，降低代碼耦合，便于以后維護。
- 目前案例
- 在某sdk項目中，賬號綁定手機郵箱，賬號升級，游客賬號升級等功能(下面統稱為賬號升級)是一個讓人頭疼的東西，因為該流程需要4-5個頁面做跳轉，最后根據不同流程，顯示對應的UI，如何將信息在這幾個頁面傳遞呢？最初設想用bundle來臨時存儲綁定信息，但缺點就是每次跳轉到新的頁面，就要馬上把上個頁面的bundle取出來，在需要多個頁面跳轉時，bundle就不適合該場景了。
- 方案1:使用SharedPreference,建立一個 BindInfoHelper 類，通過set,get方法將用戶信息存儲到sp中，這樣就避免每次轉存信息。因為流程最后要用之前存儲的信息來顯示不同的UI，所以根據單一責任原則，BindInfoHelper類應當在內部做判斷,Actvity,Fragment 就根據該狀態值顯示UI
- 方案2:可以使用sqlite數據庫存儲信息，但當時時間緊迫，就選擇了方案一
里氏替換原則
在《Android 源碼設計模式》的定義是:一個類型為T1的對象O1,替換代碼中類型為T2的對象O2,如果不出現異常，說明t1是t2的父類。
- 里氏替換的原理基于 Java 三大特性（封裝，繼承，多態），Java的父類中實現的方法，子類中一定存在同種方法，反向推導不成立。
- 目前案例
- 在某助手app中，由于項目工程比較大，如果要將原有網絡框架由 Volley 替換成 Retrofit（在沒有將網絡框架抽象的情況下），將會是件非常棘手的事情，每個調用都需要修改，誰可以保證不會出錯呢？此時利用里氏替換原則，我們應該把網絡框架抽出一層來，具體的網路框架繼承或者實現該抽象類（接口），以后需要替換的時候只要修改具體實現類，大大減少了工作量。
