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

但這不代表物件導向沒有缺點，要是沒有妥善運用SOLID 原則的話，物件導向對專案的傷害絕對不比 程序式程式碼 低！但這留給後續的文章來解釋，首先來看 ... 跳到主要內容 淺談物件導向SOLID原則對工程師的好處與如何影響能力 取得連結 Facebook Twitter Pinterest 以電子郵件傳送 其他應用程式 10月21,2019 系列文章 淺談物件導向SOLID原則對工程師的好處與如何影響能力 再談SOLID原則，WhySOLID? SRP單一職責原則，定義、解析與實踐 物件導向設計原則：開放封閉原則，定義、解析與實踐 物件導向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原則之上 這裏引用UncleBob在 物件導向原則、設計模式與C#實踐 這本書說過的話： 我的書裡所教的觀念與技巧，都只對乾淨的Code有效益。

如果你的程式碼還很雜亂，請先學會怎麼整理程式碼。

 - UncleBob（現代軟體界大神） 然而 這本書也是SOLID的原點。

軟體開發的觀念幾乎就圍繞這幾個議題在發展，因此有沒有學會上述議題，基本上就是碼農跟中高階工程師的分水嶺。

如果持續努力學習這些議題，馬上就能 凸顯跟大部分工程師的差異性，面試時可以談的條件也會變多。

我自己的學習路線如下： SOLID>重構+單元測試>設計模式>測試驅動開發(TDD)>行為驅動開發(BDD)>領域驅動開發(DDD) 但是真實的學習過程其實經常交叉學習，不一定是先學完前者才往下學習下一個。

因為這些議題都是環環相扣，常常可以在後面的議題學習到前面議題的進階用法。

結尾： 以往學習SOLID原則時，大部分文章都專注在每個原則的介紹與範例，卻幾乎沒人提及SOLID原則與物件導向之間的關係，以及SOLID原則日後的發展為何？ 因此我想在講解 SOLID每個原則之前，先花篇幅琢磨在兩個問題上。

希望也能替其他人解開疑問。

取得連結 Facebook Twitter Pinterest 以電子郵件傳送 其他應用程式 留言 這個網誌中的熱門文章 GitCommitMessage這樣寫會更好，替專案引入規範與範例 5月03,2019 CommitMessage跟寫程式註解還蠻像的，最好可以寫下「為什麼」你要作這樣的異動，而不是單單只記錄下你做了「什麼」異動。

CommitMessage最好兼俱Why及What，讓日後進行維護人員更快進入狀況。

CommitMessage這樣寫會更好：做issue的時候，不應該一次Commit所有異動！應該獨立Commit每個不同意義的異動，這樣commit訊息才會跟異動的程式碼有關聯。

每次Commit都是針對異動的檔案做說明：Why&What。

這樣的CommitMessage能讓日後的維護人員更快進入狀況每次Commit都加上issue編號，方便追蹤相關的程式異動原因。

若CommitMessage寫得妥當，在閱讀追蹤程式碼的意圖會相當容易。

如果只把Git當作版本控制，隨意撰寫CommitMessage就太可惜了！不能只把Git當作程式碼的FTP，要把Git當作歷史查閱的工具才拿發揮Git的功能。

好與不好的真實案例用一個小插曲證實Commit訊息的重要性上面PPT是我在工作中遇到的兩個案例，範例中包含「好的CommitMessage」與「不良的CommitMessage」。

在範例中可見：良好的CommitMessage:如何在「一年後」讓維護人員進入狀況不良的CommitMessage:如何在「一個月內」讓維護人員找不出程式異動的原因。

CommitMessage之規範在撰寫Git與SVN等版本控制軟體CommitMessage時，可以參照國外AngularJS團隊的規範：AngularJSGitCommitMessageConventions以下為這套訊息規範的展示與說明：CommitMessage規範範例：CommitMessage規範範例解析：CommitMessage規範組成：Header:():-type:代表commit的類別：feat,fix,docs,sty 閱讀完整內容 Gitlab合併請求MergeRequest是什麼？ 5月03,2019 Gitlab合併請求（MergeRequest）一般在團隊開發的時候，為了避免工程師直接對主要Repo進行修改，會要求工程師從專案的主要Repo複製一份這個專案的副本（Fork）回來工程師的電腦進行開發/除錯。

工程師開發完成後，如果要把電腦上最新版本的程式碼上傳回專案的主要Repo，就必須對專案的主要Repo發送一個合併請求，請專案的主要Repo管理員進行程式合併。

當合併請求發送出去後，專案的主要Repo管理員可以在管理頁面上看見你的合併請求，這時管理員會進行一次CodeReview，管理員覺得程式沒問題，就會將工程師的程式合併回主線。

若管理員覺得這段程式碼有問題，也可以Close這次的MergeRequest。

另外MergeRequest等同於Github的PullRequest -可參考: 與其它開發者的互動-使用PullRequest（PR）上述流程如下圖：​ 閱讀完整內容 PHPOO物件導向基礎教學 7月27,2017 PHPOO基礎教學此篇教學只是物件導向的基礎與實作，內容只包含類別與物件的操作，讓不熟悉類別的人可以初識物件導向的好處，並且了解物件與類別的特性與關係。

更多物件導向的理論的學習內容會整理到PHPOO的進階教學:淺談物件導向SOLID原則對工程師的好處與如何影響能力再談SOLID原則，WhySOLID?PHPOO物件導向原則:單一職責原則SRPPHPOO物件導向原則:開放封閉原則OCPPHPOO物件導向原則:里氏替換原則LSPPHPOO物件導向原則:介面隔離原則ISPPHPOO物件導向原則:依賴反轉原則DIP進階觀念：再談物件導向設計原則:單一職責原則，定義、解析與實踐認識物件導向ObjectOriented：物件導向是一種寫程式的方式，它傾向讓開發者把類似或有關聯的工作或屬性，組織到類別(classes)裡面。

這可以讓程式保持遵守 不重複原則**“don’trepeatyourself”(DRY)**，且更容易維護。

“Object-orientedprogrammingisastyleofcodingthatallowsdeveloperstogroupsimilartasksintoclasses.”不重複的程式(DRY)是物件導向最主要的優點之一，物件導向嚇跑了很多的開發者，因為它帶引入了一些新的語法，並且一看就知道比直譯程式(procedural)還複雜。

但是，其實仔細了解一下，OO實際上是一種非常直觀且是簡化程式最好的方法。

一、認識物件與類別UnderstandingObjectsandClasses在開始更深入了解OOP之前，一定要先了解 物件(object)與類別(class) 的差異。

本章節會介紹類別(class)的構造，還有其功能與用途。

類別(class)，可以比喻為一間房子的藍圖，類別只是清楚得定義房子的結構與形狀。

物件(object)，可以比喻為一棟真的房子，物件是類別的實例化。

資料(data)就像是鋼筋、電線、混泥土等蓋房子的材料。

如果沒有按照藍圖(類別class) 來組裝，這些 閱讀完整內容 WadeHuang 瀏覽簡介 封存 三月20201 一月20204 十二月20197 十一月20191 十月20192 九月20193 五月20196 十一月20181 十月20181 七月20187 六月20185 四月20181 三月20182 二月20182 八月20175 七月20171 一月20175 顯示更多 顯示較少