工廠模式的引入是為了管理物件的構造，對使用者遮蔽構造過程，使用者只從工廠拿取新物件。

簡單工廠模式

用一個場景介紹簡單工廠模式：某工廠想包攬所有產品生產，不僅提供很多不同型別的產品（iPhone 5,6,7...），還時不時生產新型別的產品（三星S8），而且客戶不關係產品的型別細節只想使用公共方法。工廠採用如下方式：

1. 根據客戶要求/訂單生產出不同產品
2. 所有產品都由本工廠（類）唯一生產線製造出售（靜態方法）
3. 每增刪一種新產品，就直接修改生產邏輯。

例項程式碼如下

abstract class Phone{
    public abstract void use();
}

class iPhone extends Phone{
    @Override
    public void use(){System.out.print("iPhone");}
}

class S8 extends  Phone{
    @Override
    public void use(){System.out.print("S8");}
}

class PhoneFactory{
    public static Phone Manufacture(String type){
        switch(type){
            case "iPhone":return new iPhone();
            case "S8":return new S8();
            ...
            default: return null;
        }
    }
}
 

這就是簡單工廠模式，這種策略有明顯缺點：

第2條靜態方法導致工廠類繼承無效

第3條對正常工作的方法進行入侵式修改違反了關閉開放原則，即有可能不慎影響到其他產品物件的的構造邏輯（比如誤刪字元）或者判斷物件型別的邏輯，導致出錯。而且這對負責生產物件的方法負擔過重，引起引數過於複雜等問題，不易於呼叫者使用。

工廠方法模式

既然一個工廠生產多種產品型別負擔過重，那就開分廠吧~，每一個工廠各司其職，客戶需要什麼產品就從什麼專用工廠取就好了。但是約定每個工廠生產出來的產品需要符合規範，故在這些分工廠之上加以繼承介面/抽象類的約束。避免了簡單工廠模式的缺點

abstract class Phone{
    public abstract void use();
}
class iPhone extends Phone{
    @Override
    public void use(){System.out.print("iPhone");}
}

class S8 extends  Phone{
    @Override
    public void use(){System.out.print("S8");}
}
abstract class PhoneFactory{
    public abstract Phone Manumfacture();
}

class iPhoneFactory extends PhoneFactory{
    @Override
    public Phone Manumfacture() {
        return new iPhone();
    }
}

class S8Factory extends PhoneFactory{
    @Override
    public Phone Manumfacture() {
        return new S8();
    }
}
 

不過工廠方法模式也有缺點：工廠類的數量多，帶來各種的複雜性