• Revisit SOLID
  • 程式碼異味 (code smell/design smell) 的表徵
  • 重點摘要：單一職責原則
  • Summary
  • Further reading

Revisit SOLID

YouTube - Fred 聊聊 SOLID 設計原則 - 約 2 小時

講者資訊 Shih-Peng (Fred) Lin (linkedin)

• 現任街口支付 CTO
• 此 talk 是 Fred 為了街口內部的內訓教材所錄製的影片，包含了 Fred 針對 Uncle bob 自 198x 起至今的文獻重新整理以及對 SOLID 更深一層的體悟
• 充分利用實務情境說明何謂 SOLID，不會有搔到癢處的感覺

Robert Martin (aka. Uncle Bob) 提出了 SOLID 五項原則，若程式設計能夠應用這五項原則，將使程式變得更加容易進行維護及擴充。

你可能找過許多文章試著了解這五大原則，然後心中出現以下疑問：

• 單一職責原則中，何謂「單一職責」？職責的範疇到底在哪？
• 開放閉合原則中，我可以接受一個設計良好的系統應該能夠在不改變原始碼的前提下輕易擴展，但到底怎麼做？
• 依賴反轉原則中，何謂「應該依賴介面，而非依賴具體實作」？
• 找到的文章舉的例子都好抽象，覺得搔到癢處。到底在我實際 programming 中何處適合使用？

程式碼異味 (code smell/design smell) 的表徵

代碼異味 - Wiki

Uncle bob 自從 35 歲起不斷到處跟人筆戰、倡議一個論點：他認為軟體工程最大的痛點就是「可維護性」。

並深究出影響可維護性的本質：即是程式碼的 「耦合 (coupling)」 ，aka. 「相依性 (interdependence)」。

RECAP
與前述 John 的觀點「complexity comes from dependencies」相呼應

又所謂的「程式碼異味」、「設計壞味道」，指的就是那些有較差維護性、較高耦合、較高相依性的軟體有的表徵：

SLOID 的本質是在試圖解決系統組件之間過強相依性的問題

• 降低相依性產生的問題，一定程度上就是降低了系統複雜度

重點摘要：單一職責原則

以下簡單摘要此 talk 中對單一職責原則的討論：

• 增刪改查到底算幾個職責？

• 其實關注點應該是 「人」，你的業務需求方是誰，他們的需求就是你的 app 的職責

• 這項原則是一個「概念」，它同樣可以用來指導如何設計 function/class/module/package 、 database table schema 、 甚至到 microservice

• 翻閱一下 Uncle Bob 自己的 blog，的確有提到 SRP 要關注的對象是 people

Summary

SRP 是此 talk 最先討論的主題，承先啟後地再帶出與其他四個原則的關係。原內容有舉一個實務的例子來輔助說明 SRP，請再自己閱讀原始影片囉，保證會獲得非常多啟發。

Further reading

Fong - 你真的懂 SOLID 原則嗎？