又重頭想了一下

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

工廠---------生產(chǎn)硬件
硬件----------
cpu------硬件的子類
主板------硬件的子類

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

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

?

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

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

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

于是就出現(xiàn)了抽象工廠模式

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

工廠方法模式的應用

　　工廠方法經(jīng)常用在以下兩種情況中:?

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

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

先這樣吧

轉(zhuǎn)載于:https://www.cnblogs.com/meieiem/archive/2012/01/31/2332611.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。