在這邊紀錄一下看完大話設計模式的心得與重點
文末附上我練習過程的程式碼
書籍介紹
書中藉由兩個工程師的對話，與現實發生的情境來介紹Design Pattern，對我在學習Desgin Pattern的抽象概念幫助很大
將書中的例子都練習過一遍，收穫滿大的。
Design Pattern 的根本-物件導向
物件導向的語言特性
封裝：將變化封裝至函式中，外部程式碼在使用時只需要知道方法簽章，不需要了解內部實作的細節。
繼承：可以從父類別衍生出子類別，子類別可以實作屬於自己的函式。
多型：從父類別衍生出的子類別，可以替代子類別，而不會出錯
物件導向程式設計的基本原則 - SOLID
單一職責(Single responsibility principle)： 對一個類別來說，應該只有一個引起他變化的原因。如果類別承擔的職責太多，在產生變化時，會遭受意想不到的破壞。如果你想到超過一個原因去修改類別，那該類別就承擔了過多的職責。
開放封閉(Open/closed principle)：設計類別時對類別的擴充保持開放，對修改保持封閉。當面對需求變化時，一定會有無法封閉的變化，這時候就必須構造抽象點來隔離那些變化。
里氏替換(Liskov substitution principle)： 子類別必須可以替換他們的父類別，子類別的可替換性使得父類別的模組在無需修改的情況下可以擴展。
介面隔離(Interface segregation principle)： 針對介面程式設計，而非對
實現(Implement)程式設計。抽取相同功能形成介面，讓各類別去實作，對呼叫的程式端來說，只須在意開放出來介面提供的功能，且將來需要抽換時只需要實作相同介面的類別即可。依賴倒轉(Dependency inversion principle) 高層模組不應該依賴低層模組，兩者都應該依賴抽象。模組之間如果太過耦合，很容易出現改了A被迫要修改B，如果都依賴抽象，兩者都只要關注自己本身即可。
我的看法：在練習與反思的過程中，我自己認為Design Pattern是兩面刃
程式面
- 它有效解決了某些特定問題，讓程式的架構更為漂亮，也更好擴充跟維護
- 留下擴充點可以為後來功能擴充做準備，但擴充點不一定都會用到
管理面
- 如果團隊成員經驗不是那麼足夠，會無法理解Design Pattern的意義與實作
- 如果任何需求都要套用Design Pattern，會造成過度設計(over design)，在技術決策上需要多加考量
結語
學習Design Pattern的時候，也要思考要如何使用它，只要有掌握物件導向的設計原則，不必一定要拘泥於某一些Pattern，或許你也可以創造屬於你自己的Design Pattern，因為Design Pattern本來就是解決特定問題的方法。
我附上我練習的程式碼，每一篇都有節錄介紹與重點，請大家自行參考囉