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

無緒 (Cluelessness) 由 Martin Rinard 提出。他在演講時指出： 在開發和維護軟體系統時，應該避免讓開發人員深入了解系統。 因為人的大腦可以處理的資訊有限。若要建立一個日益變大的應用程式，就必須學習「 如何讓每個開發人員在不了解整個應用程式的情況下，也能完成軟體開發 」。  “無緒” 並不是一個貶義詞。它用來區別兩種層次的理解水平。 1. 淺層理解 ：指對事物的了解程度僅限於掌握使用方法即可。 2. 深層理解 ：指對掌握了事物背後的原則、規律、原理。 在日常生活中的“無緒” 生活中我們通常只需要用到 淺層理解 。例如，刷牙不需要知道化學式。不需要理解冰箱原理就可以冷凍食品。當然，也有一些人需要了解更深入的內容。像是冰箱的維修人員就要了解較深入的領域知識。但即便如此，維修人員所需要的知識仍屬於 淺層理解 ，因為他們也不需要了解事物背後的每個小細節和原理。 當然也可以學習每件事物背後的知識原理，但是必要性與 CP 值通常不大。因此大多數人在日常生活中只需要 淺層理解  就足夠了。 軟體開發中的“無緒” 在軟體開發中，“無緒” 也表示大部分的時間中，開發人員只需要  淺層理解  就足以應付工作。這裡的  淺層理解  並不是指開發人員不需要懂得編寫程式。以下舉個例子來說明軟體開發中的  淺層理解  與  深層理解  之間的差異。 「電子商務網站」： 某天 PM 告知下一個專案是「電子商務網站」。那麼，實作這個網站有兩種做法： 實作方法一： 在專案初始階段，我需要打開 HTTP 協定的文件，解析 HTTP 傳輸格式、 研究如何實現 POST、GET 請求....等等。  此外還要閱讀 RFC 文件，並實現文件中的各項內容。  全部都搞定後才能開始打造「電子商務網站」。 實作方法二： 在專案初始階段，在作業系統中下載並安裝 Apache、PHP、MySQL，  設定妥當後即開始打造「電子商務網站」。 相信 實作方法二  才是大家熟悉開發的方式，因為現代軟體都是基於組件組裝出來的，沒有人需要獨自從頭到尾完成所有內容。在一個作業系統上安裝 Web 服務並開始編寫 HTML，對現在的開發人員來說是易如反掌。但事實上光是 Web 服務就已經複雜到極點，應該沒人敢說自己了解 Web 服務的所有內容。這