享元模式(Flyweight)
享元模式
意圖：運(yùn)用共享技術(shù)有效地支持大量細(xì)粒度的對象。
主要解決：在有大量對象時，有可能會造成內(nèi)存溢出，我們把其中共同的部分抽象出來，如果有相同的業(yè)務(wù)請求，直接返回在內(nèi)存中已有的對象，避免重新創(chuàng)建。
代理模式(Proxy)
代理模式
意圖：為其他對象提供一種代理以控制對這個對象的訪問。
主要解決：在直接訪問對象時帶來的問題，比如說：要訪問的對象在遠(yuǎn)程的機(jī)器上。在面向?qū)ο笙到y(tǒng)中，有些對象由于某些原因（比如對象創(chuàng)建開銷很大，或者某些操作需要安全控制，或者需要進(jìn)程外的訪問），直接訪問會給使用者或者系統(tǒng)結(jié)構(gòu)帶來很多麻煩，我們可以在訪問此對象時加上一個對此對象的訪問層。
橋接模式(Bridge)
橋接模式
意圖：將抽象部分與實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立的變化。
主要解決：在有多種可能會變化的情況下，用繼承會造成類爆炸問題，擴(kuò)展起來不靈活
組合模式(Composite)
組合模式
意圖：將對象組合成樹形結(jié)構(gòu)以表示"部分-整體"的層次結(jié)構(gòu)。組合模式使得用戶對單個對象和組合對象的使用具有一致性。
主要解決：它在我們樹型結(jié)構(gòu)的問題中，模糊了簡單元素和復(fù)雜元素的概念，客戶程序可以向處理簡單元素一樣來處理復(fù)雜元素，從而使得客戶程序與復(fù)雜元素的內(nèi)部結(jié)構(gòu)解耦。
裝飾器模式(Decorator)
裝飾器模式
意圖：動態(tài)地給一個對象添加一些額外的職責(zé)。就增加功能來說，裝飾器模式相比生成子類更為靈活。
主要解決：一般的，我們?yōu)榱藬U(kuò)展一個類經(jīng)常使用繼承方式實(shí)現(xiàn)，由于繼承為類引入靜態(tài)特征，并且隨著擴(kuò)展功能的增多，子類會很膨脹。
適配器模式(Adapter)
適配器模式
意圖：將一個類的接口轉(zhuǎn)換成客戶希望的另外一個接口。適配器模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。
主要解決：主要解決在軟件系統(tǒng)中，常常要將一些"現(xiàn)存的對象"放到新的環(huán)境中，而新環(huán)境要求的接口是現(xiàn)對象不能滿足的。
門面模式(Facade)
門面模式
意圖：為子系統(tǒng)中的一組接口提供一個一致的界面，外觀模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用。
主要解決：降低訪問復(fù)雜系統(tǒng)的內(nèi)部子系統(tǒng)時的復(fù)雜度，簡化客戶端與之的接口。
