簡介

設計模式是計算機前輩們，總結項目開發成敗經驗，得出的一套最佳實踐理論。它并不是高高在上、不切實際的理論，而是具體到代碼編寫層面的指導理論。

從學習編寫代碼開始，我們就被教導，要寫高內聚、低耦合、可復用、可擴展的代碼。但是具體要怎么做呢？設計模式給出了答案。所以，我們之所以要學習設計模式，是因為它可以教會我們，如何實現代碼的高內聚、低耦合、可復用，從而提高項目的可維護性，降低項目失敗風險，提高項目質量。正因如此，設計模式是每個開發人員的必修課。

理解

但是，我們在學習設計模式的時候，常常因為沒有抓住設計模式的本質，而迷失于設計模式的叢林中。只有緊緊抓住設計模式的本質，從而更加省時省力地將其掌握，才能更深入理解其內涵，并且知道什么時候該用、什么時候不該用、具體應該用哪個設計模式。如果無法分析如何使用設計模式、使用設計模式會付出哪些成本、帶來什么影響，這將會給項目帶來更多的風險和麻煩。也就是說，如非必要，不要使用設計模式；如果用，就要用對。

網絡上的一些自稱通俗易懂講解設計模式的文章，其實看下來，并沒有讓我們理解設計模式的本質。

筆者認為，本質這種東西用一兩句話就應該可以描述出來，并且能描繪出被研究對象共同的特征。

本質

回歸正題，設計模式的本質是什么？用一句話概括，設計模式的本質就是教你怎么封裝。

想象一下這樣一個過程。你不用設計模式，實現了某個功能，軟件正常運行，一切正常。
但是為了提高代碼的質量，你準備重構現有的代碼。
通過分析發現，某些代碼段的使用頻率很高，我們可以將其稱作“熱代碼”。對于熱代碼，我們不想一遍一遍的敲，想要節省時間和精力。實現這個目的的方法就是把熱代碼封裝起來。

只有通過適當的封裝，才能實現代碼的高內聚、低耦合、可復用、可擴展。所以，設計模式的本質就是教你怎么封裝。當然，封裝的目的多種多樣，可能有時并不只是為了封裝熱代碼，實際工作中，要根據問題的優先級綜合考慮。

理性對待

設計模式不是萬能的，不要迷信設計模式。需求的變化是常事，所有已有的代碼都可能被推翻。巨大的需求變化下，設計模式也無能為力。設計模式只能適應某類需求變化，而不是所有需求的變化。在使用設計模式時，需要開發團隊根據經驗和理論對需求的進行預測，選擇合適的設計模式，提高項目維護性。

設計模式既然是一種好的做法，那么對應的，就有不好的做法。這也從側面說明了，不學設計模式也一樣能夠實現想要的功能。功能才是軟件的生命，功能才是用戶真正關心的東西，設計模式只是開發人員的思維工具。

后面的文章中，筆者將對各種已有的設計模式，從設計模式的本質出發，進行細致分解。

設計模式的參考資料我們采用國內目前比較便于訪問的菜鳥教程中的內容。地址：https://www.runoob.com/design-pattern/design-pattern-intro.html

---

本文原創首發于微信公眾號“Qt未來工程師”。

總結

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

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