【設計模式自習室】開篇：爲何要有設計模式？

時間 2020-12-07

標籤 git 程序員 github 面試算法編程後端設計模式安全微信欄目快樂工作简体版

原文原文鏈接

前言

《設計模式自習室》系列，顧名思義，本系列文章帶你溫習常見的設計模式。git

可是，在開篇中，我想要先總體的介紹下設計模式，讓你們知道爲何你要學習設計模式。程序員

因此這篇文章的主要內容是：github

我對設計模式的理解面試
設計模式的至高目標：解耦（高內聚低耦合）算法
設計模式的分類編程
設計模式遵循的設計原則後端
爲何我寫代碼經常用不到設計模式？設計模式

文章會逐步更新於個人各個博客上（見文章尾部介紹），也但願各位觀衆老爺可以關注個人我的公衆號：後端技術漫談，全部文章都會在上面發佈，不會錯過精彩好看的文章。安全

爲何咱們須要設計模式？

我對設計模式的理解

當我剛剛接觸程序，最初聽到「設計模式」這四個字的時候，我經常會思考一個問題，這個東西爲何這麼拗口。就像我當初聽到「離散數學」，「具體數學」同樣，有種摸不着頭腦的感受。微信

帶着這種疑問，我嘗試看了幾篇介紹設計模式的文章，它們都對設計模式進行了這樣的介紹：

軟件設計模式（Design pattern），又稱設計模式，是一套被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性、程序的重用性。

看完以後，我更加摸不着頭腦了。看着什麼單例模式，責任鏈模式的代碼，感受老師歷來就沒提過這些，爲何要把代碼寫成這樣，好好的寫完本身想要的功能不就行了嘛？？？

是的，設計模式，對於入門程序員來講，確實有點空中樓閣，尤爲是對於沒接觸過大型項目的人而言，這些代碼是如此的陌生，甚至有點「故弄玄虛」。

可是，生活每每就是有這麼多「可是」！當你逐漸入門了程序編寫，接觸到了大型的，功能複雜的，須要多人合做的代碼後，再回頭看設計模式，每每就有了愈來愈清晰的認識。

隨着個人經驗積累，再回來複習設計模式，經常有醒悟的感受。接下來就說說我對設計模式的認知：

設計模式的英文是什麼？Design pattern，這是一個很是之準確的詞彙，我的認爲比中文翻譯好太多了。

Patten中文釋義：. n. 模式；圖案；樣品. vt. 模仿

pattern每每意味着是一種既定的準則，從它的動詞能夠看到，他有模仿的意思，也就是說，這樣的代碼設計，是一系列前人留下的經驗，只要跟着這樣寫代碼，每每可以讓你的代碼，更加簡潔，更加健壯，更加優雅！

我以爲他應該有個意譯的名字，叫作：代碼設計的最佳實踐！

是否是很耳熟，還記得最近很火的《阿里巴巴Java開發手冊》，以及經典的《Effective Java》嗎？他們都是屬於經驗總結型的知識，目的是幫助程序員寫出更優雅的代碼！

若是你沒聽過上面的幾本書，不要緊，固然，你也能夠看看我以前的文章《阿里巴巴Java開發手冊》閱讀筆記，大概瞭解下他們的內容是什麼樣的，你就會理解我說的「他們是一個類型的」。

高內聚低耦合

設計模式是一種代碼設計思路，其最最本質的目的是爲了解耦，延伸一點的話，還有爲了可擴展性和健壯性，可是這都是創建在解耦的基礎之上。

有同窗要問了，「解耦」是什麼意思呢？請先看下面兩個概念：

高內聚

系統中A、B兩個模塊進行交互，若是修改了A模塊，不影響模塊B的工做，那麼認爲A是高度內聚的。

低耦合

那麼當B發生改變時，A模塊仍然能夠正常工做，那麼就認爲A與B是低耦合的。

因此解耦，本質上就是讓不一樣的代碼塊各司其職，互不干擾！

設計模式的分類

建立型模式

