Long long long … years ago~
記得有把玩過設計模式的書
當時只看了一兩章就看不下去了…
後來發現對於一個沒有什麼開發經驗的人來說
根本就是無字天書
時過境遷，我想應該有足夠的知識將這些書看過
因此就將“大話設計模式”放入我的閱讀書單
並花了幾週的時間將它讀過
想藉這機會把讀過後的心得記錄下來
因為設計模式博大精深
以下的分享大多是經過自己的領會並不會照本宣科
所以若有錯誤的地方歡迎指正喔～

今天主要先介紹一些設計模式的原則
為何要先介紹原則呢
我認為若是原則抓準
設計模式背後的原理就會迎刃而解
那就先來看一下在軟工界的大師Robert C. Martin
對敏捷開發定下來的五大原則(SOLID)吧

1. S => 單一職責原則(Single Responsibility Principle)

就一個類說，應該僅有一個引起它變化的因素

以物件導向去思考就是一個類必須設計的高內聚力與低耦合
現實生活的舉例：
所謂的事務印表機就是有許多功能，例如：掃描、傳真、列印等等，但是當需要快速且大量列印時，還是需要真正厲害且功能強大的純印表機，因為整台機器都是以列印功能為導向去設計的

2. O => 開閉原則(Open-Closed Principle)

一個軟體的物件應該是可以擴展，但不給修改
(對於擴展是開放，對於修改是封閉)

以物件導向的觀念去看，一個類中藉封裝來滿足封閉，並藉繼承來滿足擴展；簡單的說，開發類時盡量要用私有變數或方法，若是有需要改動就藉由新增一個修改類繼承來達成
現實生活的舉例：
設計萬年曆時，時分秒之間就應該是封閉的，但是年月日就應該是可擴展的

3. L => 里氏代換原則(Liskow Substitution Principle)

子類必須能替換掉它的父類
(子類可以以父類的身份出現)

以物件導向的觀點，利用多型的技巧來呈現子類可以以父類的方式出現
現實生活舉例：
鼠牛虎兔…都屬於動物類，當動物類有的技能他們都會擁有，例如：吃、喝、看等動作，所以鼠牛虎兔都可以以動物類的方式做出這些動作

4. I => 介面隔離原則(Interface Segregation Principle)

不該強迫客戶端依賴他不會用到的方法
(介面屬於客戶端，不屬於它所屬的層次結構)

以物件導向的看法，介面要切得越細越好
現實生活舉例：
一般汽車的檔數為六檔，所以不應該為車去擴大這個引擎的介面；若真的要為F1設計引擎，就再多一個介面加上他需要的檔次就可以了，可能是七或八檔～到底有幾檔我就不知了

5. D => 依賴倒置原則(Dependence Inversion Principle)

抽象不應該依賴於細節，細節應該依賴於抽象

以物件導向的觀點，一個物件應該是is-a或是has-a抽象類或介面，不應該是is-a或是has-a一個具體的實例物件
現實生活舉例：
一台PC裡面的零組建都是針對介面去設計的，例如：主機板之於記憶體，無論電路如何設計只要主機板跟記憶體使用同一個介面去設計就可以彼此協同運作，就可以做到零組建抽換，無論如何廠牌或型號都可適用

PS: 想要自己開發的軟體非常健壯嗎？那就要堅守住“SOLID”(牢靠堅固的)的原則喔～