又重頭想了一下

還是以配電腦為例
最開始的時候，需要電腦，你得自己去生產電腦的每一個組件，例如你要cpu 就得自己生產cpu 要主板就得自己生產主板。
于是出現
簡單工廠模式
在簡單工廠模式中，定義一個返回接口，然后所有的組件實例都從這個工廠中產生
例:

工廠---------生產硬件
硬件----------
cpu------硬件的子類
主板------硬件的子類

當我需要某種組件的時候，直接告訴工廠，我需要的硬件名字，然后工廠就會生產一個我需要的硬件給我，這里，我不用去知道工廠中是怎么生產的，他可以自己生產，也可以找別的工廠代工，與我無關，我只需要找這個工廠要硬件就行了。

工廠類
public class Factory
{
public IHardware Produce(int type)
{
swicth(type)
{
case 0:
return new Cpu();
break;
case 1:
return new Motherboard();
break;
Default:
return null;
break;
}
}
}

硬件接口
public Interface IHardware
{
}

具體類CPU

public Cpu implements IHardware
{
}

具體類主板
public Motherboard implements IHardware
{
}
使用時，只需要一個工廠，然后找那個工廠生產實例就行了
Factory factory=new Factory();
IHardware cpu=factory.Produce(0);
IHardware motherboard=factory.Produce(1);
缺點 　　由于工廠類集中了所有實例的創建邏輯，違反了高內聚責任分配原則，將全部創建邏輯集中到了一個工廠類中；它所能創建的類只能是事先考慮到的，如果需要添加新的類，則就需要改變工廠類了。? 　　當系統中的具體產品類不斷增多時候，可能會出現要求工廠類根據不同條件創建不同實例的需求．這種對條件的判斷和對具體產品類型的判斷交錯在一起，很難避免模塊功能的蔓延，對系統的維護和擴展非常不利；? 　　這些缺點在工廠方法模式中得到了一定的克服。? 　　使用場景? 　　工廠類負責創建的對象比較少；? 　　客戶只知道傳入工廠類的參數，對于如何創建對象（邏輯）不關心；? 　　由于簡單工廠很容易違反高內聚責任分配原則，因此一般只在很簡單的情況下應用。

?

工廠方法模式應該和抽象工廠模式說的是同一個東東

那就還是用配電腦來重新理解一下

例如，原本只有一種cpu，一種主板，后來出現了很多種cpu和主板，這時使用這個工廠就會很麻煩，因為每次有新的類型出來，我都得去修改這個工廠

于是就出現了抽象工廠模式

這個理解上還有點問題，在代碼中再考慮吧只需要知道它在哪里用到

工廠方法模式的應用

　　工廠方法經常用在以下兩種情況中:?

　　第一種情況是對于某個產品，調用者清楚地知道應該使用哪個具體工廠服務，實例化該具體工廠，生產出具體的產品來。Java Collection中的iterator() 方法即屬于這種情況。?

　　第二種情況，只是需要一種產品，而不想知道也不需要知道究竟是哪個工廠為生產的，即最終選用哪個具體工廠的決定權在生產者一方，它們根據當前系統的情況來實例化一個具體的工廠返回給使用者，而這個決策過程這對于使用者來說是透明的。

先這樣吧

轉載于:https://www.cnblogs.com/meieiem/archive/2012/01/31/2332611.html

總結

以上是生活随笔為你收集整理的关于工厂模式(三)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。