設計模式之禪精述
在9月初花費20天左右的時間看完《細說PHP》後，稍作感慨開始《設計模式之禪》的閱讀，堅信讀萬卷書行萬里路，這裡作讀後記錄和小結；
前言
在之前看過的不少相關程式設計類的書籍，幾乎都會把軟體設計和建築工程做比較，然後就是從建築的底層地基講到高層建築的順序和其中的一些概念來類比軟體設計。這樣子的話，我覺得設計模式是和建築能否能夠經受住時代審美的考驗（擁抱變化–也是最基本的設計原則（開閉原則的初衷））有關聯的。
聰明的人，把房子蓋在磐石上；無知的人把房子蓋在沙土上；而對於開發者而言，設計模式就是堅固的頑石； -----Java開發者社群
目錄
**
一、設計模式之禪總述
**
禪是佛家用語，有‘參禪’，‘悟禪’等說法，像是一些高深莫測、深奧的道理；而設計模式之禪，我理解中，一是設計模式本來就是行業前輩總結、歸納出來的優秀、高深、值得人深思的設計指導思想，智慧結晶；二是學習設計模式需要像參禪悟道一樣，靜心思考，學以致用，因為世界上最難的事情有兩種：一是讓人心甘情願的把錢掏出來給你；二是把自己的思想灌輸的別人的腦袋裡。
設計模式是為了擁抱變化，總結出來的一套設計模式：分為六大設計原則，和二十三種設計模式；六大設計原則是由開閉原則衍生，通過不同方向的抽象而形成，也是設計模式的指導思想；二十三中設計模式則是在不同情景下的設計實現方式；
問題來了，為什麼是擁抱變化而歸結的呢？
在一個產品的生命週期中，遇到變化是不可避免的，而適當的擁抱變化，會整體提高系統的穩定性、靈活性；
**
二、設計模式之禪–六大設計原則–單一職責原則
**
單一職責設計原則指，一個介面或者類只有一個原因引起變化；即儘可能的使類、介面功能單一化，在提高程式碼重用性、可讀性、可維護性、可擴充套件性的同時，減少類或介面的複雜度，變化到來時的開發工作量。
舉個栗子，一個類中記錄了原始人的語言、居住地資訊，此類的每個例項代表了一個原始人；
隨著時間的變遷，語言、居住資訊可能其中一個或兩個都發生了變化，那麼此時用之前的類例項代表每個人就不準確。
方案對比：如果堅持之前類的話，生成例項時針對每種情況都要改動語言、和居住資訊的原始碼；包括生成例項的場景程式碼；如果採用語言和居住信心分別對應抽象類或者介面的話，只需增加每種語言和居住資訊的實體類或方法，之後在每次生成例項時，只需要呼叫合適的實體或方法即可。
注意：在進行職責單一化的過程中，可能會出現類之間的耦合度增高的情形，這裡可以通過實現多個介面進行解耦操作；
**
三、設計模式之禪–六大設計原則–里氏替換原則
**
里氏替換原則指，只要父類出現的地方子類就可以出現，而且替換為子類也能正常執行；
這裡呢，丟擲幾個學習中的問題：
抽象類是否可以例項化?
Java和PHP中的抽象類、介面是否有區別？
是否能夠通過判斷擁有方法體來區分抽象類、介面？
類之間的委派機制是指什麼？
物件的上下轉型中，為什麼向下轉型會丟擲異常？
DWSL介面是指什麼？
為什麼要求父類的前置條件較大？
答案待續