1. 簡(jiǎn)單工廠模式又稱靜態(tài)工廠方法模式。從命名上就可以看出這個(gè)模式一定很簡(jiǎn)單。它存在的目的很簡(jiǎn)單：定義一個(gè)用于創(chuàng)建對(duì)象的接口。
1.public class CarFactory{
public static Car getCar(int type){
if(type == 1){
return new Car1();
} else {
return new Car2();
}
}
}
2. public class CarFactory{
public static Car getCar(String carClass){
String className = carClass;
Class c = Class.forName(className);
Car car = (Car)c.newInstance();
return car;
}
}
3. public class CarFactory{
public static Car getCar(String carJNDIName){
InitialContext ic = new InitialContext();
String className = ic.lookUp(carJNDIName);
Car car = (Car)Class.forName(className).newInstance();
return car;
}
}
方式1～3適合于工廠所產(chǎn)生的對(duì)象都是屬于同一個(gè)父類型的，而從方式1～3來看，方式1無疑是最簡(jiǎn)單的，也是最容易理解和接受的，而方式2和方式3則相對(duì)來說要高級(jí)一點(diǎn)。高級(jí)在哪里呢？我們可以看到，方式1中對(duì)對(duì)象的創(chuàng)建是使用Hardcode的形式，也即是程序員需要事先知道系統(tǒng)里面存在多少個(gè)類型的對(duì)象及其對(duì)應(yīng)的編號(hào)，一旦增加或刪除、修改了對(duì)象的類型，則必然引起if-else塊的改變，造成了維護(hù)的困難。
而方式2則采用了動(dòng)態(tài)類加載的方式，方式3在方式2的基礎(chǔ)上使用了JNDI，更進(jìn)了一步，其好處是不用出現(xiàn)HardCode的方式，即便你后面的應(yīng)用增加、刪除了對(duì)象的類型，我的程序還是保持現(xiàn)在的樣子，跟進(jìn)一步來說：可以去掉那些討厭的if-else語句。
2. 工廠方法模式去掉了簡(jiǎn)單工廠模式中工廠方法的靜態(tài)屬性，使得它可以被子類繼承。這樣在簡(jiǎn)單工廠模式里集中在工廠方法上的壓力可以由工廠方法模式里不同的工廠子類來分擔(dān)。【實(shí)質(zhì)上它是讓工廠實(shí)現(xiàn)了抽象的工廠接口，它把具體怎么生產(chǎn)一種東西，放在具體的工廠去實(shí)現(xiàn)了，所謂”延遲到子類中實(shí)現(xiàn)“】
示例一：
public interface Driver{
public Car driverCar();
}
public class BenzDriver implements Driver{
public Car driverCar(){
return new Benz();
}
}
public class BmwDriver implements Driver{
public Car driverCar() {
return new Bmw();
}
}
// 應(yīng)該和具體產(chǎn)品形成對(duì)應(yīng)關(guān)系 ...
// 有請(qǐng)暴發(fā)戶先生
public class Magnate
{
public static void main(String[] args)
{
try{
Driver driver = new BenzDriver();
Car car = driver.driverCar();
car.drive();
}
……
}
示例二：
public interface Creator
{
public Prouct factory();
}
public SubCreator1 implent Creator
{
public Prouct factory()
{
return new ConcreteProduct1();
}
}
public SubCreator2 implent Creator
{
public Prouct factory()
{
return new ConcreteProduct2();
}
}
請(qǐng)注意：返回類型是Product型的??！
這樣客戶端調(diào)用是直接new 一個(gè)具體工廠的實(shí)例，然后命令它去生產(chǎn)，而對(duì)于具體工廠的父類（既工廠接口，接口完全可以改成子類繼承父類來實(shí)現(xiàn)，只是這樣不好，不符合OO的原則），它完全不知道什么產(chǎn)品被生產(chǎn)了，甚至它連那個(gè)具體工廠被實(shí)例化它都不知道！
3. 抽象工廠
public abstract class AbstractFactory{
public abstract Car getCar(String carClass);
public abstract Plane getPlane(String planeClass);
}
public class Factory1 extends AbstractFactory{
public Car getCar(String carClass){
// 參考上面的方式1～3
return car1;
}
public Plane getPlane(String planeClass){
// 參考上面的方式1～3
return plane1;
}
}
public class Factory2 extends AbstractFactory{
public Car getCar(String carClass){
// 參考上面的方式1～3
return car2;
}
public Plane getPlane(String planeClass){
// 參考上面的方式1～3
return plane2;
}
}
方式4是最為復(fù)雜而且也是最為強(qiáng)大的一種，它在實(shí)現(xiàn)了對(duì)象工廠抽象的基礎(chǔ)上，又集成了工廠方法。使到不同的工廠可以生產(chǎn)相同類型的產(chǎn)品，但產(chǎn)品的子類可能有所不同。就像上面的工廠1和工廠2都可以生產(chǎn)汽車和飛機(jī)一樣，他們各自之間可以生產(chǎn)不同系列的產(chǎn)品(抽象工廠)，而且每個(gè)系列下面可能有不同的型號(hào)(工廠方法)。
參考資料：
http://www.tkk7.com/pengpenglin/archive/2008/01/02/172325.html
http://www.tkk7.com/killme2008/archive/2007/03/15/104031.html
http://www.tkk7.com/alex/archive/2006/08/29/66479.html