WadeHuang的學習迷航記

系列文章 淺談物件導向 SOLID 原則對工程師的好處與如何影響能力 再談 SOLID 原則，Why SOLID? SRP 單一職責原則，定義、解析與實踐 物件導向設計原則：開放封閉原則，定義、解析與實踐 單一職責原則(Single responsibility principle) 定義： A class should have only one reason to change. 以一個類別來說，應該只有一個引起它變化的原因。 ”等等，這是在說人話嗎？還是我理解能力不夠好？“ 這是我第一次讀到 SRP 原則定義的反應，當時覺得 SOLID 每個原則都是文字天書。若你也有跟我一樣的反應，不要緊張，大家都經歷過這個過程。我將會在本文中以自己的體悟來講解觀念，實務經驗演示如何實踐 SOLID 原則。 單一職責原則是 SOLID 原則中看起來最容易明白，卻也是最容易讓人混淆的原則。因為很多人並不清楚 職責 是什麼，甚至誤以為一個類別只能做一件事。接下來的文章中會依序講解原則的目的；解決什麼問題；如何實踐。 目的： 提高程式碼的內聚性，讓程式碼更易於管理和重複使用。 解析： 什麼是內聚？ 在英文辭典中 內聚(Cohesion) 的同義詞為一致性、凝聚、結合等等，描述相關的事務如何聯繫在一起。在軟體開發中， 高質量程式碼通常是高內聚性的 ， 內聚 程式碼的特徵為： 每個程式碼片段都只關注一件事情 當每段程式碼只關注一件事情時，程式碼會更容易被理解和處理，且相較 低內聚 的程式碼來說更容易編寫。 什麼情況會造成低內聚? 當程式碼包含一個以上「互不相關」的邏輯或意圖時，程式碼的內聚性就會降低。 (一般而言，低內聚的程式碼代表高耦合 ^1 ) 程式碼的內聚性一但降低，閱讀與維護程式碼的難度就會提升 。當你必須從一個大函式裡面修改其中一小段邏輯，若不先花時間讀懂函式中每段程式碼之間的關係就直接修改程式碼，很容易破壞函式原先可正常運作的程式碼。為了避免對程式碼造成破壞，開發人員開發過程總是變成： 花費 80% 時間閱讀程式碼，真正編寫程式碼的時間卻只有 20% 。對於維護一個系統來說，這種情況除了相當浪費成本以外，也相當折磨開發人員的心情，更糟的是，每次回來維護又要重新讀一

系列文章 淺談物件導向 SOLID 原則對工程師的好處與如何影響能力 再談 SOLID 原則，Why SOLID? SRP 單一職責原則，定義、解析與實踐 物件導向設計原則：開放封閉原則，定義、解析與實踐 Why SOLID? 在 前一篇文章 中介紹 SOLID 對一個工程師的影響，這裡再稍微補充一下為什麼軟體開發會需要 SOLID 原則？ 軟體複雜的本質 專案經常會歷經「商業邏輯調整」和「快速且多變的需求」，這都不是開發環節所能控制的，但是一個專案會「遇到困難」常常是因為  糟糕的程式設計  和其他技術層面導致。 其中  糟糕的程式設計  又可分成三個因素： 程式碼變更 Bug 修復 複雜度控制 在添加功能前應該  閱讀代碼並細心設計 ，但實際上更常發生的是，開發者選擇 直接在程式碼上面堆疊新的程式碼 。 新舊版本  和  意圖不同  的程式碼錯綜複雜之下，會讓專案難以在不引發連鎖反應的情況下增加功能。最後新的功能引入 Bug，從而導致另一個 Bug，然後一個接著一個，這樣的事情不斷發生。 在  沒有做過可擴展性設計的程式碼  上進行擴展功能，常常是火上加油！ 那為什麼不把程式「設計」成可擴展就好了呢？ 開發者知識普遍不足 一個充滿外行人的產業 開發者們來自不同的背景，且有大量不同的方式去解決問題，但是一個開發者應該具備什麼樣的知識體系，並沒有一個廣泛的共識。 更不幸的是，許多開發者在學校裡面學到的知識是過時的，學校提供的程式設計課程並未給學生做好準備。這些課程通常只關注程式語言的功能，但是 ... 掌握一門程式語言並不能使你成為軟體開發者，正如掌握一門自然語言並不能使你成為作家 學校所教的知識，並不是大部分軟體開發者的工作內容。 開發者也許能編寫一個可運行的程式碼，但若要 回頭去擴展程式碼卻 常 常 是艱難且冒險的 。 軟體開發過程中，開發者需要做出無數個選擇，加上每個開發者用不同的方法解決問題，助長了難以維護、難以擴展的程式碼。最終讓  系統設計的思想溝通  變得困難（ 工程師必須花費大量時間閱讀程式碼 ）。 不論是開發者還是管理者都需要對  軟體複雜的本質  做管理。為了編寫出更容易應對變化的程式碼，我們必須填補基礎認知方面的空白。 導入設計原則 若有一些