再談 SOLID 原則,Why SOLID?

再談 SOLID 原則,Why SOLID?

Why SOLID?

前一篇文章中介紹 SOLID 對一個工程師的影響,這裡再稍微補充一下為什麼軟體開發會需要 SOLID 原則?

軟體複雜的本質

專案經常會歷經「商業邏輯調整」和「快速且多變的需求」,這都不是開發環節所能控制的,但是一個專案會「遇到困難」常常是因為 糟糕的程式設計 和其他技術層面導致。

其中 糟糕的程式設計 又可分成三大因素:

  • 程式碼變更
  • Bug 修復
  • 複雜度控制

在添加功能前應該 閱讀代碼並細心設計,但實際上更常發生的是,開發者選擇直接在程式碼上面堆疊新的程式碼新舊版本意圖不同 的程式碼錯綜複雜之下,會讓專案難以在不引發連鎖反應的情況下增加功能。最後新的功能引入 Bug,從而導致另一個 Bug,然後一個接著一個,這樣的事情不斷發生。

沒有做過可擴展性設計的程式碼 上進行擴展功能,常常是火上加油!
那為什麼不把程式「設計」成可擴展就好了呢?

開發者知識普遍不足

一個充滿外行人的產業

開發者們來自不同的背景,且有大量不同的方式去解決問題,但是一個開發者應該具備什麼樣的知識體系,卻沒有一個廣泛的共識。

更不幸的是,許多開發者在學校裡面學到的知識是過時的,學校提供的程式設計課程並未給學生做好準備。這些課程通常只關注程式語言的功能,但是 …

掌握一門程式語言並不能使你成為軟體開發者,正如掌握一門自然語言並不能使你成為作家

學校所教的知識,並不是大部分軟體開發者的工作內容。開發者也許能編寫一個可運行的程式碼,但若要回頭去擴展程式碼卻常常是艱難且冒險的

軟體開發過程中,開發者需要做出無數個選擇,加上每個開發者用不同的方法解決問題,助長了難以維護、難以擴展的程式碼。最終讓 系統設計的思想溝通 變得困難。

工程師必須花費大量時間閱讀程式碼。

不論是開發者還是管理者都需要對 軟體複雜的本質 做管理。為了編寫出更容易應對變化的程式碼,我們必須填補基礎認知方面的空白。

導入設計原則

若有一些原則可以指導工程師在 一定的情況下理解每個選擇的所得所失 並做出最佳權衡,則可以統一工程師解決問題的方法,降低 系統設計思想溝通 的困難度。

Uncle Bob 花費多年整理了許多開發人員、研究人員的思想和著作結晶,提出了 5 個設計原則:

  • 單一職責原則(The Single Responsibility Principle, 簡稱 SRP)
  • 開放-封閉原則 (The Open-Close Principle, 簡稱 OCP)
  • 里氏替換原則 (The Liskov Substitution Principle, 簡稱 LSP)
  • 依賴倒置原則 (The Dependency Inversion Principle, 簡稱 DIP)
  • 接口隔離原則 (Interface Segregation Principle, 簡稱 ISP)

SOLID 原則目的是讓程式碼在面對改變時,能有一套策略來應對。

SOLID 原則指導開發者們該 如何將函式和資料結構安排到類別中,以及這些 類別該如何互相關聯

遵循 SOLID 原則的程式碼具有以下特性:

  • 能夠容忍變化
  • 容易擴展新邏輯
  • 容易理解
  • 容易複用

雖然 SOLID 原則是 物件導向 的設計原則,但事實上這些原則與思維一直存在軟體工程中。因此 SOLID 原則的思維可以延伸套用至非物件導向語言、系統架構等等領域。

順帶一提,SOLID 原則並沒有順序關係,單純是 Michael Feathers(1 發了電子郵件告訴 Uncle Bob 可以用 SOLID 這個詞彙將 5 個原則串起來變成口訣方便記憶。
所以在學習 SOLID 原則的過程中,可以不用按照順序學習。

備註:

  1. Michael Feathers 是 Working Effectively with Legacy Code 的作者,也是一本開發者必讀經典書籍。

此文章也會同步到:我的部落格

系列文章:

  1. 淺談物件導向 SOLID 原則對工程師的好處與如何影響能力
  2. 再談 SOLID 原則,Why SOLID?
  3. 物件導向設計原則:單一職責原則,定義、解析與實踐
  4. 物件導向設計原則:開放封閉原則,定義、解析與實踐
  5. 物件導向設計原則:裡氏替換原則,定義、解析

留言

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×