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% 。對於維護一個系統來說，這種情況除了相當浪費成本以外，也相當折磨開發人員的心情，更糟的是，每次回來維護又要重新讀一

重構定義： 在不改變軟體外部行為的前提下，改變其內部結構，使其更容易理解且易於修改。 目的： 重構的主要目的就是為了提升程式碼品質、 提升程式碼的可讀性 ，以及為了日後有新需求的變化時，程式碼可以 更容易修改或是擴充 （提高可維護性）。 優點： 1. 改進程式碼的設計： 消除重覆的程式碼，每個小功能被歸責到適當的物件中，讓程式碼的職責更清楚就會更容易維護。 將雜亂無序的程式碼，重構成一連串的 精心設計 的流程，讓程式碼更容易擴充。 2. 程式碼更容易被理解： 重構簡單的講，就是整理程式碼，可以透過 Clean Code 的規範 來整理程式碼，提升可讀性。 想想程式碼過一段時間後的第二個讀者，而且這個人常常是你自己。 3. Debug 更容易： 重構的過程中，會透過單一職責原則，依照程式碼的工作責任將程式碼整理至責任相同的類別中。有責任清楚的物件，就能更快釐清問題點，除錯速度自然能夠提升。 什麼時候可以開始重構？ 事實上，重構並不是一項需要額外撥出時間來進行的工作， 重構應該是在你的開發過程中持續在發生的事情 。 重構的活動，最理想的情況，就是透過持續不斷的整理，掃除那些有礙程式可讀性及可維護性的程式碼，讓程式碼持續盡可能地保持在一定健康的狀態。 既然重構是一個持續進行的活動，但又不是特意安排、特別撥出時間來做的工作，那麼，在什麼樣明確的時間點，應該觸發重構的進行呢？基本上， 重構的活動應該伴隨著我們一般開發過程中的主要活動來進行。這些主要活動包括了：增加新功能、修正錯誤、以及程式碼審查的時候，還有三次法則 。 三次法則： 同樣的事做三次，犯了 Don’t Repeat Yourself 原則，表示重複的邏輯該被重構成唯一且適當的物件或函式了。 新增功能時重構： 當我們試著增加新功能時，便有可能發現舊有的程式碼可以進行一些調整，而達成了必須重構所想要達成的目的。 但如果你在增加功能的時候，發現原設計就足以優雅地讓你將新功能擴充上去，那麼，這意謂著，還不太需要做什麼重構。 除錯時重構： 除錯的時候，你不僅會接觸到舊有的程式碼，而且，你通常得搞懂它真正的運作邏輯，當你真的懂了之後，就會知道如何用更清晰、簡潔的方式來改寫這段程式碼。 總結： 很多架構良好的程式，