最近聽朋友A去面試遇到一些問題，問題並不難都是非常基礎的，但是確是我們最容易忽視的地方，這裡總結一下只為做記錄，各位觀眾老爺不喜勿噴；接下來我要開始裝逼了，哈哈

 場景：面試基礎問題

這個問題就是Java的核心思想：面向物件，這裡不展開面向物件的概念，面試題是回答一下面向物件的幾大原則，當時朋友A就一臉懵比（內心一萬個草泥馬），平時都是寫程式碼，況且面向物件這麼抽象的概念如何描述呢？（成妾做不到啊）。當時我也是懵比，就馬上去看了一下面向物件的原則，然後簡單的記錄一下。

面向物件的六大原則：

1、單一職責

2、開閉原則

3、里氏替換

4、依賴倒置

5、介面隔離

6、迪米特原則

是不是覺得記住了這6大原則就可以出去裝逼了？（不存在的，哈哈），正當你得意的說出這六大原則的時候面試官說解釋一下什麼是單一職責?我估計你會。。。。

廢話說太多了，接下來我們來一一解釋下概念性的問題：

1、單一職責

定義：就一個類而言，應該僅有一個引起它變化的原因。這個比較好理解就是自己做自己的事情，不要做超過自己職責範圍之外的事情(我想起了葫蘆娃七兄弟)；比如在Android原始碼設計模式中提到小明在寫快取模組的時候把所有的快取方式都是寫在一個類中；現實我們coding的時候也經常這樣，當我們完成後那業務邏輯的程式碼開起來是那麼酸爽（笑哭，埋坑中。。），比如釋出後產品說想改一下業務實現規則，這下你回去看你的程式碼發現自己都看不懂了（請不要給自己或則別人挖坑，），其實簡單說在coding中就是把一組相關性很高的函式、資料封裝在一個類中（這裡是沒毛病），如果有多個功能區分的函式我們可以拆開多個類，這就是簡單的單一職責。

2、開閉原則

官方定義：在軟體中的物件(類，模組、函式等)應該對於擴充套件是開放的，但是對於修改是封閉的。這句話通俗的理解為程式在完成以後，程式中一個類的實現只應該因錯誤而被修改，新的或者改變的特性應該通過新建不同的實現類，新建的類可以通過繼承的方式來重用原類的程式碼，讓程式更穩定靈活。這就是簡單的開閉原則。

3、里氏替換原則

定義：所有引用基類的地方必須能透明的使用其子類的物件。我們知道面向物件的語言有三大特點是繼承、封裝、多型，里氏替換原則就是依賴繼承、多型兩大特性。通俗的說只要是父類能出現的地方子類就可以出現，而且替換為子類後不會出現任何錯誤或者異常，使用者不需要知道是父類還是子類，但是反過來就不行，有子類出現的地方，父類就未必適應。總結一下就是兩個字：

4、依賴倒置原則

定義：模組間的依賴通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是通過介面或抽象類產生的。簡單的說就是面向介面程式設計，這句話相信大家聽的最多了。比如小明之前只是實現了sd卡的快取，現在主管要求實現記憶體快取，小明這個時候應該把快取這個功能函式抽象為一個公共介面，然後去各自實現sd卡快取策略跟記憶體快取策略。如果下次主管再加一個別的快取方式，這個時候小明就可以不修改之前的快取策略而擴充套件一個新的快取策略就可以了。

5、介面隔離原則

定義：類間的依賴關係應該建立在最小介面上。介面隔離原則將非常龐大、臃腫的介面拆分成更小的和更具體的介面，這樣客戶端只需要關係他們感興趣的方法。介面隔離原則目的就是系統解耦，提高程式碼質量。比如在java6之前有個OutputStream的關閉問題，每次使用完後都要關閉，各種try...catch巢狀程式碼可讀性非常差。我們通過看原始碼知道有一個Closeable介面，該介面定義了一個可關閉物件，恰好OutputStream又實現了這個介面，所以我們可以封裝一個工具類來關閉物件，這裡直接貼程式碼：

public final class CloseUtils{
      private CloseUtils(){}
      /**
       **關閉Closeable物件
       ** @param closeable
       **/
       public  static  void closeQuietly(Closeable closeable){
         if(closeable!=null){
              try{
                 closeable.close();
              }catch(IOExecption e){
                  e.printStackTrace();
              }
          }
     }
}

我們直接在用到的地方呼叫就可以。CloseUtils的closeQuietly方法的基本原理就是依賴於Closeable抽象而不是具體實現，並建立在最小的依賴原則基礎上，只需要知道這個物件可以關閉，其他不需要關心。

6、迪米特原則

大家肯定會問這個是什麼鬼？根本沒聽過。。（原諒我的亂入）

