設計模式學習筆記 - 1

發表於 更新於 分類於 ，

寫在前面

這個系列的筆記，是從《深入淺出設計模式》開始學習常見設計模式，將自己的理解整理起來，供後續回頭來看的時候可以更快查詢，也提供給有需要的人。
每一篇的的篇幅可能都不長，也許理解上也有一點出入，期許自己未來能在各個專案的規劃中，取出適合的模式來應用，打造更好擴充及維護的開發專案，
也希望未來實做上有用到的時候，可以回頭來補充應用情境及設計的想法。

剛開始學習的時候，很多設計模式都需要花時間想一下，過往的專案經驗中，有沒有哪個部分是適合用在當下學習的設計模式？
如果有要怎麼調整，與當時候的寫法有什麼不同；如果沒有，就只能從書中的範例去延伸思考。
每個設計模式的篇幅不多，但需要思考及理解的時間都不少，也很多時候看完一個設計模式，但腦中沒有任何概念，就只能先將當下的理解記錄下來，
如果剛好有路過的大大，願意指點迷津或是一起討論，衷心感謝。

在學習設計模式之前，會需要先補充一下前期知識-物件導向的基本原則，設計模式都圍繞著這幾個原則，所以必須要先有概念才行。
所以第一篇的內容算是前導及打底，有了基本概念後，再慢慢學習及瞭解各設計模式，遵循這五個原則，能幫助我們再規劃專案、架構的時候，
設計出好維護、易擴充的程式架構：

物件導向設計基本原則-SOLID

S: Single responsibility principle(SRP) 單一職責

每個物件，不管是類別、還是函式，都只負責自己的一件事情，這樣一來可以避免同一個函式包山包海的做了一堆事情，真的需要調整的時候發現沒辦法把功能切出去。
就好比一人公司的創業者，需要自己跑業務，記帳，規劃功能，開發等等，一旦生病了，所有的事情都會停擺。

O: Open/close principle(OCP) 開放/封閉原則

保有擴充及修改的彈性，當專案發生需求變更時，如果耦合度太高會發生難以改動的狀況，這時如果改了原本的函式，但會影響到所有有使用到這個函式的地方，
因此保有彈性。當舊需求要調整，要確保不會影響其他地方；而新需求提出應可獨立開發。

L: Liskov substitution principle(LSP) Liskov替換

子類別應該可以執行父類別想做的事情。假設父類別是可以裝水，而且可以自己加熱的快煮壺，今天將傳統的茶壺當作子類別來實做此父類別，
會發現茶壺可以裝水，但無法自己加熱，需透過瓦斯爐或電磁爐才可以達到加熱的效果，則這種情況就不符合里氏替換原則。

I: Interface Segregation Principle(ISP) 介面隔離

針對不同的需求，提供對應的介面，避免在調整的過程中，彼此互相影響。

D: Dependency Inversion Principle(DIP) 依賴反轉

定義：高階模組不應依賴低階模組，兩個都應該依賴在抽象概念上；抽象概念不依賴細節，而是細節依賴在抽象概念。

舉例來說，假設高階模組＝人類，低階模組是計算機。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

class Human
{
    public function count($x, $y) {
        $calculator = new Calculator;
        return $claculator->add($x, $y)
    }
}


class Calculator
{
    public function add($x, $y) {
        // ...
    }

    public function minus($x, $y) {
        // ...
    }
}

人類在計算的時候，直接使用了計算機的add function，這種情況稱為高耦合。萬一計算機沒電，臨時需要將古董算盤拿出來使用，就必須要去調整程式碼。
但若計算工具是介面，並且透過外部指定好工具後才傳入給Human，就不會有問題了，這種作法稱為依賴反轉。

以上是今天的內容，下一篇開始會正式進入設計模式的部分，預計每篇記錄不超過兩個設計模式，
也許進展緩慢，但希望能有充足的時間思考，讓學習的效益更大化。