1、裝飾器模式

裝飾器模式主要解決在類實例化階段動態添加某些屬性和方法的問題，而不是在一開始就將所有的屬性都定義好。

實現方法：主要分為decorator和component，他兩都繼承自同一的抽象類，component一般是主要的類，而decorator則是對component不具有的功能的添加或增強。decorator會持有component對象并在自己的類中對該對象進行操作的到一個同類型的增強對象。

例子：JavaIOstream

2、單例模式

解決問題：一個類只能有一個實例化對象（因為有的資源只有一個，如果多個實例就會出現沖突）

實現方法：經典單例模式是將構造方法私有化，并自己持有本類的私有對象，不允許在類外面創建實例，只提供一個static getInstance 的靜態方法，在該方法中實例化該類并賦值給方法調用者。

優化：在多線程的情況下，可能還是會沖突? ?1.可以在getInstance 方法上加同步鎖（鎖很耗資源）；2.可以直接類中創建實例；3.雙重加鎖

3、委派模式

標準定義：委派模式的原理為類B和類A是兩個互相沒有任何關系的類，B具有和A一模一樣的方法和屬性，并且調用B中的方法、屬性就是調用A中同名的方法和屬性。B好像就是一個受A授權委托的中介。第三方的代碼不需要知道A的存在，也不需要和A發生直接的聯系，通過B就可以直接使用A的功能，這樣既能夠使用到A的各種功能，又能夠很好的將A保護起來，一舉兩得。

通俗理解：我們在項目開發中都是一個項目團隊，老板把任務交給項目經理后，項目經理制定項目計劃、將任務下發到底下的開發人員，這就是委派模式。但是我們發現這個跟之前學的代理模式非常相似，其實這也可以當做是靜態代理模式的一種特例。此外，項目經理接到任務后會做一個權衡，怎么去選擇分配這些任務。我們又發現這個跟之前學的策略模式非常相似，其實這也可以當做是策略模式的一種特例。（其實設計模式一般都不會獨立存在，都是混合使用）

委派模式跟靜態代理模式以及策略模式的區別？

委派模式：代理人全權負責這一件事。如：老板給項目經理安排任務，項目經理只是負責調度工作，真正干活的是底下的開發人員。

靜態代理模式：代理人只是參與被代理人一小部分的工作，最終的結論還是得由代理人來決定。如：張三沒空找對象，媒婆幫張三物色到一個對象，最終得看張三喜不喜歡這個對象。

策略模式：項目經理在分配任務的時候需要權衡，會產生多種分配方案，但是最終都是將手中的任務分配給底下的開發人員。

案例：spring中的DispatcherServlet