設(shè)計(jì)模式是很多前人留下的經(jīng)驗(yàn)總結(jié)，這些模式都是很典型的也是很有代表意義的。因此掌握好設(shè)計(jì)模式是提高個(gè)人技術(shù)能力的捷徑。設(shè)計(jì)模式要全部掌握，必須進(jìn)行不斷的總結(jié)和實(shí)現(xiàn)，傻蛋最近總結(jié)了一下23種（+簡(jiǎn)單工廠）設(shè)計(jì)模式的索引，以方便大家明白各種模式都有什么作用，在遇到問題的時(shí)候能夠迅速地找到解決方案，同時(shí)加以使用，以便能夠更快的掌握。

1.Simple Factory（簡(jiǎn)單工廠）：:提供一個(gè)創(chuàng)建對(duì)象實(shí)例的集合，而無須關(guān)心其具體實(shí)現(xiàn)。被創(chuàng)建的類型可以是接口、抽象類也可以是具體類。 簡(jiǎn)單工廠的本質(zhì)：選擇實(shí)現(xiàn)。 2.Facade（外觀）：為子系統(tǒng)中的一組接口提供了一個(gè)統(tǒng)一一致的界面，該模式定了一個(gè)高層接口，這個(gè)接口使得這一子系統(tǒng)更加容易使用。 外觀模式的本質(zhì)：封裝交互，簡(jiǎn)化應(yīng)用。 3.Adapter（適配器）：將一個(gè)類的接口裝換成客戶希望的另外一個(gè)接口。適配器模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。 適配器模式的本質(zhì)：轉(zhuǎn)換匹配，服用功能。 4.Singleton（單例）：保證一個(gè)類僅有一個(gè)實(shí)例，并提供一個(gè)訪問它的全局訪問點(diǎn)。 單例模式的本質(zhì):控制實(shí)例的數(shù)目。 5.Factory Method（工廠方法）：定義一個(gè)用于創(chuàng)建對(duì)象的接口，讓子類來決定實(shí)例化哪一個(gè)類，該模式使一個(gè)類的實(shí)例化延遲到子類，即是讓父類在不知道具體實(shí)現(xiàn)的情況下，完成自身的功能調(diào)用，具體的實(shí)現(xiàn)延遲到子類。 工廠方法的本質(zhì)：延遲到子類來選擇實(shí)現(xiàn)。

?

