設計模式之工廠模式

該模式對物件建立管理方式最為簡單，因為其僅僅簡單的對不同類物件的建立進行了一層薄薄的封裝。該模式通過向工廠傳遞型別來指定要建立的物件，其uml類圖如下：

phone類：手機標準規範類(abstractproduct)

public inte***ce phone

public class miphone implements phone 

@override
public void make() 
}

public class iphone implements phone 

@override
public void make() 
}

public class phonefactory 

else if(phonetype.equalsignorecase("iphone")) 
return null;}}

public class demo 

}

也就是定義乙個抽象工廠，其定義了產品的生產介面，但不負責具體的產品，將生產任務交給不同的派生類工廠。這樣不用通過指定型別來建立物件了。

接下來繼續使用生產手機的例子來講解該模式。

其中和產品相關的phone類、miphone類和iphone類的定義不變。

abstractfactory類：生產不同產品的工廠的抽象類

public inte***ce abstractfactory

public class xiaomifactory implements abstractfactory

}

public phone makephone() }

演示：

public class demo 

}

最簡單的方式是把2中介紹的工廠方法模式完全複製乙份，不過這次生產的是pc。但同時也就意味著我們要完全複製和修改phone生產管理的所有**，顯然這是乙個笨辦法，並不利於擴充套件和維護。

抽象工廠模式通過在abstarctfactory中增加建立產品的介面，並在具體子工廠中實現新加產品的建立，當然前提是子工廠支援生產該產品。否則繼承的這個介面可以什麼也不幹。

其uml類圖如下：

pc類：定義pc產品的介面(abstractpc)

public inte***ce pc

public class mipc implements pc 

@override
public void make() 
}

public class mac implements pc 

@override
public void make() 
}

public inte***ce abstractfactory

public class xiaomifactory implements abstractfactory

@override
public pc makepc() 
}

public phone makephone()

@override

public pc makepc() }

演示：

public class demo 

}

此外無論哪種模式，由於可能封裝了大量物件和工廠建立，新加產品需要修改已定義好的工廠相關的類，因此對於產品和工廠的擴充套件不太友好，利弊需要權衡一下。

設計模式 設計模式之工廠模式

工廠方法模式 建立模式 使用場景？作用？形態？場景 大量類似的實體類 要建立的實體類都是同一本質的東西 披薩 有部分類似功能 準備 烘烤 切法 實現方式不一樣 準備的材料不同 烘烤時間不同 切法不同 將繁瑣複雜的建立類的過程聚集在一起，有序清晰 把具體例項化的過程從客戶 中抽離 作用 1 將建立物件...

c 設計模式 之 工廠模式之 工廠模式

1 uml類圖 實現和依賴關係 實現 sportfactory jeepfactory hatchbackfactory 實現 ifactory 介面 sportcar jeepcar hatchbackcar 實現 icar 介面 依賴 ifactory 依賴 icar sportfactory ...

設計模式 工廠模式之簡單工廠模式

定義 由乙個工廠物件 工廠類 來指定建立某乙個產品類的例項。使用場景 客戶端只需傳入指定的引數即可，工廠類負責建立的物件較少 因為指定了傳入的引數 介面類 本想用iphone命名的，見諒 public inte ce phone實現介面類 public class huaweiphone imple...