工廠方法模式是創建型模式，基本在學習設計模式的時候，他是比較早被介紹的。但是很多時候也發現，其實根本寫不到代碼中去，一個原因是使用了spring這種框架後，對象委託spring管理了，另一個原因是這個模式場景是比較特殊的。（本文不是介紹設計模式的，而是探討模式的適合場景的。）
工廠方法模式的優點
工廠方法模式是管理對象的創建，以及如果有對象改動的時候就可以改掉工廠的內容就可以，而不用改變每個客戶端調用的代碼。在面對對象創建變更的時候，工廠模式極高內聚了創建過程，修改的時候很方便，對面變化改動量比較小。
爲什麼使用的場景少
一般情況下，大家寫的都是比較簡單的javabean，完全直接new就可以，不會特別複雜到創建的時候設置一大堆屬性，所以一般寫代碼不會創建一個類就配一個工廠，這樣反而帶來了很大的麻煩。稍微麻煩一點的對象，默認優先選擇靜態工廠，effective java中推薦使用靜態工廠替換構造函數。這樣方便且滿足很大部分的變化。而且我們自己寫代碼的時候基本遇不到一個類原來是可以new多個的，突然需要變了，要變成單例的情況。所以在很多時候創建對象是比較簡單且變動的可能性不會特別大的，稍微想考慮變動這些，也考慮靜態工廠。工廠模式在這種情況下顯得不合適了。
工作中遇到適合的場景
場景
一個做圖的情況，分爲設計圖形的模塊和畫圖的過程，我的同事負責畫圖的框架，只要是符合接口的類給他的框架，就可以出結果。我負責去設計圖形的形狀和樣式。
場景分析
我同事這樣分割的好處就是達到了解耦的目的，設計圖和畫圖分割，畫圖的過程其實不需要知道圖形的樣子，只要給設計好的圖形傳遞過去即可。對於作圖的框架，他想解耦，就需要獲取設計好的對象，接收一個可以作圖的接口和工廠。如何組織這樣的接口就需要一個工廠去生產，每個人做的東西都是一個圖形模塊。每個人只要提供好自己圖形模塊的工廠就好。
模式適用特點
如上類圖，我特意把父類換成了接口，這樣更能展示工廠方法的特點，那就是首先得可以去抽象，你可以定義接口去規範一些類，而且調用的地方可以面向接口編程，如果是面向實現類，可能換成建造者模式更好一些。
就如我上面舉得例子，調用的地方是面向接口編寫的，多個人去實現接口，然後給對應的生產工廠。這樣會給開發帶來很多好處，起碼開發的並行力度更大了，但是工作量小的時候，這樣反而是把問題弄複雜了。所以工廠模式需要按照工作量來評估。
總結
工廠方法模式的場景更適合內部已經有一定的框架，爲了框架的擴展性，對象接口編程，這時候對象的構建就顯得比較重要了，爲了維護單一原則，原來的框架一般不會加入對象的構建的細節，所以要使用工廠去擔當這個責任，對以後非框架性的替換提供了很多方便，但是同時也需要參考工作量，畢竟工作量比較小，
加入一個框架，可能會延誤一定的工期。高質量編程視頻shangyepingtai.xin