設計模式（簡單理解）

說在前頭。本文通過對js設計模式的學習，總結出一些基本看一遍就能明白的設計模式，不管前端還是後端的設計模式基本上都是這個原理，只是實現方法不一樣罷了。還有一些目前沒來得及總結，後面再補充。

單例模式：僅有乙個例項，呼叫時若無例項則建立例項，若有例項則重複利用

策略模式：將乙個個方法通過乙個公共方法組合起來，同時可以對這個組合裡的方法進行增加和修改，使用時來呼叫公共方法，由公共方法來呼叫某個具體方法。

**模式：**模式就是在訪問真正方法之前，先訪問**方法，由**方法進行一波操作驗證，再決定要不要訪問真正方法。

**模式主要有三種：保護**、虛擬**、快取**

保護**：在訪問真正的方法之前，先訪問**方法，通過**方法對這個訪問進行判斷，決定是否能訪問真正方法。

虛擬**：在訪問真正的方法之前，可以加入一些額外的邏輯操作，例如函式節流可以放在這裡。

快取**：在訪問真正的方法之前，尤其是對於一些開銷大的運算，先判斷**是否有快取，有的話直接返回，沒有再訪問真正方法，並快取到**方法中。

迭代器模式：按照順序，從物件中依次取出資料。

通過呼叫乙個方法就能順序訪問乙個物件中的各個元素，並不用暴露物件的內部表示，也並不關心迭代器內部實現，其實也就是在for迴圈外套了一層函式，一般使用較多的場景是遍歷物件，例如陣列的map和foreach方法已經內建了迭代器。

發布-訂閱模式（觀察者模式）：官方概念：定義了物件之間的一對多的依賴關係，當乙個物件的狀態發生改變時，所有依賴於它的物件都將得到通知

舉個現實世界的例子，給多個訓練有素的小狗狗起名字（這是訂閱），喊誰的名字誰就過來吃飯（這是發布）。

如果小狗狗名字都一樣，這時候如果喊這個名字，所有小狗狗就都會來吃飯；如果改為讓這個名字的小狗狗都坐下，所有小狗狗就都會坐下。

命令模式：官方概念：通過命令使得請求傳送者和請求接收者能夠消除彼此之間的耦合關係。

在看完一些文件之後，我所理解到的是當執行某個操作時，呼叫乙個命令方法，這個命令方法來呼叫具體的執行方法，來解決問題。

看到這裡一直有點蒙，消除耦合我理解，不在同乙個方法裡不就行了，把操作寫到具體執行的方法裡，需要時直接呼叫具體的執行方法就行了嘛，搞不懂為什麼還要多加一層。

冷靜之後，明白了一丟丟，好像寫到乙個方法裡和呼叫乙個方法來執行，在程式執行上，並沒有什麼區別，還是耦合的。

然後自己想了乙個例子，總算搞懂了。看一下下面這個例子。

普通寫法：我在樓下喊：aaa吃飯了，aaa聽到了並說ok，過了兩天我不喜歡和aaa吃飯了，我想喊bbb吃飯，我得重新喊，bbb吃飯了，像我這種懶人，不想一直換名字喊，怎麼辦。

命令模式：首先我買個機械人，設定一下喊aaa吃飯，然後我輸入命令：乾飯！機械人就幫我通知aaa去吃飯了；

過來兩天不喜歡和aaa吃飯了，設定一下喊bbb吃飯，我還輸入命令：乾飯 ！機械人就幫我通知bbb去吃飯了。

我只需要說乾飯就行了，並不需要說和誰一起；機械人只需要接到命令的時候，喊某某某吃飯就行了，並不需要知道誰讓它喊的。這才叫解耦！

組合模式：由兩部分組成，組合物件和葉物件，並且具有相同的資料結構，呼叫組合物件的方法時會遞迴呼叫葉物件的方法來處理。

