隨著 2020 進到了 2021，菜雞與物件導向也推進到了五大原則結束，可以暫時告一段落了。

最初和朋友約好了要把公司新訓學到的東西做個整理（廣告一下他的部落格：Sian），只是沒想到因為太常發廢文偷懶，大半年才推進到物件導向的基礎而已，甚至占不到新訓內容的十分之一。希望 2021 能繼續推進，把這部份的坑給填一填，然後把前面的文章也重構一下，只是按照我的個性，可能又會忍不住開新的坑吧，哈哈。

至於物件導向相關的心得和紀錄，也就是這個系列，偶而有想到或是有所體悟的時候再發上來吧，暫時想先把前面隨手寫凌亂文章給整一整先。在這個十幾篇的短系列，記錄了從類別與物件開始，到耦合、內聚及五大原則，每個主題的心得。這邊稍微做個小整理：

類別、物件

  • 物件就是用來表達「我們知道的某個東西」，物件導向是用物件彼此互動的方式來建立架構
  • 類別去定義我們要的物件有什麼特徵、有什麼功能，再從類別中實例化（也就是根據設計圖產生）物件出來使用

建構式、多載

  • 建構式用來在建立物件時就進行一些我們想要的操作，例如狗狗的毛色等等天生的東西，或是這個建立這個物件的必須素材
  • 多載指的就是可以有很多個同樣名字的方法，各自去接不同的參數，讓同個目標的函式可以根據傳入的參數不同做不一樣的處理

封裝

  • 封裝將物件視作一個整體，讓每個物件保留自己的隱私。將物件的實作內容隱藏起來，互動的其他物件和使用者只需要知道怎麼使用即可
  • 兩個物件彼此了解越多，耦合就會越高。因此藉由封裝，我們提高類別內的內聚性，降低對外的耦合性，隱藏複雜資訊，並且迴避掉一些不小心直接用了不該用的方法造成的問題

繼承

  • 繼承是一種「is-a」的關係。當你能說出Ａ是一個Ｂ的時候，就代表你認為Ａ可以繼承自Ｂ
    • 最直覺的繼承例子就是物種的分類。舉例來說，狗跟貓都是哺乳類，因此他們都可以繼承到一些哺乳類共通的特徵（例如哺乳、用肺呼吸）
  • 繼承讓我們能只修改基底類別，便讓所有衍生出來的類別都一併受用，大大提高了程式碼的重複使用性
  • 但是，同時也帶來了強耦合，讓我們在修改基底類別時，不容易察覺到衍生類別因為這次修改而連帶發生的問題
  • 謹慎使用，或是乾脆不要用

多型

  • 多型允許繼承同一個父類別的各個子類別可以用不同方式去實現父類別的要求。藉著用子類別實作出各式各樣不同的方法，就能讓父類別的方法達到延伸和多樣化的效果，而不需要更動父類別本身
  • 同時，當子類別被以父類別的名義建立出來時，他就只能夠表現出父類別的樣子。使用者基於封裝的精神，不需要知道實作的細節

抽象、覆寫

  • 這邊的抽象指的是抽象類別，也就是無法被實例化的類別，通常我們會用來宣告那些不應該被實體化成一個物件的類別，例如哺乳類
  • 覆寫是指對於像是前述的抽象方法，或是一些父類別定義好要求子類別必須重新實作的虛擬方法時，子類別繼承後必須重新去實作該方法，藉此達到多型

介面

  • 介面就像是針對類別的實作、物件的行為去做規定的一個契約書，只需要先定義好該做的事，裡面怎麼做不需要管；所以只需要宣告要求的方法，不需要撰寫方法本體
  • 介面將物件之間的互動的著眼點放在該物件的行為上，降低了物件之間的耦合，更提高的物件彼此替換的彈性

內聚、耦合

  • 內聚是指：把需要的程式和資料都包裝在同一個模組內，使得該模組能夠做為一個單獨的個體執行
  • 內聚代表的是該模組的獨立性，當這個模組可以獨力完成工作，就代表我們能夠重複使用它，且不需要擔心影響到其他模組
  • 追求高內聚是絕對必要的，但達到完全內聚是不應該的，容易創造神之類別或大量複製貼上，使程式碼難以重複使用
  • 耦合是指：如果模組和另一個模組有關聯，那這兩者之間就耦合
  • 耦合會讓物件之間彼此相關，容易導致改東壞西的狀況，提高修改的難度。但因為物件導向讓物件之間協作的精神，達到毫無耦合是不可能的
  • 彼此關聯就會彼此牽連，因此我們要讓物件彼此之間保持一個舒適的距離。注意，是舒適的距離，而不是不相往來，健康的內聚就是健康的耦合
  • 判斷健康的內聚和耦合的標準，取決於該模組是否符合單一職責原則

