最近看了兩本關於設計模式的書，在此記錄一下感想。
第一次聽說設計模式是在網上查詢MVC模式的時候，順便搜了一下設計模式，才瞭解到武林中存在着“23種設計模式”這麼個東西。當時以爲覺得設計模式就是倚天劍、屠龍刀，一個代碼寫的很爛的菜鳥看了設計模式就會成爲“武林至尊”，代碼水平立刻變得很厲害。學習了之後才知道我想錯了，設計模式只是倚天劍和屠龍刀中的“九陰真經”，就算得到了還是要苦苦練習，結合實際的編程和項目才能夠把其中的思想融會貫通，真正成爲一個編程高手。
“設計模式”是一套被反覆利用、被多數人知曉的、被無數工程師實踐的代碼設計經驗的總結。因爲它比較抽象，沒有一定編程經驗很難讀懂，更不能理解其精髓。23種設計模式總體看下來，有的當時就能理解，有的需要思考一番才能理解，就像以前不會的很難的那種數學題，看了答案，跟着答案的思路捋一捋就理解了，然後下次遇到類似的題稍微變一變又不會做了。這次初探設計模式也是一樣，合上書之後自己寫代碼，很難想到該怎麼將剛學到的設計模式用到自己代碼中去，或許這就是經驗太少的原因吧。
我最大的感受就是單一職責原則、開放封閉原則、依賴倒轉原則、里氏代換原則、迪米特法則、接口隔離原則這六大設計原則比設計模式更加重要，如果說設計模式是面向對象編程的編程思想，那麼設計原則就是這些編程思想的指導總綱，而這六大設計原則的目的又可以概括爲六個字，就是“高內聚，低耦合”。（感覺看完書我就記住了這六個字）高內聚就是說，設計的接口內部功能要單一緊湊，不要想起什麼都往裏面塞，最後搞的非常臃腫，沒有辦法複用。然後低耦合是說，設計的接口之間的關聯要儘量小，不要出現更改一個地方的時候牽一髮而動全身，幾十個地方都要跟着改，要不就沒法用。說起來我們學習設計模式的最終目的就是要實現代碼的最大化複用。
單一職責原則：一個類只負責一項功能或相似的功能，承擔儘可能少的職責。這樣可以增強可讀性，方便維護和修改，當然缺點就是在小的項目裏運用會顯得拆分的太詳細，類的數量會急劇增加。（然後就想着反正是小項目沒必要考慮單一職責原則，然後後後來項目的功能越加越多，又變成了又臭又長的爛代碼。。。）
開放封閉原則：類、模塊、函數等對擴展開放，對修改封閉。增加一個功能時，應當儘可能的不去改動已有的代碼，當修改一個模塊時不應該影響到其他模塊。（這個相信大家不能同意更多，因爲誰也不想讓原來跑的好好的代碼經過自己的手之後，出現各種奇怪的問題，所以不會去想動以前的代碼。問題是根據我的經驗，由於“已有”的代碼在設計的時候沒有考慮“低耦合”，導致改動的時候牽一髮而動全身，不得不去動已有的代碼。。。）
里氏替換原則：所有能引用基類的地方必須能透明地使用其子類的對象。只要父類能出現的地方，就可以用子類來替換它，反之，子類能出現地方父類不一定能出現，因爲子類擁有父類的所有屬性和行爲，但是子類拓展了更多的功能。子類重寫父類方法的時候功能不能改動太多，功能實在差很多的話就不要重寫了，應擴展一個新方法，這一點我做的很不好。
依賴倒置原則：高層模塊不應該依賴低層模塊，二者應該依賴其抽象。把具有相同特徵或相似功能的類，抽象成接口或者抽象類，讓具體的實現類繼承這個抽象類。抽象類（接口）負責定義統一的方法，實現類負責具體功能的實現。
接口隔離原則：用多個細粒度的接口來代替由多個方法組成的複雜接口，每一個接口服務於一個子模塊，不要試圖建立一個很龐大的接口供所有依賴它的類調用。這其實還是強調“高內聚”的事兒。
迪米特原則：一個對象應該對其他對象有最少的瞭解。對象與對象之間應該使用儘可能少的方法來關聯，避免千絲萬縷的關係。這其實還是強調“低耦合”的事兒。
設計模式在編程中的作用，就像《孫子兵法》在戰爭中的作用。設計模式是前輩們歸納總結出來的指導思想，對設計模式的運用不能紙上談兵，豐富的項目經驗是很重要的。不同的階段來看看這些理論，會有不同的收穫。這次只是初探，隨着以後的代碼寫的越來越多，還要隨時注意學習和運用這些設計模式。