定義：一個物件應該對其他物件有最少的瞭解（還有一個解釋是：只與直接的朋友通訊）。通俗的講，一個類應該對自己需要耦合或者呼叫的類知道最少，類的內部如何實現與呼叫者或者依賴者沒關係，呼叫者或者依賴者只需要知道它需要的方法即可，其他一律不關心。是不是覺得還是很難理解？我們舉個栗子，我們程式設計師去租房子，在一線城市租房大部分都是通過中介找房，假如我們只關心房間的面積跟租金，其他一概不管，中介只需要將符合我們要求的房子提供給我們就好了。接下來我們從code層面上會比較好理解一點。我們抽象出一個房間類(Room)，中介類（Mediator），租戶類(Tenant)

    /**
     * 房間
     */
    public class Room{
        public float area;//面積
        public float price;//價格

        public Room(float area, float price) {
            this.area = area;
            this.price = price;
        }

        @Override
        public String toString() {
            return "Room{" +
                    "area=" + area +
                    ", price=" + price +
                    '}';
        }
    }

    /**
     * 中介
     */
    public  class Mediator{
        List<Room> rooms = new ArrayList<>();//中介手上的房間數
        public Mediator(){
            for(int i=0;i<5;i++){
                rooms.add(new Room(14+i,(14+i)*150));
            }
        }

        public List<Room> getRooms() {
            return rooms;
        }
    }

    /**
     * 租戶
     */
    public class Tenant{
        public float roomArea;
        public float roomPrice;
        public static final float diffPrice = 100.00001f;
        public static final float diffArea = 0.00001f;

        /**
         * 租賃房子
         * @param mediator
         */
        public  void rentRoom(Mediator mediator){
            List<Room> rooms = mediator.getRooms();
            for(Room room:rooms){
                if(isSuitable(room)){
                   System.out.println("租到房子啦！"+room);
                    break;
                }
            }
        }

        /**
         * 是否符合租戶要求
         * @param room
         * @return
         */
        private boolean isSuitable(Room room){
            return  Math.abs(room.price-roomPrice)<diffPrice&&Math.abs(room.area-roomArea)<diffArea;
        }
    }

從上面程式碼可以看到，租戶(Tenant)不僅依賴了中介(Mediator)，還需要頻繁與房間(Room)打交道。租戶的要求只是要求通過中介找房子，如果把這些檢測條件都放在租戶(Tenant)中，那麼中介的功能就被弱化了，導致租戶與房子的耦合較高，還要關心房子的細節。當Room變化時候Tenant也必須跟著變化；而Tenant又與Mediator耦合，這樣就出現了多重關係。結構關係圖（UML）如下：

既然耦合嚴重，那我們就見招拆招。首要要明確的是租戶只跟中介通訊，從程式碼中提現就是將Room相關的操作從Tenant中移除，這些操作是屬於中介（Mediator)。重構程式碼後：

/**
     * 中介
     */
    public  class Mediator{
        List<Room> rooms = new ArrayList<>();//中介手上的房間數
        public Mediator(){
            for(int i=0;i<5;i++){
                rooms.add(new Room(14+i,(14+i)*150));
            }
        }

        /**
         * 中介租賃房子
         * @param area
         * @param price
         * @return
         */
        public Room rentOut(float area,float price){
            for (Room room:rooms){
                if(isSuitable(area,price,room)){
                    return room;
                }
            }
            return  null;
        }

        /**
         * 是否符合租戶要求
         * @param room
         * @return
         */
        private boolean isSuitable(float area,float price,Room room){
            return  Math.abs(room.price-price)<Tenant.diffPrice&&Math.abs(room.area-area)<Tenant.diffArea;
        }
    }

    /**
     * 租戶
     */
    public class Tenant{
        public float roomArea;
        public float roomPrice;
        public static final float diffPrice = 100.00001f;
        public static final float diffArea = 0.00001f;

        /**
         * 租賃房子
         * @param mediator
         */
        public  void rentRoom(Mediator mediator){
                   System.out.println("租到房子啦！"+mediator.rentOut(roomArea,roomPrice));
        }
    }

我們只是將租戶對於房間的判斷操作放到了中介中，這本來就是屬於中介的職責，根據租戶設定的要求找到符合條件的房子，並將結果交給租戶就可以了。租戶不需要了解房間太多的細節，所以事情租戶與中介溝通就好，這樣“只與直接的朋友通訊”就能夠將租戶與中介、房間之間複雜關係中抽離出來，降低程式的耦合，穩定性更好。
以上就是Java核心面向物件的原則的解釋與場景分析。新手上路，請各位觀眾老爺df二連帶走。

PS:寫完這部落格的感覺就是