SOLID

  • 隨著物件導向的亂用、誤用、無腦用，軟體就會逐漸腐化。因此，大前輩們整理並提出了一些可以致力的方向，也就是所謂的「原則」
  • 藉由這些原則，我們可以讓程式碼「能容忍變化、容易理解、能讓模組和元件使用」，達到降低程式碼的腐化臭味的目標
  • 整個 SOLID 就是面對變化的作戰策略

單一職責原則

  • 顧名思義，就是一個類別應該只負責一個職責，但是職責的定義和大小容易產生誤會。因此實際定義是：就一個類別而言，應該只有一個引起它變化的原因
  • 引起變化的原因可能是業務需求的變更或追加，注意不要讓類別做它不該做或好像超出範圍的事情
  • 把工作交給負責該職責的類別去做，自己只需要關注在自己正在處理的職責即可，也就是封裝的體現
  • 單一職責的關鍵在於展現程式碼的意圖，並時常自問：是否只有一個原因造成改變？職責是否清晰？
  • 當我們並未遵守單一職責原則時，會容易產生意外的重複、修改時也無法界定影響範圍、並且每次修改都要閱讀大量無關程式碼，使得修改成本大幅上升
  • 而遵守單一職責時，我們提高的程式碼的重複使用率，降低修改成本，並且也提高了內聚、降低了耦合，讓程式更容易管理

開放封閉原則

  • 軟體實體（類別、模組、函式等等）應該對擴展開放，而對修改封閉
  • 面對需求，對程式碼的改動是透過增加新程式碼進行的，而不是更改現有的程式碼
  • 開放封閉原則的關鍵在於模組化，以及準備擴充點。藉由單一職責切分出模組，並在主要邏輯和附加邏輯之間，加入抽象層來解耦合，可以讓物件之間保持彈性
  • 目標在於降低修改成本和風險，凡是變化都有成本，但如果我們做好模組化，並事先準備面對修改的策略，就可以降低修改的風險

里氏替換原則

  • 子類別必須能夠替換父類別，不需要改變，也不會發生任何錯誤或異常
  • 我們預期了這個函式或類別需要準備的輸入參數，也預期了應該要有的輸出結果。如果某一天替換了子類別，卻不是這麼一回事，就會發生很多意料外的錯誤
  • 里氏替換原則的關鍵在於繼承時必須遵守三個條件：先驗條件不可以強化、後驗條件不可以弱化、不變條件必須保持不變
  • 繼承的時候應該著眼在能否做出父類別期望的行為，而非子類別是否所屬於父類別（企鵝不會飛，鳥會飛）

介面隔離原則

  • 不應該強迫用戶依賴它們未使用的方法；應該最小化類別與類別之間的介面
  • 介面也必須要通過單一職責的考驗，在定義介面時，優先從組合的方面進行考慮，把想要的行為用職責的角度去思考

依賴反轉原則

  • 高階模組不應該依賴於低階模組。兩者都應該依賴抽象
  • Ａ模組直接受到Ｂ模組的影響，我們就稱Ａ依賴了Ｂ。同時，抽象不應該依賴細節；細節應該依賴抽象，因此我們需要用抽象層將依賴做隔離
  • 依賴反轉原則的關鍵在於抽象層的觀念：並不是低階模組的實作提供了抽象層，而是高階模組針對所需要的功能提出了抽象，而低階模組去實現它
  • 針對反轉之後如何建立實例的問題，控制反轉是一個常見的思路：讓控制反轉中心去建立低階模組，然後高階模組要使用的時候再把這個低階模組交給高階模組使用，這個過程的實現方法就叫做依賴注入。藉此讓高階模組處於控制權上的被動，同時也不用再負責建立低階模組，解除兩者間的依賴

最少知識原則

  • 只和直接的朋友溝通，不和陌生人說話，一個物件應該對其他物件應該只有最少的了解
    • 直接的朋友包括：該方法所屬的類別、該方法所接收的參數、該方法中建立的類別、該方法所屬的類別所依賴的對象
    • 換個方向想就是直接具有依賴關係的類別和方法
  • 不應該使用其他類別的方法所回傳的類別的方法
  • 最少知識原則的關鍵在於良好的封裝：複雜性隱藏到自己內部，對外只開放必要的功能，並且只使用到直接關聯的對象，確保不會造成意外的耦合

當然，還有許多沒有收錄或是我也尚未學習到的部分，就先收錄在本篇結尾的遺珠之憾單元。如果有什麼體悟了，或是累積了一些數量（也就是之後腦洞又開了）就再拿來發新文章，如此豈不樂哉。如果對內容有什麼想法或能補充的，有發現我有所疏漏的地方，也還麻煩跟我說一聲，這邊就對那些願意給予幫助、以及把這些文章看完的朋友道個謝囉。

那麼，我們下個系列再見囉，各位新年快樂！

</2020>

遺珠之憾

這邊放一些物件導向相關的咚咚和推薦文章，彌補本篇一些沒提到的部分，例如合成複用原則、三次原則等等。當然，有想到也會回來補充一下啦～

同系列文章