程序員的修仙之路——“設計模式之道”！

設計模式是一套被反復使用的、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式的目的就是為了重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。歡迎小伙伴們關注，持續(xù)分享更多優(yōu)質干貨！

設計模式之道

何為設計模式？

設計模式的分門別類

1、原型(Prototype)模式

2、工廠方法(Factory Method）模式

3、抽象工廠(AbstractFactory) 模式

4、單例(Singleton)設計模式

5、生成器(Builder)模式

6、適配器(Adapter Pattern)模式

7、橋接(Bridge)模式

8、外觀(Facack) 模式

9、中介者(Mediator)模式

10、觀察者(Observer)模式

11、組合(Composite)模式

12、迭代器(Iterator Pattern)模式

13、訪問者(Visitor Pattern)模式

14、裝飾器(Decorator)模式

15、責任鏈(Chain of Responsibility)模式

16、狀態(tài)(State Pattern)模式

17、策略(Strategy)模式

18、命令(Command) 模式

19、享元(Flyweight)模式

20、代理(Proxy Pattern)模式

21、備忘錄(Memento Pattern)模式

寫在前面

Hello，你好呀，我是灰小猿！一個超會寫bug的程序猿！

提到設計模式，相信小伙伴們一定都不會陌生，而且在很多在公司的崗位要求上，都會要求我們或多或少的掌握或使用過幾個設計模式。今天我就和大家一起來就21種設計模式的最通俗的定義和使用場景進行分析，勢必與面試官掰扯到底！！！

何為設計模式？

首先，何為設計模式（養(yǎng)生之道）？且聽一一分解！

設計模式（Design pattern）代表了一種最佳的實踐，通常被有經驗的面向對象的軟件開發(fā)人員所采用。設計模式是軟件開發(fā)人員在軟件開發(fā)過程中面臨的一般問題的一種解決方案。這些解決方案是眾多軟件開發(fā)人員經過相當長的一段時間的試驗和錯誤總結出來的。所以毋庸置疑，單單從字面意思就知道，設計模式是用來解決開發(fā)中遇到的難題的。

設計模式也是一套被反復使用的、多數人知曉的、經過分類編目的、代碼設計經驗的總結。看這一句是不是就已經知道了設計模式的定義了呢？使用設計模式的目的就是為了重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 也可以說是為了簡化開發(fā)而誕生的。毫無疑問，設計模式對于開發(fā)者和對于系統(tǒng)來說都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。項目中合理地運用設計模式可以完美地解決很多問題，每種模式在現實中都有相應的原理來與之對應，每種模式都描述了一個在我們周圍不斷重復發(fā)生的問題，以及該問題的核心解決方案，這也是設計模式能被廣泛應用的原因。

聽了這么多概念，是不是也不一定記得住？沒關系！記住設計模式是為了在遇到問題時能簡化開發(fā)，盡快解決的就行了。

設計模式的分門別類

上面也說到了，設計模式是經過分類編目的，那么它就一定是有很多種分類的，所以按照這21種設計模式的使用場景和特點，可以分為以下八種！

對象創(chuàng)建型：1.原型模式；2.工廠模式；3.抽象工廠模式；4.單例模式；5.生成器

接口適配型：1.適配器模式；2.橋接模式；3.外觀模式

對象去耦型：1.中介者模式；2.觀察者模式

抽象集合型：1.組合模式；2.迭代器模式

行為擴展型：1.訪問者模式；2.裝飾器模式；3.責任鏈模式

算法封裝型：1.模版方法模式；2.策略模式；3.命令模式

性能與對象訪問型：1.享元模式；2.代理模式

對象狀態(tài)型：1.備忘錄模式

是不是也覺得很多記不住啦？沒關系啦！其實對于這些設計模式，還有一個簡單的分類，就是按照使用目的劃分為的三類：

對象創(chuàng)建型（creational）：主要用于處理對象的創(chuàng)建，實例化對象

結構處理型（structural）：處理類或對象間的組合

行為描述型（behavioral）：描述類或對象怎樣進行交互和職責分配

其中：

對象創(chuàng)建型包括：工廠方法模式、抽象工廠模式、單例模式、生成器模式、原型模式

結構處理型包括：裝飾器模式、適配器模式

行為描述型包括：觀察者模式

按照分類只記住這幾種就會簡單一些。其實每一種設計模式都有屬于它的特點和應用場景，經過反復的練習，掌握每一種設計模式的定義和應用場景，應對簡單的面試還是沒有問題的。最重要的就是之后合理使用其來開發(fā)項目，應用到實戰(zhàn)中，徹徹底底的秀面試官一臉！

接下來就來和大家介紹一下這21種設計模式的基本定義和適用場景，記住這個對于之后熟練使用設計模式是很有幫助的！

1、原型(Prototype)模式

定義：原型(Prototype)模式用原型實例指定創(chuàng)建對象的種類，并且通過拷貝這個原型來創(chuàng)建新的對象。

適用場景：

當一個系統(tǒng)應該獨立于它的產品創(chuàng)建、構成和表示時;

當要實例化的類是在運行時刻指定時,例如，通過動態(tài)裝載;

為了避免創(chuàng)建一個與產品類層次平行的工廠類層次時;

當一個類的實例只能有幾個不同狀態(tài)組合中的一種時，建立相應數目的原型并克隆它們可能比每次用合適的狀態(tài)手工實例化該類更方便一些。

2、工廠方法(Factory Method）模式

定義：工廠方法(Factory Method）模式定義一個用于創(chuàng)建對象的接口，讓子類決定將哪一個類實例化，使一個類的實例化延遲到其子類。

適用場景：

當一個類不知道它所必須創(chuàng)建的對象的類的時候;

當一個類希望由它的子類來指定它所創(chuàng)建的對象的時候;

當類將創(chuàng)建對象的職責委托給多個幫助子類中的某一個，并且你希望將哪一個幫助子類是代理者這一信息局部化的時候。

3、抽象工廠(AbstractFactory) 模式

定義：抽象工廠(AbstractFactory) 模式提供一個創(chuàng)建一系列相關或相互依賴對象的接口，而無需指定他們具體的類。

適用場景：

一個系統(tǒng)要獨立于它的產品的創(chuàng)建、組合和表示時;

一個系統(tǒng)要由多個產品系列中的一-個來配置時;

當要強調一系列相關的產品對象的設計以便進行聯(lián)合使用時:

當提供一個產品類庫,而只想顯示它們的接口而不是實現時。

4、單例(Singleton)設計模式

定義：單例(Singleton)設計模式是一種創(chuàng)建型模式，其意圖是保證一個類僅有一個實例，并提供一個訪問這個唯一實例的全局訪問點。

適用場景：

當類只能有一個實例而且客戶可以從一個眾所周知的訪問點訪問它時;

當這個唯一實例應該是通過子類化可擴展的，并且客戶應該無須更改代碼就能使用一個擴展的實例時。

5、生成器(Builder)模式

定義：生成器(Builder)模式將一個復雜對象的構建與它的表示分離,使得同樣的構建過程可以創(chuàng)建不同的表示。

適用場景：

當創(chuàng)建復雜對象的算法應該獨立于該對象的組成部分以及它們的裝配方式時;

當構造過程必須允許被構造的對象有不同的表示時。

6、適配器(Adapter Pattern)模式

定義：適配器模式將類的接口轉換成客戶希望的另外一個接口，目的是消除由于接口不匹配所造成的類的兼容性問題。

適用場景：

已有類的接口與需求類接口不匹配。

借助一個抽象類，不必實現接口中的全部方法

7、橋接(Bridge)模式

定義：橋接模式把抽象層次結構從實現中分離出來，使其能夠獨立變更。抽象層定義了供客戶端使用的上層抽象接口。實現層次結構定義了供抽象層次使用的底層接口。

適用場景：

當一個類存在兩個獨立變化的維度，且這兩個維度都需要進行擴展時。

當一個系統(tǒng)不希望使用繼承或因為多層次繼承導致系統(tǒng)類的個數急劇增加時。

當一個系統(tǒng)需要在構件的抽象化角色和具體化角色之間增加更多的靈活性時。

8、外觀(Facack) 模式

定義：外觀(Facack) 模式為子系統(tǒng)中的一組接口提供一個致的界面，Facade模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用。

適用場景:

要為一個復雜子系統(tǒng)提供一個簡單接口時，子系統(tǒng)往往因為不斷演化而變得越來越復雜;

客戶程序與抽象類的實現部分之間存在著很大的依賴性;

當需要構建一個 層次結構的子系統(tǒng)時，使用facade模式定義子系統(tǒng)中每層的入口點。

9、中介者(Mediator)模式

定義：中介者(Mediator)模式用一個中介對象來封裝系列的對象交互。中介者使各對象不需要顯式地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互。

適用場景:

一組對象以定義良好但是復雜的方式進行通信，產生的相互依賴關系結構混亂且難以理解;

一個對象引用其他很多對象并且直接與這些對象通信,導致難以復用該對象;

想定制一個分布在多個類中的行為，而又不想生成太多的子類。欲使一個后端數據模型能夠被多個前端用戶界面連接,采用中介者模式最合適。

10、觀察者(Observer)模式

定義：觀察者(Observer) 模式定義對象間的一種一對多的依賴關系，當一個對象的狀態(tài)發(fā)生改變時，所有依賴于它的對象都得到通知并被自動更新。

適用場景：

當一個抽象模型有兩個方面，其中一個方面依賴于另一-個方面，將這兩者封裝在獨立地對象中以使它們可以各自獨立地改變和復用;

當對一個對象的改變需要同時改變其他對象，而不知道具體有多少對象有待改變時;

當一個對象必須通知其他對象，它又不能假定其他對象是誰，即:不希望這些對象是緊耦合的。

11、組合(Composite)模式

定義：組合模式將對象組合成樹形結構以表示“部分-整體"的層次結構，使得用戶對單個對象和組合對象的使用具有一致性。

適用場景:

想表示對象的部分-整體層次結構;

希望用戶忽略組合對象與單個對象的不同，用戶將統(tǒng)一地使用組合結構中的所有對象。

12、迭代器(Iterator Pattern)模式

定義：迭代器提供了一種順序訪問聚合對象（集合）中元素的方法，而無需暴露結構的底層表示和結構細節(jié)。 遍歷集合元素的任務從集合 轉移給了迭代器對象。

適用場景：

需要訪問組合對象內容，而不想暴露內部表示、結構。

注意：迭代器分為內部迭代器和外部迭代器。

外部迭代器允許客戶端更自由的使用，同時需要熟悉組合對象的內部結構。

內部迭代器被封裝在集合內部，在集合外部提供接口。

集合對象（nsarray, nsdictionary）都默認提供了迭代器。

13、訪問者(Visitor Pattern)模式

定義：訪問者模式作用于組合對象結構中的每一個元素的操作，它讓我們在不改變元素類的前提下，擴展這些類的新操作。在接受訪問者的接口方法中，實現將元素傳給訪問者，然后訪問者擴展對元素的操作。

適用場景：

想對一個對象進行很多不相關的操作，又不想污染這個對象。

14、裝飾器(Decorator)模式

定義：裝飾器模式描述了以透明圍欄來支持修飾的類和對象的關系，動態(tài)地給一個對象添加一些額外的職責，從增加功能的角度來看，裝飾器模式相比生成子類更加靈活。

適用場景:

在不影響其他對象的情況下，以動態(tài)、透明的方式給單個對象添加職責;

處理那些可以撤銷的職責;當不能采用生成子類的方式進行擴充時。

15、責任鏈(Chain of Responsibility)模式

定義：責任鏈模式使多個對象都有機會處理請求，從而避免請求的發(fā)送者和接收者之間的耦合關系。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，直到有一個對象處理它為止。

適用場景：

有多個的對象可以處理一個請求，哪個對象處理該請求在運行時刻自動確定;

在不明確指定接收者的情況下，向多個對象中的一個提交一個請求;

可處理-個請求的對象集合應被動態(tài)指定。

16、狀態(tài)(State Pattern)模式

定義：允許對象在內部狀態(tài)發(fā)生改變時改變它的行為，對象看起來好像修改了它的類。對象的行為依賴于它的狀態(tài)（屬性），并且可以根據它的狀態(tài)改變而改變它的相關行為。

適用場景：

行為隨狀態(tài)改變而改變的場景。

條件、分支語句的代替者。

17、策略(Strategy)模式

定義：策略模式定義一系列的算法，把它們一個個封裝起來，并且使它們可以相互替換。此模式使得算法可以獨立于使用它們的客戶而變化，

適用場景：

許多相關的類僅僅是行為有異。“策略”提供了一種用多個行為中的一個行為來配置一個類的方法;

需要使用-個算法的不同變體。例如，定義一些反應不同空間的空間/時間權衡的算法。當這些變體實現為一一個算法的類層次時，可以使用策略模式;

算法使用客戶不座該知道的數據。可使用策略模式以避免暴露復雜的、與算法相關的數據結構;

一個類定義了多種行為，并且這些行為在這個類的操作中以多個條件語句的形式出現，將相關的條件分支移入它們各自的Strategy類中，以代替這些條件語旬。

18、命令(Command) 模式

定義：命令模式將一個請求封裝為一個對象，從而使得可以用不同的請求對客戶進行參數化;對請求排隊或記錄請求日志，以及支持可撤銷的操作。

適用場景：

抽象出待執(zhí)行的動作以參數化某對象，此模式是過程語言中的回調(callback) 機制的一個面向對象的替代方式;

在不同的時刻指定、排列和執(zhí)行請求;

支持取消操作;

支持修改日志，這樣當系統(tǒng)崩潰時，這些修改可以被重做一遍;

用構建在原語操作上的高層操作構造一個系統(tǒng)。

19、享元(Flyweight)模式

定義：享元模式運用共享技術有效地支持大量細粒度的對象。

適用場景:

一個應用程序使用了大量的對象;

完全由于使用大量的對象，造成很大的存儲開銷;

對象的大多數狀態(tài)都可變?yōu)橥獠繝顟B(tài);

如果刪除對象的外部狀態(tài)，那么可以用相對較少的共享對象取代很多組對象:

應用程序不依賴于對象標識。

20、代理(Proxy Pattern)模式

定義：通過提供與對象相同的接口來控制對這個對象的訪問，以使得在確實需要這個對象時才對它進行創(chuàng)建和初始化。

代理模式可以分為遠程代理和虛擬代理。

遠程代理：用本地對象代替遠程對象。如：發(fā)送網絡時的代理服務器。

虛擬代理：將代理直接面向客戶端，使客戶端認為操作的虛擬代理就是真實對象。虛擬代理提供占位對象和重型對象。默認使用占位對象，當需要使用重型對象時才加載。

適用場景：

遠程代理，這種方式通常是為了隱藏目標對象存在于不同地址空間的事實，方便客戶端訪問。

虛擬代理，這種方式通常用于要創(chuàng)建的目標對象開銷很大時。

安全代理，這種方式通常用于控制不同種類客戶對真實對象的訪問權限。

智能指引，主要用于調用目標對象時，代理附加一些額外的處理功能。

延遲加載，指為了提高系統(tǒng)的性能，延遲對目標的加載。

使用實例：

Object-C不支持多繼承，如果代理對象不是NSObject的子類的話，可以考慮用NSProxy來作為占位或者替代對象。盡管NSProxy也是NSObject類型，但是NSProxy的作用就是當代理。

21、備忘錄(Memento Pattern)模式

定義：在不破壞原有封裝的前提下，捕獲一個對象的內部狀態(tài)，并在該對象之外保存狀態(tài)。 這樣，之后可將對象恢復到之前的狀態(tài)。將狀態(tài)封裝成對象保存。

適用場景：

需要保存對象在某一時刻的狀態(tài)（或部分狀態(tài)），這樣以后就可以恢復到先前的狀態(tài)。

提供一個可回滾的操作

使用實例：

Cocoa Touch框架在歸檔，屬性列表序列化，核心數據中采用了備忘錄模式。

好了，關于21種設計模式的講解就先分享這些，掌握了這些基本理論，和面試官掰扯幾個回合應該是沒問題了，之后就看你如何機智的使用設計模式開發(fā)項目了！

關于設計模式有問題的小伙伴們可以在評論區(qū)留言提出！

覺得不錯記得關注喲！

灰小猿陪你一起進步呀！

開發(fā)者 軟件開發(fā)

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現本站中有涉嫌抄襲或描述失實的內容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。