設(shè)計模式常見面試知識點(diǎn)總結(jié)（Java版）

設(shè)計模式

這篇總結(jié)主要是基于我設(shè)計模式系列的文章而形成的的。主要是把重要的知識點(diǎn)用自己的話說了一遍，可能會有一些錯誤，還望見諒和指點(diǎn)。謝謝

更多詳細(xì)內(nèi)容可以到我的cdsn博客上查看： https://blog.csdn.net/a724888

最后，如果想要更好地完成這部分內(nèi)容的學(xué)習(xí)，建議大家還是去看一下原文。

創(chuàng)建型模式

創(chuàng)建型模式 創(chuàng)建型模式的作用就是創(chuàng)建對象，說到創(chuàng)建一個對象，最熟悉的就是 new 一個對象，然后 set 相關(guān)屬性。但是，在很多場景下，我們需要給客戶端提供更加友好的創(chuàng)建對象的方式，尤其是那種我們定義了類，但是需要提供給其他開發(fā)者用的時候。

單例

<pre>

1. 單例模式保證全局的單例類只有一個實例，這樣的話使用的時候直接獲取即可，比如數(shù)據(jù)庫的一個連接，Spring里的bean，都可以是單例的。

3. 單例模式一般有5種寫法。

5. 第一種是餓漢模式，先把單例進(jìn)行實例化，獲取的時候通過靜態(tài)方法直接獲取即可。缺點(diǎn)是類加載后就完成了類的實例化，浪費(fèi)部分空間。

7. 第二種是飽漢模式，先把單例置為null，然后通過靜態(tài)方法獲取單例時再進(jìn)行實例化，但是可能有多線程同時進(jìn)行實例化，會出現(xiàn)并發(fā)問題。

9. 第三種是逐步改進(jìn)的方法，一開始可以用synchronized關(guān)鍵字進(jìn)行同步，但是開銷太大，而后改成使用volatile修飾單例，然后通過一次檢查判斷單例是否已初始化，如果未初始化就使用synchronized代碼塊，再次檢查單例防止在這期間被初始化，而后才真正進(jìn)行初始化。

11. 第四種是使用靜態(tài)內(nèi)部類來實現(xiàn)，靜態(tài)內(nèi)部類只在被使用的時候才進(jìn)行初始化，所以在內(nèi)部類中進(jìn)行單例的實例化，只有用到的時候才會運(yùn)行實例化代碼。然后外部類再通過靜態(tài)方法返回靜態(tài)內(nèi)部類的單例即可。

13. 第五種是枚舉類，枚舉類的底層實現(xiàn)其實也是內(nèi)部類。枚舉類確保每個類對象在全局是唯一的。所以保證它是單例，這個方法是最簡單的。

</pre>

工廠模式

<pre>

1. 簡單工廠一般是用一個工廠創(chuàng)建多個類的實例。

3. 工廠模式一般是指一個工廠服務(wù)一個接口，為這個接口的實現(xiàn)類進(jìn)行實例化

5. 抽象工廠模式是指一個工廠服務(wù)于一個產(chǎn)品族，一個產(chǎn)品族可能包含多個接口，接口又會包含多個實現(xiàn)類，通過一個工廠就可以把這些綁定在一起，非常方便。

</pre>

原型模式

<pre>

1. 一般通過一個實例進(jìn)行克隆從而獲得更多同一原型的實例。使用實例的clone方法即可完成。

</pre>

建造者模式

<pre>

