一直以來想要整理一下設計模式的心得，總有這樣那樣的事情耽誤，現在抽點寫一下吧。其實跨度這麼長時間，自己的理解也變化了不少。當然純屬個人的理解，有不對的地方還是多包涵。
簡單工廠模式應該是每一個學習設計模式的第一站，爲什麼這麼說呢，這就要從這個模式的使用說起。簡單工廠模式不屬於23種設計模式之一，是工廠模式家族中最簡單實用的模式，沒有什麼特殊的處理，根據傳入的參數，產出一個對應的“產品”，但是，它卻是面向對象編程的一個很好的體現。在這個模式裏面，我們不再需要關心傳入傳出，只需要單純的維護工廠即可。
在我的感覺中，簡單工廠模式，就是將一條條複雜的高速通道給封裝到一個盒子裏面，用戶再也不用關心我要從哪個入口進入哪個出口出來，盒子上只留有一個門，憑“卡”進入，你的“卡”信息決定了爲你安排的線路，不需要再在入口和出口的位置糾結了，所有的糾結扔給工程師吧，只要你的盒子路線劃分好（即工廠類內部邏輯清晰），過來的車（傳入的請求），自然而然的會到達預定的目的地（返回正確的結果）。而當路線滿足不了需求的時候（程序的需求變更），你只需要修改盒子內部結構（修改工廠類內部邏輯），以及告訴打卡機（增加一個判斷條件）即可。
如果這麼說不是很好理解，我們用下面的一個小例子來說明：計算器的設計，按照我們以往的思路，計算器肯定有一個類，然後裏面有加減乘除的方法和傳入的值，使用的時候我們只需要實例化出這個類，然後就可以使用裏面的方法，在沒有需求變更的時候，這樣其實也是挺方便的。但是某一天，我們的計算器需要升級了，添加A方法B方法...，這時候你也可以時候我們可以直接修改計算器這個類，但是這時候你沒有發現，其實你的業務和邏輯已經混在一起了，我們已經失去了計算器（因爲“計算器”！=“會各種算法的機器”），同時當你把過多的邏輯和業務混淆在一起後，你的邏輯算法也將失去價值，它再也不能爲你提供更多的幫助，你也將會陷入一個不斷複製修改的過程，而這個過程還可以會引發更恐怖的事情，你可能會在某次修改的時候漏過某些方法，這可是一個災難。
反過來說，我們的簡單工廠要做的正是避免這種情況，我們在生產計算器的時候會讓它繼承一個運算類，這個是幹嘛用呢？這個是告訴大家，計算器是計算器，它本身沒有任何功能，之所有有了那些功能，是因爲它裏面安裝了這種可以運算的功能，而這個運算類就是我們核心的運算規則，在生產一些高級的計算器的時候，它可能會有各種各樣其他的運算功能，這個不要緊我們只需要在原本的運算類基礎上向下派生子類，同時實現一些高級的接口即可，這樣，我們的業務就算是與邏輯脫離開來，對於邏輯的維護不會影響到業務的處理，同時對於業務的修改也不會造成邏輯的混亂。
同時，工廠的使用會大大的提高程序的複用，儘量的避免了程序的複製，也就儘可能的避免了升級過程中漏掉一些方法的修改。
最後說一下，編程時一門技術，更是一門藝術。