6.Abstract Factory（抽象工廠）：提供了一個(gè)創(chuàng)建一系列相關(guān)或者“相互依賴對(duì)象的接口”，而無需指定他們的具體類。也就是說既要?jiǎng)?chuàng)建接口的對(duì)象，同時(shí)還要約束它們之間的關(guān)系。可以類比創(chuàng)建主板和CPU對(duì)象，但是Intel的CPU只能插在支持Intel主板的插槽上面。在實(shí)現(xiàn)App的DAO的時(shí)候，通常可以使用抽象工廠結(jié)合工廠方法的方式來實(shí)現(xiàn)。 抽象工廠的本質(zhì)：選擇產(chǎn)品簇的實(shí)現(xiàn)。 7.Builder（構(gòu)建者）：將一個(gè)復(fù)雜的對(duì)象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。類比文件的導(dǎo)出問題，每種文件都有文件的頭、文件Body、和文件尾和最終的導(dǎo)出，所以對(duì)于不同的文件的構(gòu)建方式相同但是表現(xiàn)方式不同。 構(gòu)建者模式的本質(zhì):分離整體構(gòu)建算法和部件的構(gòu)造。 8.Prototype（原型）：用原型實(shí)例創(chuàng)建對(duì)象的種類，并通過copy這些原型創(chuàng)建新的對(duì)象。會(huì)用到Clone方法。類比處理訂單（大訂單分成若干個(gè)小的訂單）問題，訂單有企業(yè)訂單和個(gè)人訂單，其實(shí)其操作過程是相似的。 原型模式的本質(zhì)：克隆生成對(duì)象。 9.Mediator（中介）： 用一個(gè)中介對(duì)象來封裝一系列的對(duì)象交互。中介者使得各個(gè)對(duì)象不需要顯示地相互引用，從而使其耦合松散，而且可以獨(dú)立地改變它們之間的交互。類比主板用于和各種配件之間交流，而不需要各種配件之間交流。當(dāng)處理部門和員工之間關(guān)系時(shí)，此模式就很好，比如部門的解散會(huì)影響到部門中的人員，部門和人員之間實(shí)現(xiàn)了緊耦合，使用中介者就可以變?yōu)樗神詈?#xff0c;部門不知道員工，員工不知道處于哪個(gè)部門。 中介模式的本質(zhì)：封裝交互。 10.Proxy（代理）：為其他對(duì)象提供一種代理以控制對(duì)這個(gè)對(duì)象的訪問。如spring中的AOP。或者對(duì)于大數(shù)據(jù)量列表的加載，當(dāng)需要知道某條數(shù)據(jù)的詳細(xì)信息的時(shí)候才通過Proxy來訪問真實(shí)對(duì)象。 代理模式的本質(zhì)：控制對(duì)象的訪問。 11.Observer（觀察者）:定義對(duì)象之間的一種一對(duì)多的依賴關(guān)系。當(dāng)目標(biāo)對(duì)象發(fā)生狀態(tài)的改變時(shí)，所有的觀察者對(duì)象都會(huì)得到通知，從而自動(dòng)更新。 觀察者模式的本質(zhì)：觸發(fā)聯(lián)動(dòng) 12.Command（命令）: 客戶端只是想要發(fā)出命令或者請(qǐng)求，而不關(guān)心請(qǐng)求的真正接收者是誰，也不關(guān)心具體的實(shí)現(xiàn)是如何的，而且對(duì)于同一個(gè)請(qǐng)求的動(dòng)作可以有不同的請(qǐng)求內(nèi)容，當(dāng)然具體的處理功能也就不同。所以命令模式就是將一個(gè)請(qǐng)求封裝成一個(gè)對(duì)象，從而可以使你可以用不同的請(qǐng)求對(duì)客戶的請(qǐng)求進(jìn)行參數(shù)化，請(qǐng)求可以進(jìn)行排隊(duì)，同時(shí)也支持請(qǐng)求的“可撤銷操作”。 命令模式可以用于宏命令，就是一個(gè)大的命令中包含著一組小的命令。同時(shí)也可以處理隊(duì)列請(qǐng)求，就是指對(duì)命令的對(duì)象進(jìn)行排隊(duì)，組成工作隊(duì)列，然后依次取出命令對(duì)象來進(jìn)行執(zhí)行。 命令模式的本質(zhì)：封裝請(qǐng)求。 13.Iterator（迭代器）：提供一個(gè)方法順序的訪問一個(gè)聚合對(duì)象中的各個(gè)元素，而又不需要暴露該對(duì)象的內(nèi)部表示。迭代器模式對(duì)于處理對(duì)數(shù)據(jù)庫數(shù)據(jù)的翻頁等事件是很好的，傳統(tǒng)的方式有二：1.每翻一頁就請(qǐng)求一次數(shù)據(jù)庫。2.把所有數(shù)據(jù)都加載在數(shù)據(jù)庫中。而迭代模式可以很好的實(shí)現(xiàn)一次訪問數(shù)據(jù)庫，就只趣比如10頁，這樣就不用每次都從數(shù)據(jù)庫中取了。既節(jié)省了時(shí)間，也節(jié)省了內(nèi)存。 迭代器模式的本質(zhì)：控制訪問聚合對(duì)象中的元素。 14.Composite（組合）：組合模式主要用于表示“樹-葉子”的層次結(jié)構(gòu)，組合模式使得用戶對(duì)單個(gè)對(duì)象和組合對(duì)象的使用具有一致性，既組合模式通過引入一個(gè)抽象類，作為樹類別和葉子別的父類，這樣就把樹對(duì)象和葉子對(duì)象統(tǒng)一起來，用戶在使用的時(shí)候，始終是在操作此抽象的組件對(duì)象而不用區(qū)分其實(shí)樹對(duì)象還是葉子對(duì)象。其最關(guān)鍵的還是這個(gè)抽象類，這樣無論是對(duì)樹操作還是葉子操作都具有了一致性。 組合模式的本質(zhì)：統(tǒng)一葉子對(duì)象和樹對(duì)象 15.Template Method（模板方法）：定義一個(gè)操作中的算法骨架，從而讓將一些方法的實(shí)現(xiàn)延遲到子類中，在不同的子類中，對(duì)這些方法的實(shí)現(xiàn)可以進(jìn)行重寫。對(duì)于用有很多重復(fù)、相似的操作的業(yè)務(wù)處理，就可以用這個(gè)方法。 在Java中通常就使用 繼承的方法和回調(diào)的方式，使得父類可以訪問子類的方法，所以模板方法有兩種實(shí)現(xiàn)方式，繼承的方式和回調(diào)的方式，繼承的方式相對(duì)簡(jiǎn)單，而回調(diào)的方式相對(duì)地靈活。 模板方法的本質(zhì)：固定算法骨架。 16.Strategy（策略）：定義一系列的算法，并把它們一個(gè)個(gè)地封裝起來，并且使它們可以相互替換，本模式可以使算法可以獨(dú)立于使用它的客戶端的變化而變化。策略的重心不是如何來實(shí)現(xiàn)算法，而是如何組織、調(diào)用這些算法，從而讓程序結(jié)構(gòu)更加靈活，具有更好的擴(kuò)展性。 策略的本質(zhì)是：分離算法、選擇實(shí)現(xiàn)。 17.State（狀態(tài)模式）：允許一個(gè)對(duì)象在其內(nèi)部狀態(tài)改變時(shí)改變它的行為。對(duì)象看起來似乎修改了它的類。即對(duì)于同一個(gè)業(yè)務(wù)，在各個(gè)狀態(tài)下的處理基本上都是不同的，因此把每個(gè)狀態(tài)所對(duì)應(yīng)的功能處理封裝在一個(gè)獨(dú)立的類中，這樣在選擇不同處理的時(shí)候，其實(shí)就是在選在不同的狀態(tài)處理類。 狀態(tài)模式的本質(zhì)：根據(jù)狀態(tài)來分離和選擇行為。 18.Memento（備忘錄模式）：在不破壞封裝性的前提下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)。這樣以后就可以將該對(duì)象恢復(fù)到原先保存的狀態(tài)。備忘錄的典型應(yīng)用是 離線存儲(chǔ)。 備忘錄模式的本質(zhì)：保存和恢復(fù)內(nèi)部狀態(tài)。 19.Flyweigth（享元模式）：運(yùn)用共享技術(shù)有效地支持大量細(xì)粒度的對(duì)象。典型的應(yīng)用就是對(duì)權(quán)限的控制。 享元模式的本質(zhì)：運(yùn)用共享技術(shù)有效地支持大量細(xì)粒度的對(duì)象。 20.Interpreter（解釋器模式）：當(dāng)讀取xml時(shí)，xml文件發(fā)生了改變，相應(yīng)的解釋程序也會(huì)發(fā)生改變。用來解決這個(gè)問題的方法是解釋器模式。相當(dāng)于定義一個(gè)語言，同時(shí)定義一個(gè)它的語法表示，并且定義一個(gè)解釋器，這個(gè)解釋器就是用該表示來解釋語言中的句子。 解釋器模式的本質(zhì)：分離實(shí)現(xiàn)、解釋執(zhí)行。 21.Decorator（裝飾模式）：動(dòng)態(tài)地給一個(gè)對(duì)象添加一些額外得職責(zé)。對(duì)增加功能來說，裝飾模式比生成子類更為靈活。裝飾模式也能用來實(shí)現(xiàn)AOP。 裝飾模式的本質(zhì)：動(dòng)態(tài)組合。 22.Chain of Responsibility（責(zé)任鏈）：使多個(gè)對(duì)象都有機(jī)會(huì)來處理請(qǐng)求，從而避免請(qǐng)求的發(fā)送者和接收者的耦合關(guān)系。將這些對(duì)象連成一條鏈，并沿著這條鏈傳遞該請(qǐng)求，知道有個(gè)一對(duì)象處理它為止。責(zé)任鏈模式主要是用來處理。責(zé)任鏈就是用來處理 客戶端發(fā)來一個(gè)請(qǐng)求，有多個(gè)對(duì)象都有機(jī)會(huì)來處理這個(gè)請(qǐng)求，但是客戶端不知道究竟是誰來處理這個(gè)對(duì)象。這樣就實(shí)現(xiàn)了請(qǐng)求者和接收者解耦，這樣就可以動(dòng)態(tài)地切換和組合接收者了。 責(zé)任鏈的本質(zhì)：分離職責(zé)，自由組合。 23.Bridge（橋接模式）：將抽象部分和它的實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立的變化。所謂橋接就是在抽象和實(shí)現(xiàn)之間搭橋，讓它們能夠連接起來，可以相互通訊。抽象一定是要實(shí)現(xiàn)的，所以就需要搭一個(gè)橋，讓抽象部門通過這個(gè)橋就可以調(diào)用到實(shí)現(xiàn)部分的功能，這樣就實(shí)現(xiàn)了抽象和實(shí)現(xiàn)的徹底分離，抽象部分和實(shí)現(xiàn)部分可以獨(dú)立的變化。 橋接模式的本質(zhì)：分離抽象和實(shí)現(xiàn)。 24.Visitor（訪問者）：作用于某個(gè)對(duì)象中各個(gè)元素的操作，它使在不改變各個(gè)元素的類得前提下定義作用于這些元素的操作。 訪問者模式的本質(zhì)：預(yù)留通路，回調(diào)實(shí)現(xiàn)。

?

總結(jié)

以上是生活随笔為你收集整理的23种设计模式的索引的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。