1. 建造者模式中有一個概念叫做鏈?zhǔn)秸{(diào)用，鏈?zhǔn)秸{(diào)用為一個類的實例化提供便利，一般提供系列的方法進(jìn)行實例化，實際上就是將set方法改造一下，將原本返回為空的set方法改為返回this實例，從而實現(xiàn)鏈?zhǔn)秸{(diào)用。

3. 建造者模式在此基礎(chǔ)上加入了builder方法，提供給外部進(jìn)行調(diào)用，同樣使用鏈?zhǔn)秸{(diào)用來完成參數(shù)注入。

</pre>

結(jié)構(gòu)型模式

<pre>

1. 結(jié)構(gòu)型模式

3. 前面創(chuàng)建型模式介紹了創(chuàng)建對象的一些設(shè)計模式。

5. 這節(jié)介紹的結(jié)構(gòu)型模式旨在通過改變代碼結(jié)構(gòu)來達(dá)到解耦的目的，使得我們的代碼容易維護(hù)和擴(kuò)展。

</pre>

橋接模式

<pre>

1. 有點(diǎn)復(fù)雜。建議參考原文

</pre>

適配器模式

<pre>

1. 適配器模式用于將兩個不同的類進(jìn)行適配。

3. 適配器模式和代理模式的異同

5. 比較這兩種模式，其實是比較對象適配器模式和代理模式，在代碼結(jié)構(gòu)上，

6. 它們很相似，都需要一個具體的實現(xiàn)類的實例。

7. 但是它們的目的不一樣，代理模式做的是增強(qiáng)原方法的活；

8. 適配器做的是適配的活，為的是提供“把雞包裝成鴨，然后當(dāng)做鴨來使用”，

9. 而雞和鴨它們之間原本沒有繼承關(guān)系。

11. 適配器模式可以分為類適配器，對象適配器等。

13. 類適配器通過繼承父類就可以把自己適配成父類了。

14. 而對象適配器則需要把對象傳入另一個對象的構(gòu)造方法中，以便進(jìn)行包裝。

</pre>

享元模式

<pre>

1. 享元模式的核心在于享元工廠類，

3. 享元工廠類的作用在于提供一個用于存儲享元對象的享元池，

5. 用戶需要對象時，首先從享元池中獲取，

7. 如果享元池中不存在，則創(chuàng)建一個新的享元對象返回給用戶，

9. 在享元池中保存該新增對象。

</pre>

代理模式

<pre>

1. 我們發(fā)現(xiàn)沒有，代理模式說白了就是做 “方法包裝” 或做 “方法增強(qiáng)”。

3. 在面向切面編程中，算了還是不要吹捧這個名詞了，在 AOP 中，

5. 其實就是動態(tài)代理的過程。比如 Spring 中，

6. 我們自己不定義代理類，但是 Spring 會幫我們動態(tài)來定義代理，

8. 然后把我們定義在 @Before、@After、@Around 中的代碼邏輯動態(tài)添加到代理中。

</pre>

外觀模式

<pre>

1. 外觀模式一般封裝具體的實現(xiàn)細(xì)節(jié)，為用戶提供一個更加簡單的接口。

3. 通過一個方法調(diào)用就可以獲取需要的內(nèi)容。

</pre>

組合模式

<pre>

1. 組合模式用于表示具有層次結(jié)構(gòu)的數(shù)據(jù)，使得我們對單個對象和組合對象的訪問具有一致性。

3. 直接看一個例子吧，每個員工都有姓名、部門、薪水這些屬性，

5. 同時還有下屬員工集合（雖然可能集合為空），

6. 而下屬員工和自己的結(jié)構(gòu)是一樣的，

8. 也有姓名、部門這些屬性，

9. 同時也有他們的下屬員工集合。

11. class Employee {

12. private String name;

13. private String dept;

14. private int salary;

15. private List<Employee> subordinates; // 下屬

16. }

</pre>

裝飾者模式

裝飾者

裝飾者模式把每個增強(qiáng)類都繼承最高級父類。然后需要功能增強(qiáng)時把類實例傳入增強(qiáng)類即可，然后增強(qiáng)類在使用時就可以增強(qiáng)原有類的功能了。

和代理模式不同的是，裝飾者模式每個裝飾類都繼承父類，并且可以進(jìn)行多級封裝。

行為型模式

<pre>

1. 行為型模式

3. 行為型模式關(guān)注的是各個類之間的相互作用，將職責(zé)劃分清楚，使得我們的代碼更加地清晰。

</pre>

策略模式

<pre>

1. 策略模式一般把一個策略作為一個類，并且在需要指定策略的時候傳入實例，于是我們可以在需要使用算法的地方傳入指定算法。

</pre>

命令模式

<pre>

1. 命令模式一般分為命令發(fā)起者，命令以及命令接受者三個角色。

3. 命令發(fā)起者在使用時需要注入命令實例。然后執(zhí)行命令調(diào)用。

5. 命令調(diào)用實際上會調(diào)用命令接收者的方法進(jìn)行實際調(diào)用。

7. 比如遙控器按鈕相當(dāng)于一條命令，點(diǎn)擊按鈕時命令運(yùn)行，自動調(diào)用電視機(jī)提供的方法即可。

</pre>

模板方法模式

<pre>

1. 模板方法一般指提供了一個方法模板，并且其中有部分實現(xiàn)類和部分抽象類，并且規(guī)定了執(zhí)行順序。

3. 實現(xiàn)類是模板提供好的方法。而抽象類則需要用戶自行實現(xiàn)。

5. 模板方法規(guī)定了一個模板中方法的執(zhí)行順序，非常適合一些開發(fā)框架，于是模板方法也廣泛運(yùn)用在開源框架中。

</pre>

觀察者模式和事件監(jiān)聽機(jī)制

<pre>

1. 觀察者模式一般用于訂閱者和消息發(fā)布者之間的數(shù)據(jù)訂閱。

3. 一般分為觀察者和主題，觀察者訂閱主題，把實例注冊到主題維護(hù)的觀察者列表上。

5. 而主題更新數(shù)據(jù)時自動把數(shù)據(jù)推給觀察者或者通知觀察者數(shù)據(jù)已經(jīng)更新。

7. 但是由于這樣的方式消息推送耦合關(guān)系比較緊。并且很難在不打開數(shù)據(jù)的情況下知道數(shù)據(jù)類型是什么。

9. 知道后來為了使數(shù)據(jù)格式更加靈活，使用了事件和事件監(jiān)聽器的模式，事件包裝的事件類型和事件數(shù)據(jù)，從主題和觀察者中解耦。

11. 主題當(dāng)事件發(fā)生時，觸發(fā)該事件的所有監(jiān)聽器，把該事件通過監(jiān)聽器列表發(fā)給每個監(jiān)聽器，監(jiān)聽得到事件以后，首先根據(jù)自己支持處理的事件類型中找到對應(yīng)的事件處理器，再用處理器處理對應(yīng)事件。

</pre>

責(zé)任鏈模式

<pre>

1. 責(zé)任鏈通常需要先建立一個單向鏈表，然后調(diào)用方只需要調(diào)用頭部節(jié)點(diǎn)就可以了，后面會自動流轉(zhuǎn)下去。

3. 比如流程審批就是一個很好的例子，只要終端用戶提交申請，根據(jù)申請的內(nèi)容信息，自動建立一條責(zé)任鏈，然后就可以開始流轉(zhuǎn)了。

</pre>