在真正說到設計模式前，還是要稍微帶過物件導向的SOLID原則，不然只看前面的分法應該是無法理解接下來設計模式的寫法是為什麼要這樣做的。

SRP：單一職責原則

• 一個類別應該只有一個變化原因
• 相似功能的東西放在同一類別，不同的放到別的地方

以先前舉例的Unit例子來說，它裡面的內容就包含了戰鬥數值、尋路演算法、攻擊計算、動畫演出這些的實際做法，可以說是完全違反單一職責原則這件事，真正好的方式是把這些實際做法隔離在其它Class裡。

OCP:開放閉封原則

• 實體是可擴展但不可修改
• 將相同的部分取出來或抽象化來保持封閉性
• 在最重要的特性開發出來的同時不斷地觀察變化，將變化最多的部分抽象化
• OCP的機制主要為abstract跟polymorphism

以程式的方式來說，操作方法向上提升，抽象化為interface或abstract類別，將功能的實作往下移到subclass中。用現實的案例舉例的話，我會以現實的法律為例，如果公民教內容還沒忘光光的話，那應該會知道憲法是所有法律最高層的規定，只要違反這些規則的下層法規通通無效，我隨便舉一個例子，那我隨便舉一個例子，第 13 條，人民有信仰宗教之自由。那要是今天人民信了一個邪教那該怎麼辦？又或者這些宗教跟人民收錢，結果最後被發現是詐騙時又該怎麼辦？這些都不是憲法會去制定的範圍，而是民法或刑法這些法規會去規定的範圍。

如果更難懂的話，就...自己去翻閱參考連結的書籍看看他們說的能不能讓人比較懂一點吧，如果有想到更好的之後再改。

LSP：Liskov替換原則

• 子型態(subtype)必須能夠替換掉它們的基底型態(base type)
• 其實就是繼承(inheritance)

這邊我直接畫圖比較快

如上圖所示，Unit並沒有依賴於任何PushAbility或MoveAbility的subclass，而這兩個繼承IAbility的實體類別都可以替換IAbility型態，這就是LSP。

ISP:介面分隔原則

• 功能的切分
• 介面的簡化

以我的理解來說，interface應該要盡量不要塞太多的function在裡面，不然就會出現明明沒用到該功能卻還是要實作出來，在程式碼的呈現會十分多餘，不過實際上的到底要切多少還是要考量一下實際上這些功能存在的意義。

DIP(The dependency-inversion principle):依賴反向原則

• 高層模組不應該相依於低層模組，兩者應該相依於於抽象
• 抽象不應該依賴於實作。實作應該依賴於抽象

簡單就是這些東西應該是放在像是Interface或abstract這種地方來獲取資料，而不是直接從實作類別獲取。再以LSP的圖片說的話，就是Unit不會直接從PushAbility跟MoveAbility獲取甚至改變資料、而是透過IAbility這個抽象化類別獲取。

今天的物件導向介紹就大概這樣，下篇將要進入這次編排中最多篇的章節—設計模式啦！

參考連結

無瑕的程式碼：整潔的軟體設計與架構篇