1.單一職責原則（Single Responsibility Principle，縮寫SRP）

單一職責原則，就一個類而言，應該只有一個引起它變化的原因。簡單說，一個類應該是一組高度相關的函數、數據的封裝；也就是高內聚。

下面代碼為 ImageLoader（圖片加載）類的代碼

public class ImageLoader{
    //圖片緩存
    LruCache<String,Bitmap> mImageCache;
    //線程池，線程數量為CPU的數量
    ExecutorService mExecutorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProessors());
    
    public ImageLoader(){
        initImageCache();
    }
    
    private void initImageCache() {
        //省略...         
   }
    
   //顯示圖片
   public  void displayImage(final String url, final ImageView imageView) {
        //省略... 
   }
    
   //下載圖片
   public  Bitmap downloadImage(String imageUrl) {
        //省略... 
        return bitmap;
   }
}

這里可以看出來 ImageLoader 類作用有初始化圖片緩存、顯示圖片、下載圖片，顯然顯示圖片和下載圖片兩個方法與初始化圖片緩存方法相比作用就顯得有些不相關。也就是不符合單一職責原則。按照邏輯進行分拆之后得到ImageLoader和ImageCache兩個類。ImageLoader負責圖片加載邏輯，ImageCache負責處理圖片緩存邏輯，這樣職責就清楚了，當與緩存相關的邏輯需要改變時，不需要修改ImageLoader類，而圖片加載的邏輯需要修改時也不會影響到緩存處理邏輯。

image

ImageLoader代碼修改如下所示：

/** 圖片加載類 */
public  class ImageLoader {
    //圖片緩存
    ImageCache mImageCache = new ImageCache() ;
    //線程池,線程數量為CPU的數量
    ExecutorService mExecutorService = Executors.newFixedThreadPool (Runtime.getRuntime().availableProcessors());

    //加載圖片
    public  void displayImage(final String url, final ImageView imageView) {
        //省略... 
     }

    public  Bitmap downloadImage(String imageUrl) {
        //省略... 
        return bitmap;
    }
} 

而添加的ImageCache類用于處理圖片緩存，具體代碼如下：

public class ImageCache {
    // 圖片LRU緩存
    LruCache<String, Bitmap> mImageCache;

    public ImageCache() {
        initImageCache();
    }

    private void initImageCache() {
        //省略... 
    }

    public void put(String url, Bitmap bitmap) {
        mImageCache.put(url, bitmap) ;
    }

    public Bitmap get(String url) {
        return mImageCache.get(url) ;
    }
}

如何劃分一個類、一個函數的職責，每個人都有自己的看法，這需要根據個人經驗、具體的業務邏輯而定。

2.開閉原則（Open Close Principle，縮寫OCP）

開閉原則是Java中最基礎的設計原則，知道我們如何建立一個穩定的、靈活的系統。定義：軟件中得對象應該對于擴展是開放的，但是對于修改是封閉的。

例如圖中MemonyCache、DiskCache、DoubleCache都實現了ImageCache接口，ImageLoader使用ImageCache處理緩存，就意味著ImageLoader可以通過setImageCache()指定使用哪一種緩存類型，可以使三種緩存其中任意一種，同時不需要修改ImageLoader中的代碼。這也就是開閉原則的體現。

簡單地說，當軟件需要變化時，應該盡量通過擴展的方式來實現變化，而不是通過修改已有的代碼來實現?！皯摫M量”4個字說明OCP原則并不是說絕對不可以修改原始類的，當代碼需要需要重構的時候要及時重構，使代碼恢復正常，而不是通過繼承等方式添加新的實現，這會導致類型的膨脹以及歷史遺留代碼的冗余。

開發過程中都沒有那么理想的狀況，因此，凡事也是需要結合具體情況再做決定，目的是更穩定、更靈活同時保有原有的正確性。

3.里氏替換原則（Liskov Substitution Principle，縮寫LSP）

里氏替換原則，書上原話的定義簡直看不得（解釋的辣眼睛，完全看不懂），簡單地說就是所有引用基類的地方必須能透明地使用其子類的對象。只要父類能出現的地方子類就可以出現，而且替換為子類也不會產生任何錯誤或異常，使用者可能根本就不需要知道是父類還是子類。但是，反過來就不行了，有子類出現的地方，父類未必就能適應。其實就是：抽象。

