開年做總結的時候說，今年要搞一搞phpunit、設計模式等。測試的坑我已經填了，今天開始來填設計模式的坑了。
之前看文章（不記得是哪兒了，對不起啊，作者）說：設計模式這個東西，是因為我們思維的侷限，沒辦法設計出乙個架構良好的系統，所以搞出了這樣的東西來滿足我們的需求。乙個完美的東西應該是簡單的，而我們再看設計模式的時候，常常被其左一下、右一下搞得暈暈的。因此，這位大牛覺得，在系統開始之初是不應該或者盡可能少的使用設計模式，讓自己的**跟簡潔、簡單。更容易懂。
對於這位大牛的話，我深以為然。說說自己的例子。我自己做的乙個系統，其中有一種個邏輯有七八個if…else…。然後看那**我只能抓狂。然後就用狀態模式重構了一番。執行流程，邏輯清楚，呼叫簡單。當然這是我自己的評價。後面有一天又新增了乙個狀態，這還不是so easy？設計模式就是用來解決這些問題的呀，方便擴充套件。
然後就讓我這一組的乙個同學在我之前的狀態模式中，新增加乙個狀態類。結果，過了半天他過來問我，我這個類時怎麼執行的？打斷點看了執行流程還是不明白其原理。呵呵…說到這裡，相信很多人有這樣的體會。看不懂設計模式。
ok，說這麼多閒話，主要是為了表達兩個意思：
1. 大牛說的對，能夠不用設計模式就很好解決擴充套件、維護的問題，就別過度設計。因為設計模式也許你懂，但是換個實習生來做（也許工作兩三年的也不一定懂）維護，他根本不知道你為什麼要把**搞成這樣，乙個方法，七八個if…else…多好呀！
2. 設計模式挺不好搞明白的，而且隨著時間推移，有多個變種，以及多種組合使用的方式。因此我才覺得寫一寫自己實踐中使用的東西。我是這麼想的：23種設計模式，我可能不會全部都寫一次，畢竟很多東西，我們做業務可能一輩子都用不到。
既然設計模式這麼屌，肯定他必須遵守某些規範。比如平時我們自己的**，就是因為每個人都按照自己的「個性」來搞，然後到最後，就慘不忍睹了。所以為了便於擴充套件、維護。設計模式應該有乙個規範。對於這個規範，之前我還想來裝裝逼，後面看了看網上的資料，覺得實在沒有我裝逼的空間了。裝逼的位置留給他：
[1] 設計模式六大原則（1）：單一職責原則[2] 設計模式六大原則（2）：黎克特制替換原則
[3] 設計模式六大原則（3）：依賴倒置原則
[4] 設計模式六大原則（4）：介面隔離原則
[5] 設計模式六大原則（5）：迪公尺特法則
[6] 設計模式六大原則（6）：開閉原則
設計模式 六大設計原則
剛剛結束設計模式學習時，感覺哪哪的抓不住重點，雖然之前師傅給勾了寫比較重要的設計模式，但是給我的感覺設計模式怎麼全都乙個樣子。通過對一些文章的瀏覽，簡單的對設計原則總結了一下。設計模式，就是設計範例。是經典問題的解決方案，是可以讓學習者舉一反三的，有研究價值 有交流價值的例子。設計模式的本質是物件導...
設計模式 六大設計原則
solid s 單一職責原則 o 開放封閉原則 l 黎克特制代換原則 i 介面隔離原則 d 依賴倒轉原則 故事 手機拍攝ufo 定義 就乙個類而言，應該僅有乙個引起它變化的原因。通俗講就是我們不要讓乙個類承擔過多的職責。如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或...
設計模式的六大設計原則
1 單一指責原則 single responsibility principle，srp 每個類的功能單一，不能多功能 2 黎克特制替換原則 liskov substitution principle lsp，lsp 1.子類必須完全實現父類的方法 2.子類可以有自己的個性 3.覆蓋或實現父類的方法...