同為 設計模式的 可以理解為對new關鍵字的代替。 本著重覆三次即重構的原則，如果一個對象在不同的地方被new了兩次以上，那就可以考慮使用它。那我們為什麼要用簡單工廠模式代替new呢？就像我們使用Getter Setter代替直接讀寫欄位一樣，說白了就是加上一個間接層，以緩衝處理流程的變化(比如獲取 ...
同為創造型設計模式的簡單工廠模式可以理解為對new關鍵字的代替。
本著重覆三次即重構的原則，如果一個對象在不同的地方被new了兩次以上，那就可以考慮使用它。那我們為什麼要用簡單工廠模式代替new呢？就像我們使用Getter Setter代替直接讀寫欄位一樣，說白了就是加上一個間接層，以緩衝處理流程的變化(比如獲取欄位的時候，為其加上100再返回，寫在Getter里就不需要散彈式修改)。
相比起來工廠方法模式無疑複雜了很多。引用一句維基百科上對其用途的解釋:
Deal with the problem of creating objects without having to specify the exact class of the object that will be created
也就是說用在不想直接引用精確類型來創建對象的時候。等等，不引用精確類型那不就是多態嗎，那我們直接用
AInterface a;
//TODO: 對a依賴註入
a.work();
AInterface b;
//TODO: 對b進行不同精確類型的依賴註入
b.work();這樣的形式不就行了嗎？
如果這樣就能解決問題，當然可以這樣用，畢竟重構只在必要的時候去做。但是對a進行依賴註入的工作肯定不會自動完成，為瞭解決這個問題出現了一大批依賴註入框架。如果你不想用笨重的框架，那你就得自己去創建a的實例，然後理所當然的你就必須知道a的精確類型，畢竟你不能直接new一個介面，至少在java里是這樣。所以你有了這樣的代碼：
AInterface a;
a = new AInterfaceImpl();
a.work();
AInterface b;
b = new BInterfaceImpl();
b.work();事實上，噁心的工作不會消失不見，頂多可以把噁心的工作延遲完成，不然我們的程式不可能跑得動。在上面的需求里，你不能永遠忽視a的精確類型，就算用依賴註入框架也是一樣的，在程式的某個地方，你必須給它一個明確的類型。但是，程式員的美德是，複雜的工作，永遠要推遲到後面去實現，至少在上面的代碼里，我想要隱藏精確類型，比如像這樣：
Factory factory;
//TODO: 對factory依賴註入
//看，用起來很簡單對吧
AInterface a;
a = factory.getIt();
a.work();
//TODO: 對factory進行不同的依賴註入
//用多態的特性做不同的工作
AInterface b;
b = factory.getIt();
b.work();好吧，我們解決了一個問題，然後引入了另一個問題。現在我們必須關心Factory的精確類型了。我們不停地把垃圾扔給別人，以保持自己的乾凈。
對於不停傳遞垃圾這種行為我已經累了，不想寫了，但是工廠方法模式當然還沒有結束，有空再寫吧
