迪米特原則（Law of Demeter LoD）

迪米特原則又叫最少知道原則（Least Knowledge Principle,LKP），這里的最少知道主要是強調，調用者對傳入的參數(shù)，和接受到的返回的參數(shù)很熟悉即可，不需要知道在調用過程中涉及了哪些框架設計者自己的類。

例如你使用某個JSON框架，你傳入的是可能是一個對象，最多再傳入了一個Class類型就可以很方便的調用這個框架的方法，接受到了的也是已經(jīng)被序列化好的JSON字符串，這些都是我們熟悉的，但是如果你要我傳入一個這個JSON框架自己為了開發(fā)方便而定義的類，并且讓我實例化作為參數(shù)，又或者作為返回值接收，我是無從下手的。這樣作為調用者來說體驗不是很好，所以迪米特原則強調的是，調用者最好只是需要知道他們熟悉的東西就可以了，無需知道更多。

還是舉例子飯店的例子，天天去吃飯，我們最熟悉的是當然是服務員(Waiter),我們就只需要知道這一個角色就可以了，點餐和結賬只需要找他就可以，著很方便。

我們點餐后，服務員自己會去找他熟悉的廚師，又或者經(jīng)理去安排接下來的工作。

所以，我們對飯店只需要知道一個服務員即可，這是最少知道的體現(xiàn)。

public class Pop{
    public void Order(Waiter waiter,String menuList){
        waiter.getOrder(menuList);
        //我們的調用只需要傳入我們熟悉的服務員，還有點完的菜單就可以，然后剩下的交給服務員
    }
}
public class Waiter{
    
    private Cook;
    public void getOrder(String menuList){
        Cook.cook(menuList);//服務員會去處理接下來事情，去找廚師還是找什么，我們都不知道
    }
}

調用的時候。

public static void main(String[] ars){
    Pop pop = new Pop();
    pop.Order(new Waiter(),"西紅柿炒蛋，蛋糕，米飯");
    //等待上菜。
}

當我們調用的時候，只傳入了我們所熟悉的服務員(Waiter)，因為我們天天去，當然最熟悉，然后天天點這家的菜，自然對這家有什么菜也爛熟于心。

我們也最少知道這些知識，就可以吃到我們想要的東西。我們對后面做菜的廚師(Cook)并不知道也不熟悉，我們吃個飯也不用每個廚師都認識吧，這也不合邏輯。

合成復用原則（Composite/Aggregate Reuse Principle,CARP）

這個原則其實我們天天都在用，就是讓你的類持有一個其他成員變量，為什么要這樣的做？

我認為，這是除了使用內部類來實現(xiàn)多重繼承的另一種方法，這個繼承其實還是要打上雙引號，因為這個和繼承還是有更加本質的區(qū)別。

我們可以往一個類中塞入很多其他類成員來使用他們的方法，就仿佛是繼承了他們，可是就繼承來說，父類的細節(jié)是完全暴露給子類的，我們把他叫做白箱復用，而通過合成/復用的方法，我們對類以外的對象是無法獲得實現(xiàn)細節(jié)，其實我們對于這個陌生的父類只是單純調用他的方法而已，我們把它叫做黑箱復用。

這個就不做代碼演示了。大家平時肯定都用到，只是沒有這個方面的意識而已。

版權聲明：本文為CSDN博主「PopCandier」的原創(chuàng)文章，遵循CC 4.0 by-sa版權協(xié)議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/CandyCCCation/article/details/88904313