2018 [台北] 保哥 認識 SOLID 物件導向開發原則

2018 保哥介紹 SOLID 物件導向原則小紀錄

這次有很幸運地報名到保哥的課程!!! 20個名額 70秒內售完 XDDD

先前就對SOLID很好奇,而且找了很多的資料也還是不太能理解到底是什麼樣的一個概念

保哥在一開始時就直接提出了開發時常見的情形

  • 開發時間較長? 還是除錯時間較長?
  • 有團隊進行開發 還是一人寫 Code?
  • 一個長期維護的專案,需求變更的頻繁程度?
  • 你如何讓程式具備有可讀性與擴充性?
  • 如何避免在修改程式的過程中引發連鎖反應? (改A壞B)
    • 相依性降低就可以改善這個問題

再來說了 OOP 四個特性

  • 抽象 (Abstraction)
    • 將真實世界的需求轉換成 OOP中的類別
    • 類別可以包含狀態(屬性)與行為(方法)
  • 封裝 (Encapsulation)
    • 隱藏/保護內部實作的細節,並可以隊屬性或方法設定存取層級(public, private, protected)
  • 繼承 (Inheritance)
    • 透過繼承來重複利用、擴充和修改基底類別的定義
  • 多型 (Polymorphism)
    • 同樣的類別有多種形體
如果不了解 OOP 的特性 和 SOLID 就甭想了解 Design Pattern 怎麼來的

後來講內聚力與偶合力 (Cohesion & Coupling)之前

先講模組(Module),一種抽象的概念

以C#舉例

  • 可能是一個 「類別」 (class)
  • 方法(method)
  • 組件(assembly)

內聚力 Cohesion

在一個 "模組" 內完成 "一件工作" 的度量指標

高內聚力

在一個模組(類別)內 只完成一件工作

內聚力高,意味著該模組可以獨立運作,也意味著更容易重複利用

低內聚力

在一個"模組"內完成多份工作

內聚力低,意味著這個模組會造成難以維護測試重用理解

範例:所有功能寫在一個 class裡面 或一個 method 有5000行的程式碼

最佳實務

在設計模組的時候要盡量設計出高內聚力的程式碼

若要一個模組內完成多項工作,建議拆成多個模組

耦合力 (Coupling)

意指

  • 模組與模組之間的關聯強度
  • 模組之間相互依賴的程度
  • 衡量兩個模組的緊密連接程度

高耦合力

意味著當改了A模組時,相關聯的B模組就會容易被影響(改A壞B)

低耦合力

當在修改模組時 有越少模組被影響就意味著耦合力較低

最佳實務

實現DIP就是實現 「降低耦合力」的一個原則

何謂原則?

所謂原則 就是一種 「概念」 或 「價值」 用來引導你產生 「適切的行為」 與 「價值評量方法」

講白一點的概念就是...

依循SOLID 可以..

  • 寫出比較好的程式碼
  • 較能夠判斷程式碼的好壞

SOLID原則為以下 5 點

  • 單一職責原則 Single Responsibility Principle
  • 開放封閉原則 Open Closed Principle
  • 里氏替換原則 Liskov Substitution Prinsple
  • 介面隔離原則 Interface Ssegregation Prinsple
  • 相依反轉原則 Dependency Inversion principle

學習 SOLID 物件導向設計原則的好處

  • 降低程式碼複雜程度
  • 具有較佳程式碼可讀性
  • 提升模組可重複利用姓
  • 讓模組具有高內聚力、低耦合力
  • 面臨變更需求時可減少破壞現有模組的風險

小感想

現實生活中也有很多東西都會運用到SOLID原則,保哥舉裡吹風機的例子,吹風機可以換頭而他本身有馬達跟機身 那是他自己的模組

而 囧星人之前也是一個工程師,所以她以一個工程師的角度做了他的鬍子XD

網址連結: https://youtu.be/7KUbmq_M640?t=4m14s

這一次的介紹讓我真的比較了解 這五大原則的東西了,不然真的沒什麼 feel 尤其是 DI 的部分

因為今天的介紹後我更了解要如何判斷一個Code的好壞,不過很重要的一點是

原則是原則,Code 最後會長什麼樣子,是尤 「需求」決定。

接下來要多做的其實很多都是經驗上的問題,如何寫出高內聚、低耦合的 Code,如何將所有需求合理的抽象化,都需要經驗的累積,只求一件事就是要求自己不斷的進步!!!

這一篇是一點小小的紀錄,介紹的過程中有很多很多的範例程式,我覺得這個是十分棒的一件事!!
感謝各位大大收看 <(_ _)>