先說我的結論，要學，但可能用不到!
看了我的答案，有的人可能會覺得很矛盾，別急...先看完我的想法。
物件導向核心就三件事:
- 封裝
- 繼承
- 多型
而這三件事又能延伸出多項原則，來讓這三件事能發揮最大價值，這些原則分別是:
- SRP 單一職責原則
- OCP 開放封閉原則
- LSP Liskov 替換原則
- ISP 介面隔離原則
- DIP 依賴反向原則
- LKP 最少知識原則
如果用武術來形容軟體的概念，上面提到的就像是武功心法，用文字去描述武功的重點，輔助避免練功時練錯方向，而設計模式就像是武功中的招式，在招式中去體會心法，心法幫你練成更棒的招式。
所以如果想體會物件導向，就需要透過學習設計模式去體會封裝、繼承、多型是要怎麼應用，又為什麼要衍伸出多項原則。其實它們的核心都只有一個，就是為了『替換(修改)』，當然如果可以，學習軟體測試也是其中一環。
至於為什麼會用不到?因為很多框架都實作了設計模式，所以如果你用的框架說自己很靈活、很好修改，那他一定用了很多設計模式在裡面，像Spring、Android等，裡面處處都可以看到設計模式的蹤影。所以如果不是自己設計框架，通常...不會用到設計模式。
那....我們就不用學嗎?當然不是，開頭的結論就說了，要學!它會讓你知道封裝、繼承、多型的重要性，讓你在寫程式的時候將這些放進你的程式與思考之中，再者雖然設計模式不常用，但一旦用到，它會產生非常高的價值!
有看過一些反對設計模式的說法是，設計模式是毒瘤，拖慢了我們整個專案，把一件小小的事情搞得很複雜。
對於這類的說法，我只能說，也許他們的看法是對的，那你們幹嘛硬套設計模式呢?通常會遇到這種狀況的，我都覺得是"教科書症候群"，就是指教科書上怎寫，它們就不思考到底有沒有效益，只會說教科書就是這樣寫!一定要這樣做才是正確!最後被虐千百次之後，憤怒的將教科書砸在地上，大罵"此書誤我人生"。
舉個生活中的例子，就像你只是想走到巷口便利商店買瓶飲料，走路大概只需要五分鐘，你也可以騎機車或開車，但你硬要選開車，只因為汽車最快、最安全，然後出車庫找車位卻花了十分鐘以上，然後來抱怨說汽車不好類似。
最後總結一下，學設計模式可以讓你對物件導向的概念更清楚，而當你觀念清楚之後，什麼時候該用，什麼時候不該用也就會明白了。這就像金庸筆下的獨孤求敗，一開始拿利劍，後來拿重劍，最後草木皆可為劍，無劍更甚有劍的道理大概就是這樣吧。
最後希望你帶走知識的同時，也能留下短短一兩句的心得與我們分享
留言
張貼留言
有什麼想法歡迎跟我們分享