先是大概看了下，介紹工廠模式的篇幅有些略長啊，有些不太愿意看了。
在書中先是介紹了“簡單工廠”，就是利用一個方法生成實例對象，在別的語言中通常用靜態實現，在OC中往往是利用+標識的類方法實現，簡單的理解就是避免用new生成實例的方法。直接用類方法進行生成新當前類實例的方法被書中介紹成“簡單工廠方法”。
根據書中的定義：
通過讓子類決定該創建的對象是什么，來達到將對象創建的過程封裝的目的--------工廠方法模式
如果按照該定義作為正確評判工廠方法模式的正確準則的話，我們用+標識的方法，僅僅是類方法，并非是某一種設計模式，并且書中介紹簡單工廠模式僅僅是大家約定俗成的一種書寫習慣，談不上是什么模式。
但是核心思想都是我們調用直接調用一個方法去生成實例，相比我們直接使用new 進行實例化有什么好處呢？
好處就是 我們可以更改這個方法的具體實現，并且不會更改原有調用方的代碼邏輯，這也體現了封閉的原則，我們可以在該方法中實例化出對應的子類，也就是調用方從來不關心具體是哪個實例，只要我能調用出對應的方法就好。利用多態，做到更改函數的具體實現，而這樣做的一切，都不會影響調用方--------即調用方可以不更改任何代碼，僅僅更改工廠函數(瞎起的名，懂這個意思就好)具體生成子類的策略，就能實現處理不同場景的功能，這樣的一切更改對于調用方 都是無感知的。
OO的封裝、繼承、多態思想還需要加強，多態的影子中在設計模式中太常見了。
值得注意的是，在我當初學這個模式的時候有些想不通的是，直接在我們直接在調用類的等號左邊直接用父類，等號右邊直接實例化子類不也是達到了同樣的效果么？調用方的代碼就也就改了一處，后來發現這種想法是略傻逼的。在代碼實現上判斷耦合程度最簡單的方式就是看#import引入的類是否多，如果引入過多的類則證明改類會和很多類都有聯系，即和很多類存在耦合，如果按照剛才方式，做了一件事不僅引入了父類也引入了子類，相比別人做一件事只引入一個類是不是辦的優點傻逼呢？
所以具體的實例化過程還是都放在工廠方法中實現比較穩妥，這樣調用方僅僅引入父類即可，而且一行代碼都不用更改！
盡量以后設計的時候，盡量多考慮依賴接口，而不是依賴實現編程，這是為了以后即使需要變動，盡量保證變動較少的原則。這些目前看都是簡單工廠所做的，工廠模式 目前還沒真理解，只是有點模糊的理解，屬于半吊子階段中。
一個正式的工廠方法模式的介紹：
定義一個創建對象的接口，但由子類決定要實例化的類是哪一個，工廠方法讓類吧實例化推遲到子類。
就是用方法封裝了實例化的過程，調用方都會當作父類去使用，而實際實例了哪個類都是由工廠函數決定了。