模板方法模式：有兩部分組成，一部分是抽象父類，一部分是具體實現的子類，抽象父類定義一些方法，並固定好方法的執行順序，再將這些方法暴露出去，可以由子類來重寫。由於父類已經固定好執行順序，所以所有的子類執行方法順序還是一致的。

享元模式：與單例模式相似，是一種效能優化的模式，是用來減少共享物件的數量，如果存在多個相似的物件，可以將公共部分剝離開來，生成內部狀態多次復用；其餘部分在外部維護。

享元模式與單例模式區別：

級別不同：單例模式是類級別，享元模式是物件級別。

物件個數：單例模式嚴格控制只能有乙個示例物件，享元模式可以再次建立，也可以取快取物件。

共同點就是都節約記憶體資源，節省物件建立時間。

責任鏈模式：有點像中介軟體的感覺，可以避免多重if分支語句。將多個處理方法串起來，當前方法處理不了就呼叫下乙個方法，直到有方法處理為止，跟命令模式目的相似，也是為了避免傳送者和接受者之間的耦合。

中介者模式：增加乙個中介者物件，來將多個有關聯的物件聯絡起來，當乙個物件有變化時，只需要通知中介者就行，中介者會依次通知與之有關聯的物件。減少修改某個物件就得在多個物件內部修改的情況。

裝飾者模式：顧名思義，就是在物件上新增一些裝飾，在不改變物件本身功能的基礎上，增加額外的行為方法。

狀態模式：將事物的每種狀態都封裝成單獨的類，在處理的時候呼叫這個狀態類，這個狀態類來負責自身的行為。允許乙個物件在其內部改變它的行為。

舉個簡單的例子：開燈，起床；關燈，睡覺。

一般情況我們分用分支語句來處理，若開燈的時候起床，若關燈的時候就睡覺。

但是在狀態模式中，將開燈和關燈封裝成兩個類，開燈類自身的行為就是起床，關燈類自身的行為就是睡覺，這時候我們只需要呼叫開燈和關燈負責的行為，就能得到起床還是睡覺。

在複雜的場景中，呼叫方法，觸發某個行為，輸出這個行為的表現，這時候可以改變該行為，則再次呼叫的時候就會觸發改變之後行為的表現，以此類推。

介面卡模式：通過乙個方法，對不相容的部分進行適配。

例如投屏的時候如果需要vga介面，有vga介面的電腦能正常投屏，但是沒有vga介面的電腦則不能，這時候就需要提供轉接頭來適配。

外觀模式：為子系統提供乙個統一的入口，我們日常開發中最常用的應該就是這個了。

比如我們的工具類，對一系列方法，提供乙個統一的入口，根據這個入口呼叫某個具體工具方法。

簡單理解設計模式

1 什麼是設計模式 對特定問題的一種解決方案。注 特定問題 在軟體開發過程中重複出現的問題。解決方案 就是解決辦法，既解決問題的方式或方法。例子 醫生給病人看病，每一種病都是一種設計模式。比如乙個人感冒了，醫生給他開了感冒藥，這個感冒藥就是乙個設計模式。2 設計模式的組成 模式名稱 就是對每個設計模...

設計模式的簡單理解

1.建立型 1 單例 只需乙個例項時考慮。2 工廠方法 一般先用工廠方法解決物件建立問題。3 抽象工廠 當工廠方法無法滿足多系列問題時，再重構為抽象工廠。4 建造者 多個部件的建造實現相同，只是所需部件 建造順序不同時考慮。5 原型 在初始化資訊不發生變化時考慮。2.結構型 1 介面卡 讓介面不相容...

簡單理解設計模式之外觀模式

最近有點忙，沒什麼時間來寫部落格，所以一閒下來就想起來，還有很多的模式沒有跟大家一起分享，所以今天就來跟大家一起談談設計模式之外觀模式。1.什麼是外觀模式？說實話，平常我很少看見跟外觀模式有關的一些講解，也可能是我孤陋寡聞吧 閒話就不多說了，不管怎樣我們先來看看外觀模式的定義 為子系統的一組介面提供...