設計原則大集合

OOAD中除了分析案例,需求清單,架構設計等概念性的東西外,最終還是必須將專注力放在程式碼撰寫上頭,這時候設計原則便將發揮作用。

設計原則是一群能夠被應用到設計或撰寫程式碼的工具或技術,讓程式更好維護,更具有彈性與擴展力。

1. 開閉原則 (OCP, Open Close Principle)

"類別應該允許擴展而開放, 禁止修改而關閉" --- 例如: 你寫出一個完美的類別,當同事想要使用時,你所建構的類別當然不允許直接修改其中內容而變成兩個不同類別(禁止修改),同時必須能夠以達成他人目的繼承覆寫(允許擴展)。 但是...OCP的重點並不在於繼承,而是"彈性",所以只要記住大方向(類似封裝與抽象的意涵),你也可以使用合成等方式達到此目的。

2. 自我不重複原則 (DRY, Don't Repeat Yourself Principle)

"抽取類別中重複的程式碼,置放於單一地方" --- 這個道理淺而易懂,假如這次專案中一堆類別裡都有copy-paste的程式碼,哪裡用到哪裡就放,半年後打開來修改應該會有一點當初到底在做甚麼的感覺...偉大的軟體其中一個重點就是好維護,就算工程師多厲害,寫出來難以維護的軟體就是垃圾,能夠輕易修改達成用戶需求才是王道,而且DRY原則如果做不好,表示架構流程設計有很大問題。

3. 單一責任原則 (SRP, Single Responsibility Principle)

"系統中每一個物件都應該聚焦在單一責任,同時也只具有單一責任" --- 每一個物件只能有一個理由改變,假若汽車類別中有駕駛方法不是很奇怪嗎?駕駛應該是操作者的責任才對。 偉大軟體條件之一: "高內聚低耦合",但有些沒經驗的工程師可能會把類別分成太細,細到甚至螺絲釘都成了類別,請注意:做軟體該做的事,別吹毛求疵。

4. 替代原則 (LSP, Liskov Substitution Principle)

"子型別(sub type)必須能替代其基礎型別(base type)" --- 這關乎著良好的繼承關係,假如有一天你發現子類別不能夠取代父類別,那表示繼承關係出錯...

這樣可能很難懂,舉個例子: 有一個平面地圖類別,其中有方法 get(x,y),現在要寫另一個3D地圖,你想說要繼承平面地圖,好的,當調用方法時取出x,y軸...z呢??

這種時候絕對不能使用繼承,不用擔心,還有其他的方式讓你完成你該做的事。

委派 --- 在3D地圖類別中直接使用平面地圖的方法get(x,y),不改變它的結構,讓他幫你取代x,y軸,3D地圖類別中再自己規劃z軸設計。

之外再提兩個方式:

(1) 合成 --- 能夠使用一組其他類別的行為,並在執行時期隨意切換。 (2) 聚合 --- 一個類別可以是另一個類別的一部份,但仍然能夠存在於該類別之外。

以上為設計原則,了解之後對於物件設計將會事半功倍!!