老師說：｢設計模式是把許多常遇到的問題做成模式，來方便大家溝通和解決問題」

你老師講得很明白，但是你好像聽得很模糊，才會問了這個奇怪的問題：

目前台灣軟體界 是否有常常用到設計模式?

你把設計模式換成另外一個字『最佳實務』來看看你問的問題奇不奇怪？

在某個情境下需要解決某些特定問題，我們設計了一套方法去處理，這個稱為實務。接著你發現還有許多人也遇到了同樣的問題，並且採用的方法與你的類似或一樣，大家都認為這個問題這樣處理好，那就可以稱為最佳實務。

那麼設計模式就等同於最佳實務嗎？當然不是，不然就不需要另外建立一個名詞了。最佳實務這詞含意太廣泛，以至於從程式的換行要怎麼換，到整個系統架構要怎麼設計，都能叫做最佳實務。而設計模式則比較著重在設計這一塊，物件之間要怎麼互動，職責怎麼劃分，或是如何克服語言的一些缺陷或不便等等。

因此設計模式其實無處不在，既然身為程式『設計師』，那就無法避免的會遇到各種設計上的難題。這些難題八成別人也曾經遇到過，並且有了解決方法，只是你知道或不知道而已。如果你想要確保你的類別只會有單一一個物件，並要讓所有用到這個類別的地方都共用同一個物件，把這個問題丟上網路去查，你會查到 Singleton 這個模式。想想看如果這個作法沒有一個名字，你要怎麼去形容他？『在類別裡面增加一個靜態方法，在這個方法內建立並回傳唯一的一個物件，同時將建構子設為私有的以避免直接呼叫 new 建立更多物件。』

比起用一大串的描述來講解這個作法，不如直接給他一個名字，這樣子在溝通上以及學習上都會更方便。設計模式其實就只做了這一件事情，把一些常見的作法適用的情境與問題整理出來，並給予一個方便好記的名稱。所以樓上有人說了『也會有那種…其實就在用，只是自己沒注意到的狀況。』，差別只在於你知不知道這個作法叫這個名字而已。

另外一種情況，是你遇到的問題很難三言兩語描述得很清楚，以至於很難馬上找到好的解法。設計模式其實整理了一些這類不好描述的問題。如果你能將一些常見的設計模式都看一看，理解各個模式所要解決的問題是什麼。這就像多認識了一項工具一樣，當你遇到這工具能派上用場的時候就能想起來。對於軟體開發這個領域也會更加瞭解，同時也是一種實力的累積。

以上不知道有沒有解答到你的疑惑？

最後建議在學習設計模式的時候，重點應該放在這個模式適用的情境以及要解決的問題，實際上程式怎麼寫的反而並不是那麼重要。如前面所說設計模式其實就是針對特定問題的一個解法，你把所有的程式都背起來但不知道什麼時候使用是沒幫助的。學習設計模式應該是要在遇到某些問題時，能想起來好像有這麼一個模式是在解決類似的問題，這時候再去查看看適不適用，以及細節到底是怎麼做的就可以了。

在課堂上老師說：｢設計模式是把許多常遇到的問題做成模式，來方便大家溝通和解決問題」

這是對設計模式的誤解, 設計模式(Design Patterns)只是一個小範圍的軟體設計技巧, 以物件導向觀念來看, 指的是物件的設計模式, 和物件的封裝, 繼承, 多重, 使用, 重用, 與管理相關, 用於物件與所處系統的溝通, 起不了什麼"人類"溝通的效用. 如同多年前有個鬼把建構式數學從腦海裏掏出來, 告訴無辜的學子說, 學這個吧, 那是學好數學的捷徑. 其實, 如同建構式數學一樣, 設計模式是腦海中的自然反應, 也就是天資聰穎的那一部分, 說是方便溝通與解決問題實在是倒果為因.

真正方便溝通與解決問題的是架構模式(architecture patterns)和架構風格(Architecture Styles), 如微核心(microkernel), MVC(Model view Controller),...等等. 相對以管窺天的設計模式, 架構才是全面性的, 才能讓人類溝通, 解決問題. 我不知道台灣的大學是否教架構模式, 也許只是帶過吧.

這並不是設計模式不好, 那是一定要會的物件建構觀念,就只是這樣, 花個一堂課就夠了. 至於業界是否使用? 當然有用, 善於運用設計模式可以降低物件耦合程度, 產生較穩定的系統基石.

這問題類似另一個提問[學寫程式要懂這些演算法才行嗎？]
其實這些都可以歸結到一個課題：技術實踐與學術理論的差距到底有多大？！
淺白來說明，就類似你聽過聽懂三十六計！但你用在你工作、生活...有多少？
大多數的麻瓜們，只要會吃吃喝喝就能過日子了。
但若你多讀了些書，多懂了些理論。
你就多了些機會出人頭地~
如此而己~