閑談設計模式

Intro

設計模式（Design Pattern）是一套被反復使用、多數人知曉的、經過分類的、代碼設計經驗的總結。

了解這些前輩們總結出來的經驗有助于幫助你寫出來更優秀的代碼，幫助你寫出可擴展、可讀、可維護的高質量代碼。

在極客時間里推出了數據結構和設計模式的王爭說了一句話，如果說“數據結構與算法之美”是教你寫出高效的代碼，那設計模式就是教你寫出高質量的代碼。

為什么要學習設計模式

提升自己代碼質量，告別寫被人吐槽的爛代碼

提高復雜代碼的設計和開發能力，設計出擴展性良好，可維護性更強，可復用性更好的代碼

讓讀源碼、學框架事半功倍，學會設計模式，在看框架源碼的時候會更好的理解框架中的一些功能設計

為你的職場發展做鋪墊，提升自己 code review 能力，把控團隊代碼質量

設計模式設計原則

設計原則是指導我們代碼設計的一些經驗總結，對于每一種設計原則，我們需要掌握它的設計初衷，能解決哪些編程問題，有哪些應用場景。只有這樣，我們才能在項目中靈活恰當地應用這些原則。

• 單一職責原則

  對于一個類而言，應該僅有一個引起它變化的原因

  如果一個類承擔的職責過多，就等于把這些職責耦合在一起，一個職責的變化可能會削弱或者抑制這個類完全其他職責的能力。這種耦合會導致脆弱的設計，當發生變化時，設計會遭受到意想不到的破壞。

• 開放-封閉原則

  開放-封閉原則是說軟件實體（類、模塊、函數等等）應該可以擴展，但是不可修改。

  對于擴展開放，對于更改封閉

• 依賴倒轉原則

• • 高層模塊不應該依賴低層模式，兩個都應該依賴抽象。

  • 抽象不應該依賴細節，細節應該依賴于抽象?；诮涌诰幊?。

• 里氏代換原則

  子類型必須能夠替換掉它們的父類型

• 接口隔離原則

  使用多個隔離的接口,比使用單個接口好，建立最小的接口

  一個接口只負責一個功能

• 迪米特法則

  如果兩個類不必彼此通信，那么這兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一個類的某一個方法，可以通過第三者轉發這個調用。

  類的結構設計上，每一個類都應當盡量降低成員的訪問權限

  類之間的耦合越弱，越有利于復用，一個處在弱耦合的類別修改，不會對有關系的類造成波及

Overview 概覽

【DesignPatterns】 項目是用 C# 寫的一些設計模式的示例，基于 .netcore 3.1，大部分示例來自《大話設計模式》

設計模式大體上可分為三類：

• 創建型模式（Create）

簡單工廠（SimpleFactory）

抽象工廠（AbstractFactory）

工廠方法（FactoryMethod）

建造者模式（Builder）

原型模式（Prototype）

單例模式（Singleton）

• 結構型模式（Structure）

• 適配器模式（Adapter）

• 橋接模式（Bridge）

• 組合模式（Composite）

• 裝飾(者/器)模式（Decorator）

• 外觀/門面模式（Facade）

• 享元模式（Flyweight）

• 代理模式（Proxy）

• 行為型模式（Behavior）

• 觀察者模式（Observer）

• 模板方法（TemplateMethod）

• 命令模式（Command）

• 狀態模式（State）

• 職責鏈模式（Chain of Responsibility）

• 解釋器模式（Interpreter）

• 中介者模式（Mediator）

• 訪問者模式（Visitor）

• 備忘錄模式（Memento）

• 迭代器模式（Iterator）

• 策略模式（Strategy）

More

我們上面提到的設計原則有六個，現在有的文章說是有七個，多出來的一個原則是 “組合由于繼承”，主要是強調多用組合而非繼承，因為繼承可能會引入很多不必要的東西，而且很多語言的設計是不允許多繼承的，C# 就是單繼承的語言，一個類只能有一個父類。

繼承主要有三個作用：表示 is-a 關系，支持多態特性，代碼復用。而這三個作用都可以通過組合、接口、委托三個技術手段來達成。除此之外，利用組合還能解決層次過深、過復雜的繼承關系影響代碼可維護性的問題，所以很多情況下組合是比繼承更好一些的。

王爭在設計模式專欄中總結了一些設計模式和設計原則的一些知識點，分享一下，可以作為學習設計模式的參考：

Reference

• https://github.com/WeihanLi/DesignPatterns

總結

以上是生活随笔為你收集整理的闲谈设计模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。