初入c++時便時常聽那些學業上的前輩談及面向對象編程，直到後來學習c++時用的基礎書籍也是名爲《面向對象程序設計-c++》，這無處不在的”面向對象“的4字出現的頻率很多時候甚至已經超越了c++本身，這也有時提醒我去注意這個捉摸不透的怪傢伙~~
多年之前，幾個屌絲的程序員再也無法忍受傻逼策劃無休止的改需求，奇葩用戶各種惡意的測試軟件的穩定性，時代發展所帶來的不停的軟件的更新與擴展，說的這麼光明，實際行動的時候卻全部都是程序員的加班，坑爹啊嗚，爲什麼受傷的總是程序員~~~~~ ，爲了改變這一現狀（賺了軟件行業這麼多桶金卻因爲加班而沒有時間吃喝嫖賭大寶劍簡直是是世界上最不公平的事了~），這幾個屌絲開始思考自己未來路的規劃~~，或是放棄，或是加班，也許是其他~~
世間萬物的起始都是有規律可循的，關鍵在於你是否能發現ta ~~，我始終相信這一點在此之前的多年之前，一羣建築師們聚在一起捫心自問：質量可以客觀評價麼？換句話說：情人眼中真的會出西施？是否可以從人們的美的理解中提取共識，提取美麗背後所代表的實際的優秀點，美是可以被度量的麼？答案的確是肯定的~~，在這裏，建築師所關注的美是建築的質量，如何設計纔可以使建築更加優秀？一扇門如何設計纔是一扇優秀的門？
而在軟件系統的設計中：也同樣存在這樣一個定理，軟件的質量是可以被度量和評斷的~~
這就顯而易見地牽扯出了倆個問題：既然軟件的質量是可以被評斷的，那麼對於軟件的質量的高低看法是存在共識的~~，而高質量軟件相對於低質量軟件他所優秀的地方在何處？而低質量軟件相對於高質量軟件，又有哪些是高質量軟件所沒有的？直至此處便得到了以下的結論：既然軟件的高低是可以判斷的，那麼必然我們可以找出一款軟件因何而優秀，一款軟件因何而拙劣~~~
而之前的那些程序員們也是顯然想到這幾點，綜合這些問題和那些大神們雄厚的項目經驗，他們逐漸發覺了一些規律，他們稱之爲模式，引用《設計模式解析》上面的一句話：模式即是某一背景下某個問題的一種解決方案~~。當然在這裏我更習慣於這麼解釋：某一情況下某個特殊問題關係的結構的特點與處理方法，“每一個模式都描述了一個在我們的環境中會不斷出現的問題，並進而敘述了這個問題解決方案的要素”，通過這種方式，解決方案能夠百萬次地反覆應用，但是具體方式又不會完全相同。“
我一直以來都特別喜歡James對於建築大師Alexander的《The Timeless Way of Buliding》一書中對”模式“基本原理那段文字的解析，堪稱對於設計模式的一種靈魂式解讀，大家有興趣的強烈推薦大家去找一下。
對於那段文字：最後得出瞭如下總結：
一個模式應當具備以下4點：
1：模式的名稱
2：模式的目的，即要解決的問題（這一點極其重要，這也是很多萌新錯用誤用設計模式的源頭）
3：實現方法
4：爲了實現該模式我們所必須考慮的限制和約束因素
通過這種對於模式的理解，我們從中藉由模式看到了觀察問題，設計過程和麪向對象的更高層次的視角，這也將我們從”細節“中解放出來
還有一點要說明的是：設計模式的本質並不是創造一種新的軟件設計問題的解決方法，而是將軟件設計界已經存在了的，反映了的優秀的設計經驗的方法識別出來；
至於過度處理細節這個問題我將爲大家帶來一個非常易懂的例子：現在有2個木匠之間討論“如何爲一個櫥櫃製作抽屜”的問題。
他們的方案分別是：
木匠A：加入爲這些櫥櫃做抽屜，我們需要在木料上直着據下去，然後迴轉45度再鋸，接着再直着鋸，再回轉45度再鋸。。。。。。。。然後就可以了。（聽上去就像代碼評審，無限的細節，全都是細節！！！）
木匠B：我們應當採用楔形櫃或者是方櫃？
不知道聽到這2個人的話的時候你們會有什麼想法，假設聽衆擁有最基礎的建築學知識，知道最基礎的建築結構。
面對木匠A我相信縱然那人擁有經驗也會是蒙逼的，即是他可以聽懂每一步所做的事，但是顯而易見的他很難從這大塊的零散信息中獲得這個木匠的目的和意圖，（也就是這樣做是爲了什麼？這個結構是什麼樣子）也就無法對它的想法作出任何評斷。
但是面對木匠B就相對地愉悅了太多了，應爲他們現在討論的是一個問題的本質上差別，他們討論問題的層次更高了，也更加抽象了避免了陷入細節的沼澤。當人們聽到木匠B的想法是，頭腦中便可以浮現出楔形櫃和方櫃的特徵，同時可以很快的想到這2種櫃各自的優缺點，這樣設計者們就可以就方案的優缺點進行有效的討論，而不用關乎那些底層的如何製作木櫃的無聊的細節。因爲討論這個問題時目標是明確的。
最後列舉一些對於優秀的面向對象策略的基本準則：
1：按照接口編程
2：儘量使用聚合代替繼承
3：找出變化並封裝之
最近也只有設計模式花了大功夫，寫的很撇，不成敬意，僅供娛樂~~~