上圖可以看出，Window依賴于View，而Button和TextView繼承View。這里任何繼承自View類的子類都可以設置給show()方法，也就是里氏替換原則。通過里氏替換，就可以自定義各式各樣的View，然后傳遞給Window，并且將View顯示到屏幕上。

里氏替換原則的核心原理是抽象，抽象又依賴于繼承這個特性，繼承的優缺點都相當明

優點：

• 代碼重用，減少創建類的成本，每個子類都擁有父類的方法和屬性
• 子類與父類基本相似，但又與父類有所區別
• 提高代碼的可擴展性

缺點：

• 繼承是侵入性的，只要繼承就必須擁有父類的所有屬性和方法
• 可能造成子類代碼冗余、靈活性降低，因為子類必須擁有父類的屬性和方法

事物總是具有兩面性，如何權衡利與弊都是需要根據具體場景來做出選擇并加以處理。

4.依賴倒置原則（Dependence Inversion Principle，縮寫DIP）

依賴倒置原則，說的就是一種特定的就形式，使得高層次的模塊不依賴于低層次的模塊的實現細節的目的，依賴模塊被顛倒了。依賴倒置原則的幾個關鍵點：

• 高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象
• 抽象不應該依賴細節
• 細節應該依賴抽象

是不是覺得和沒說一個樣，至少我是這么覺得的；繼續往后看才明白，所謂高層模塊就是調用端，低層模塊就是具體實現類。依賴倒置原則在 Java 語言中的表現就是：模塊間的依賴通過抽象發生，實現類之間不發生直接的依賴關系，通過接口或抽象類產生依賴關系。什么是依賴關系呢？其實就是相互之間的調用關系。概括來說就是面向接口變成，或者是面向抽象編程。

其實依賴倒置原則主要目的就是解耦

依然可以使用這張圖來表示，表達出來就是ImageLoader和MemonyCache等并沒有直接關系，甚至ImageLoader只需要實現ImageCache類或繼承其他已有的ImageCache子類完成相應的緩存功能，然后將具體的實現注入到ImageLoader即可實現緩存功能的替換。這也是依賴倒置原則的體現。

5.接口隔離原則（Interface Segregation Principle，縮寫ISP）

接口隔離原則將非常龐大、臃腫的接口拆分成為更小的和更具體的接口；目的就是解耦。這個原則的做法和單一職責原則有點相似，就是說接口中得方法保持更高的相關性、盡量少，避免掉不需要的方法。

舉個栗子，現在有一個帶有呼吸方法的接口，還有一個打鼾方法的接口；如果說，你把這兩個方法放到一個接口中，基本就是違背接口隔離原則，畢竟呼吸和打鼾沒有什么緊密的相關性；不可能說我需要呼吸的時候一定需要打鼾吧！

6.迪米特原則（Law of Principle，縮寫LOP）

迪米特原則也稱為最少知識原則（Least Knowledge Principle），定義：一個對象應該對其他對象有最少的了解。通俗地講，一個類要對自己需要調用的類知道得最少，類的內部如何實現、如何復雜都與調用者（或依賴者）沒關系，調用者（或依賴者）只需要知道他需要的方法即可，其他的不需要關心。類與類之間的關系越密切，耦合度越大；當一個類發生改變時，對另一個類的影響也越大。

迪米特法則還有一個英文解釋是：Only talk to your immedate friends，翻譯過來就是：只與直接的朋友通信。什么叫做直接的朋友呢？每個對象都必然會與其他對象有耦合關系，兩個對象之間的耦合就成為朋友關系，這種關系的類型有很多，例如組合、聚合、依賴等。

下圖是Volley框架中的DiskBasedCache類（實現Cache接口）和Cache接口的代碼

Volley中的Response緩存接口的設計。Cache接口定義了緩存類需要實現的最小接口，依賴緩存類的對象只需要知道這些接口即可。例如緩存的具體實現類DiskBasedCache，該緩存類將Response序列化到本地,這就需要操作File以及相關的類。

Volley的直接朋友就是DiskBasedCache，間接朋友就是mRootDirectory、mEntries等。Volley只需要直接和Cache類交互即可，并不需要知道File、mEntries等對象的存在。

文中有引用書本中得例子，也有根據自己理解舉的例子，如有不對還望指出。