淺談物件導向 SOLID 原則對工程師的好處與如何影響能力

淺談物件導向 SOLID 原則對工程師的好處與如何影響能力

前言

為了感謝部落格一直以來都有人在閱讀,讓我一直有經營下去的動力。所以想寫一個系列 學習 SOLID 原則 2 年後的心得文章。這心得文章包含自己使用 SOLID 兩年的總結,並且以自己的理解簡化 SOLID 原則,希望幫助新手工程師縮短「SOLID 原則是文字天書」的時間。

從第一次接觸 物件導向 SOLID 原則 至今已經兩年了,一開始覺得「SOLID 原則是文字天書」,到現在 Coding 時常融入 SOLID 的思想來「設計」程式。

所以 SOLID 原則到底是什麼?

SOLID 原則是物件導向「設計層面」的思維與定律。

大學時期程式設計課程中所學的物件導向,其實只是在介紹程式語言有提供 物件導向的哪些特性,卻 從未有人教導如何透過物件導向的特性撰寫程式碼甚至沒人告訴你為什麼要用物件導向開發程式

然而 SOLID 原則就是物件導向開發的指導方針,若以多個角度來看這些原則,會發現 SOLID 已經指出 物件導向的優點 以及 程序式程式碼隱晦的缺點。但這不代表物件導向沒有缺點,要是沒有妥善運用 SOLID 原則的話,物件導向對專案的傷害絕對不比 程序式程式碼 低!但這留給後續的文章來解釋,首先來看看 SOLID 的好處與重要性。

SOLID 原則對專案的好處?

SOLID 原則對專案的影響很大,當專案一點一滴的導入 SOLID 原則的程式碼,不少複雜的程式碼慢慢被簡化,被簡化的程式碼可以降低複雜度,讀懂程式碼的時間從原本需要花 20 分鐘閱讀,到只需要花費 2 分鐘閱讀。縮短閱讀時間對專案來說是一件好事,一般來說工程師「閱讀程式碼」的時間常常大於「新增/修改程式碼」的時間,畢竟要先讀懂才能動手嘛,因此 縮短閱讀程式碼時間 等於 縮短「新增/修改程式碼」程式碼的時間。

優點:降低程式碼複雜度 => 縮短閱讀程式碼的時間 => 減少維護專案程式碼的時間

你可能會覺得,為什麼 SOLID 原則可以降低程式碼的複雜度?

因為 物件導向本身的目的就是管理「程式碼複雜度」,這也是為什麼這麼多人推崇使用物件導向開發的原因,然而 SOLID 原則是教導工程師應該如何透過 物件導向的特性 來管理程式碼的複雜度。

SOLID 原則對工程師的好處?

由上述可知 SOLID 原則可以降低程式碼的複雜度,這是第一個好處,因為降低工程師開發過程的痛苦值!(應該沒人想一直面對醜陋複雜的程式碼)

再來的好處可多的呢!為什麼這麼說呢?
SOLID 原則是踏入資深工程師階段的必學觀念。大部分 軟體開發的進階觀念,都建構在良好的物件導向程式碼之上。要是沒辦法妥善運用物件導向,就沒辦法運用軟體開發的進階觀念/技巧。

這相當重要,若工程師沒有能力學習進階觀念,很可能就會一直停留在碼農階段。

但是學會 SOLID 原則之後呢?

以下列出 SOLID 未來的應用,下列被提及的每個議題都是 進階物件導向重要的基石,很值得花時間投資

1. 單元測試

  • 用程式碼撰寫測試程式,取代手動測試。
  • 替專案提供回歸測試,時時刻刻執行單元測試,檢查有沒有人改壞程式碼。
  • 符合 SOLID 原則的程式碼可以輕易導入單元測試。

2. 重構

  • 在不改變程式碼外部行為的前提下,修改程式碼內部的結構,提升可讀性與擴充性
  • 重構必然會搭配測試,避免改壞程式碼。
  • 低階重構:把爛 Code 重構成符合物件導向 SOLID 原則(敏捷開發)。
  • 中階重構:把 SOLID 重構成設計模式(敏捷開發)。
  • 高階重構:把 SOLID 重構成軟體架構(敏捷開發)。

3. 設計模式

  • 進階物件導向應用
  • 學習 物件與物件之間常見的組合模式。用來管理程式碼的複雜度,或解決開發系統中的各種常見問題。
  • 學過設計模式,在寫程式或閱讀程式的時候,會用更高一層的視角去思考。
  • 最後會培養出根深蒂固的抽象觀念。

但這些議題卻又基於 SOLID 原則之上

因為 SOLID 原則幫助專案建立一個乾淨、穩定、良好的物件導向程式碼,讓這些物件導向程式碼可以引入更進階的概念/技巧。

這裏引用 Uncle Bob 在 物件導向原則、設計模式與C#實踐 這本書說過的話:

我的書裡所教的觀念與技巧,都只對乾淨的 Code 有效益。
如果你的程式碼還很雜亂,請先學會怎麼整理程式碼。
Uncle Bob(現代軟體界大神)

然而 這本書也是 SOLID 的原點。軟體開發的觀念幾乎就圍繞在上述幾個議題在發展,因此有沒有學會上述議題,基本上就是碼農跟中高階工程師的分水嶺。如果持續努力學習這些議題,馬上就能 凸顯跟大部分工程師的差異性面試時可以談的條件也會變多

我的學習路線如下:

SOLID > 重構 + 單元測試 > 設計模式 > 測試驅動開發(TDD) > 行為驅動開發(BDD) > 領域驅動開發(DDD)

但是真實的學習過程其實經常交叉學習,不一定是先學完前者才往下學習下一個。因為這些議題都是環環相扣,常常可以在後面的議題學習到前面議題的進階用法。

結尾:

以往學習 SOLID 原則時,大部分文章都專注在每個原則的介紹與範例,卻幾乎沒人提及 SOLID 原則與物件導向之間的關係,以及 wSOLID 原則日後的發展為何?
因此我想在講解 SOLID 每個原則之前,先花篇幅琢磨在兩個問題上。希望也能替其他人解開疑問。

接下來也將會陸續推出講解 SOLID 每個原則的文章出現,沒意外的話下次 PO 文是探討 單一職責原則

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

系列文章:

  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

×