## <font class="h2">設計模式design pattern</font>

###### tags: `javascript`
<style>
.h2 {
background: linear-gradient(135deg,#fff,#537479) ;
color: #537479;
display:block;
padding: 6px 5px;
border-radius: 4px;
}
.h3 {
background: linear-gradient(180deg,#fff 50%,#c9d5d4) ;
color: #537479;
display:block;
padding: 6px 5px;
border-bottom: 3px solid #537479;
}
.h4 {
color: #537479;
font-weight:bold;
font-size:1.1em;
}
</style>
<br>

「設計模式」就是我們程式碼的有用結構(structure)、樣式(style)和模板(stencil)
<br><br>

### <font class="h3">物件導向設計SOLID 原則</font>

物件導向的世界中，有所謂的 SOLID Principles。這五項原則是 Design Patterns 的基礎
==主要是讓程式碼更容易閱讀、維護、擴充==
### <font class="h4">1. Single Responsibility Principle 單一職責原則:</font>
一個模組應該只對唯一的一個角色負責。


<br>

重構原則:
每個物件，不管是類別、函數，負責的功能，都應該只做一件事。
對函數而言，一個函數內，同時做了兩件以上的事情。當發生錯誤時，很難快速定位錯誤的原因。
另外，也容易間接導至程式碼的可閱讀性降低。

<br>

### <font class="h4">2. Open/Closed Principle 開放封閉原則</font>

**擴展是開放的，修改是封閉的(不能修改，只能新增)**
具體作法:
1. 將重要不可輕易改變的模組，避免外部修改
2. 將動態要時常變更的模組保留空間供後續調整

藉由增加新的程式碼來擴充系統的功能，而不是藉由修改原本已經存在的程式碼來擴充系統的功能。
當需求有異動時，要如何在不變動現在正常運行的程式碼，藉由**繼承、相依性**注入等方式，增加新的程式碼，以實作新的需求。
假若為了新需求，去修改了原本的程式中的某一個函數，可能會造成其他呼叫使用該函數的的功能，出現非預期的錯誤。

降低程式碼耦合(相依關係)變動

<br>

### <font class="h4">3. Liskov Substitution Principle 里氏替換原則</font>

簡單來說，當實作繼承了 interface 或 base-class的 sub-class，那麼在程式中，只要出現該 interface 或 base-class 的部份，都可以用 sub-class 替換。

<br>

### <font class="h4">4. Interface Segregation Principle 介面隔離原則</font>

針對不同需求的用戶，開放其對應需求的介面，提拱使用。可避免不相關的需求介面異動，造成被強迫一同面對異動的情況
<br>

### <font class="h4">5. Dependency Inversion Principle 依賴反轉原則</font>

當 A 模組在內部使用 B 模組的情況下，我們稱 A 為高階模組，B 為低階模組。高階模組不應該依賴於低階模組，兩者都該依賴抽象介面。

:::info
要特別提醒的是，符合 SOLID 的開發方式，雖然較易維護與擴展。但就實務面而言，有時，必需考量使用 SOLID 額外帶來的開發時間，是否是開發期程所能承受的。
:::

<br><br>

### <font class="h3">Gof提出的23種Design Pattern</font>
設計模式：可復用物件導向軟體的基礎
Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides，後以「四人幫」（Gang of Four，GoF）著稱

| 創建型 (Creational Patterns) | 結構型 (Structural Patterns) | 行為型 (Behavioral Patterns) |
| ---------------------------- | ---------------------------- | ------------------------------ |
| Abstract Factory 抽象工廠 | Adapter 轉接器 | Chain of Responsibility 責任鏈 |
| Builder 建造者 | Bridge 橋接 | Command 命令 |
| Factory Method 工廠方法 | Composite 組合 | Interpreter 直譯器 |
| Prototype 原型 | Decorator 裝飾者 | Iterator 迭代器 |
| Singleton 單例 | Facade 門面 | Mediator 中介者 |
| | Flyweight 享元 | Memento 備忘錄 |
| | Proxy 代理 | Observer 觀察者 |
| | | State 狀態 |
| | | Strategy 策略 |
| | |Visitor 訪問者 |

<br><br>

<br><br>

---
https://ithelp.ithome.com.tw/articles/10191553
https://waynecheng.coderbridge.io/2021/01/09/DesignPattern-Preface/

https://github.com/Hsueh-Jen/blog/issues/7

https://ithelp.ithome.com.tw/articles/10216587

https://wyattkidd.medium.com/%E7%BF%BB%E8%AD%AF-javascript-%E8%A8%AD%E8%A8%88%E6%A8%A1%E5%BC%8F-fca4e2e16752

https://www.youtube.com/watch?v=pkm5jQfnKGs&ab_channel=%E5%9C%A8%E5%9C%B0%E4%B8%8A%E6%BB%BE%E7%9A%84%E5%B7%A5%E7%A8%8B%E5%B8%ABNic