終於來到鐵人賽最後一天，從去年準備轉職、初步學習完程式語言後，就有從前輩們聽說某些基礎是很重要的，例如資工的基礎科目資料結構、演算法、計算機組織、作業系統···等，而設計模式是其中之一。
在去年時就有購買相關書籍，並且稍微看過其中某幾種模式，不過整體有計劃(被鐵人賽強制)的學習，還是在這30天之中才初步對於每個模式有一次的認識，對於整體程式思維我想會有一些幫助。
有人說用C寫資料結構是為了熟悉和認識指標的使用，而設計模式是為了讓利用這些大家整理出來既有的模式，熟悉並且認識介面的使用。當然物件導向程式設計不是唯一的程式設計範式，除此之外還有結構化和函數式程式設計(或許更多!)，我認為在這些設計範式之外，是一直在進步的程式思維，而未來可能會有人覺得設計模式已死，但其中撰寫程式碼的思維則會融入程式設計師的骨髓和血液中，並且往下一個世代的程式思維進化。
每天寫作不知不覺已經30天完賽了，如果不參加這個活動我可能沒辦法這麼快的把設計模式看完有一個了解(聽到這個東西也過一年了)，看到前面的文章感覺沒過多久，這三十天雖然自己沒有感覺進步很多，但是也稍微掌握了一些關於設計模式的眉角。鐵人賽這個活動很有意義，在過程中會經歷很多取捨···，聚餐、出去玩或是工作之類的，都會壓縮到寫文章的時間，文筆、文章結構和寫作架構思維，因為過去比較少鍛鍊到這部分的技能，所以在過程中也覺得自己進步很多(所以現在看到前幾天的文章會覺得有點慘不忍睹)。
最後感謝30天前的自己有勇氣參加鐵人賽。
拿出勇者鬥惡龍的勇氣，我們一起超越不可能！
除了昨天介紹的，在 GoF 四人幫 的 Design Pattern 中，還有下列這幾種行為型模式。
給定一種語言，定義它的文法的一種表示，並定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子。
用一個仲介者物件來封裝一系列的物件互動。仲介者始個物件不需要顯式地互相參考，從而使其耦合鬆散，而且可以獨立地改變它們之間的互動。
表示一個作用於某物件結構中的各元素的操作，它使你可以在不改變各元素的類別的前提下定義作用於這些元素的新操作。
是最複雜的模式、很少用到，必須考量使用的時機。
定義一系列的演算法，把它們一個個封裝起來，並且使他們可相互替換。本模式使得演算法可獨立於使用它的客戶而變化。
不破壞封裝的前提之下，捕獲一個物件的內務狀態，並在該物件之外保存這個狀態。這樣以後就可以將該物件恢復到原先保存的狀態。
將資訊利用類似備忘錄的形式儲存，封裝後可以做到快照各個狀態的效果，像是photoshop的筆觸紀錄功能。
提供一種方法依序存取一個聚合物件中各個元素，而又不需暴露該物件的內部表示。
已經廣泛應用在各個程式語言或是資料庫中。
這些設計模式(方法)其實沒有高下之別，而是根據需求狀況使用最適合的模式，或許因為現在的需求，流行和經常被使用的只有根據其中幾種模式來擴展，但不代表之後不會有其他的設計思維，系統化的淬煉出更精簡並且容易理解的撰寫程式方式和系統設計的思考方式。
參考資料
-- 大話設計模式
-- Android源碼設計模式解析與實戰
-- Design Patterns in Object Oriented Programming
-- 無瑕的程式碼－整潔的軟體設計與架構篇
iThome鐵人賽
看影片追技術