建立型模式將建立對象的過程進行了抽象，也能夠理解爲將建立對象的過程進行了封裝，做爲客戶程序僅僅須要去使用對象，而再也不關係建立對象過程當中的邏輯。

簡單工廠模式（Simple Factory）:簡單工廠模式不是GoF總結出來的23種設計模式之一
工廠方法模式（Factory Method）
抽象工廠模式（Abstract Factory）
建立者模式（Builder）
原型模式（Prototype）
單例模式（Singleton）

結構型模式

結構型模式是爲解決怎樣組裝現有的類，設計它們的交互方式。例如：擴展性（外觀、組成、代理、裝飾）、封裝（適配器、橋接）。由於如何設計對象的結構、繼承和依賴關係會影響到後續程序的維護性、代碼的健壯性、耦合性等。

外觀模式/門面模式（Facade門面模式）
適配器模式（Adapter）
代理模式（Proxy）
裝飾模式（Decorator）
橋樑模式/橋接模式（Bridge）
組合模式（Composite）
享元模式（Flyweight）

行爲型模式

行爲模式刻劃了在程序運行時難以跟蹤的複雜的控制流，進一步可分爲行爲類模式和行爲對象模式。

行爲類模式使用繼承機制在類間分派行爲。

行爲對象模式使用對象聚合來分配行爲。一些行爲對象模式描述了一組對等的對象怎樣相互協做以完成其中任何一個對象都沒法單獨完成的任務。

模板方法模式（Template Method）
觀察者模式（Observer）
狀態模式（State）
策略模式（Strategy）
職責鏈模式（Chain of Responsibility）
命令模式（Command）
訪問者模式（Visitor）
調停者模式（Mediator）
備忘錄模式（Memento）
迭代器模式（Iterator）
解釋器模式（Interpreter）

三者之間的區別和聯繫

建立型模式提供生存環境，結構型模式提供生存理由，行爲型模式提供如何生存。

建立型模式爲其餘兩種模式使用提供了環境。

結構型模式側重於接口的使用，它作的一切工做都是對象或是類之間的交互，提供一個門。

行爲型模式顧名思義，側重於具體行爲，因此概念中才會出現職責分配和算法通訊等內容。

設計原則

設計模式是優雅的代碼實現，因此會講究標準的設計原則，經常使用的設計原則以下：

開閉原則：對擴展開放，對修改關閉
里氏轉換原則：子類繼承父類，單獨徹底能夠運行
依賴倒轉原則：引用一個對象，若是這個對象有底層類型，直接引用底層類型
接口隔離原則：每個接口應該是一種角色
合成/聚合複用原則：新的對象應使用一些已有的對象，使之成爲新對象的一部分
迪米特原則：一個對象應對其餘對象有儘量少的瞭解

爲何我寫代碼經常用不到設計模式？

這一點，是我臨時加上的，由於我以前也有這樣的困惑。看了這麼多設計模式，爲何我平常使用中根本就不會想到去用呢？我想給出幾點回答：

第一，咱們平常開發中，常常是使用框架在構造大型的項目，框架已經爲咱們考慮到了太多的設計，已經讓咱們開箱即用。因此咱們經常只須要CRUD（增刪改查）。其實框架的源碼中，使用到了很是多的設計模式，這也是爲何不少大牛在推薦咱們看某某框架的源碼前，經常建議咱們先看設計模式。不然看源碼的時候，會很是的吃力，由於不知道爲何會這樣寫代碼。

第二，設計模式的使用每每在你的編程經驗積累到必定程度後，在遇到了大量的問題後，你會想着去進行合理的代碼結構設計來解決一些經常會遇到的問題，這時候，你就會慢慢的想到使用設計模式了！因此不要急，你能夠先不用強行往本身的項目上放設計模式，但必定要先了解各類設計模式。

第三，若是你急着想要上手實踐設計模式，那麼，作一個徹底不依賴大型框架的項目吧，能夠是一個工具類，能夠是一個小功能腳本，只要不依賴那些複雜的框架，很快你就能發現你代碼中能夠應用設計模式的地方，別問我怎麼知道的，快去本身造一個輪子吧！