前言

每每談及到Java，就不免會想到一個悲傷的事實:你是否每天都在new物件，卻依然堅守在單身崗上屹立不倒，(所謂面向物件編程的"缺點"hhh)，這篇來學一下工廠模式，擺脫new物件的苦惱!

知識點

傳統工廠

抽象類和子類們
生產和使用放在一起了沒有分離開，使用時傳名字，然后來生產相應的產品

public class OrderPizza {

	// 構造器
	public OrderPizza() {
		Pizza pizza = null;
		String orderType; // 訂購披薩的型別
		
			orderType = getType();
			if (orderType.equals("greek")) {
				pizza = new GreekPizza();
				pizza.setName(" 希臘披薩 ");
			} else if (orderType.equals("cheese")) {
				pizza = new CheesePizza();
				pizza.setName(" 奶酪披薩 ");
			} else if (orderType.equals("pepper")) {
				pizza = new PepperPizza();
				pizza.setName("胡椒披薩");
			} else {
				break;
			}
			//輸出pizza 制作程序
			pizza.prepare();
			pizza.bake();
			pizza.cut();
			pizza.box();
			
	}

改進的思路分析分析

修改代碼可以接受，但是如果我們在其它的地方也有創建Pizza的代碼，就意味著，也需要修改，而創建Pizza的代碼，往往有多處，
思路：把創建Pizza物件封裝到一個工廠類中，這樣我們有新的Pizza種類時，只需要修改該工廠類就好，其它有創建到Pizza物件的代碼就不需要修改了.->簡單工廠模式

簡單工廠模式(傳產品名字然后if-else)

一個超級工廠，負責生產所有種類的產品

在傳統工廠的基礎上，通過將產品創建的程序封裝成一個工廠類，實作生產和使用分離開

介面類/抽象類

package com.melo.design.工廠模式.簡單工廠模式;

public interface Shape {

    void draw();
}

子類產品

package com.melo.design.工廠模式.簡單工廠模式;

public class Circle implements Shape{
    @Override
    public void draw() {
        System.out.println("Circle");
    }
}

工廠類

package com.melo.design.工廠模式.簡單工廠模式;

public class ShapeFactory {

    public static Shape getShape(String shape){
        if("Circle".equals(shape)){
            return new Circle();
        }else if("Triangle".equals(shape)){
            return new Triangle();
        }
        return null;
    }
}

呼叫方

package com.melo.design.工廠模式.簡單工廠模式;

public class Main {

    public static void main(String[] args) {
        Shape circle = ShapeFactory.getShape("Circle");
        circle.draw();
    }
}

缺點

總而言之，簡單工廠模式就是讓一個工廠類承擔構建所有物件的職責，呼叫者需要什么產品，讓工廠生產出來即可，它的弊端也顯而易見：

一是如果需要生產的產品過多，此模式會導致工廠類過于龐大，承擔過多的職責，變成超級類，當蘋果生產程序需要修改時，要來修改此工廠，梨子生產程序需要修改時，也要來修改此工廠，也就是說這個類不止一個引起修改的原因，違背了單一職責原則，
二是當要生產新的產品時，必須在工廠類中添加新的分支，而開閉原則告訴我們：類應該對修改封閉，我們希望在添加新功能時，只需增加新的類，而不是修改既有的類，所以這就違背了開閉原則，

工廠方法模式

在工廠方法模式中，我們不再提供一個統一的工廠類來創建所有的物件，而是針對不同的物件提供不同的工廠，也就是說每個物件都有一個與之對應的工廠，
工廠方法讓類的實體化推遲到子類中進行!!!

原本簡單工廠是一個工廠，負責生產所有的產品，現在要改成每個物件對應一個工廠，一個工廠只負責生產一個產品

優點

這樣我們就解決了上文所述的單一職責問題，每個工廠只負責生產一個產品
同時也解決了開閉原則，每次需要新增一個產品的時候，我們只需要新增一個工廠類就好，而不需要去修改原來的工廠類

缺點

每次增加一個產品時，都需要增加一個具體類和物件實作工廠，使得系統中類的個數成倍增加，在一定程度上增加了系統的復雜度，同時也增加了系統具體類的依賴，這并不是什么好事，

每個產品對應一個工廠類，然后同一類的產品，比如都是水果類，則再抽象一個水果工廠出來，具體的工廠類去實作他的create方法

MyDemo

水果介面

package com.melo.mydesign.Factory.FactoryMethod.Product;

//產品只關心使用,不關心創建
public interface Fruit {
    void eat();
}

水果具體子類

package com.melo.mydesign.Factory.FactoryMethod.Product;

public class Apple implements Fruit {
    @Override
    public void eat() {
        System.out.println("吃蘋果");
    }
}

package com.melo.mydesign.Factory.FactoryMethod.Product;

public class Pear implements Fruit {

    @Override
    public void eat() {
        System.out.println("吃梨子");
    }
}

水果工廠介面

package com.melo.mydesign.Factory.FactoryMethod.Factory;

import com.melo.mydesign.Factory.FactoryMethod.Product.Fruit;

public interface FruitFactory {
    Fruit createFruit();
}

具體水果工廠實作子類

package com.melo.mydesign.Factory.FactoryMethod.Factory;

import com.melo.mydesign.Factory.FactoryMethod.Product.Apple;
import com.melo.mydesign.Factory.FactoryMethod.Product.Fruit;

public class AppleFactory implements FruitFactory {
    @Override
    public Fruit createFruit() {
        return new Apple();
    }
}

package com.melo.mydesign.Factory.FactoryMethod.Factory;

import com.melo.mydesign.Factory.FactoryMethod.Product.Fruit;
import com.melo.mydesign.Factory.FactoryMethod.Product.Pear;

public class PearFactory implements FruitFactory {
    @Override
    public Fruit createFruit() {
        return new Pear();
    }
}

具體使用

package com.melo.mydesign.Factory.FactoryMethod;

import com.melo.mydesign.Factory.FactoryMethod.Factory.AppleFactory;
import com.melo.mydesign.Factory.FactoryMethod.Factory.FruitFactory;
import com.melo.mydesign.Factory.FactoryMethod.Product.Fruit;

public class Consumer {

    public static void main(String[] args) {
        //使用者不需要知道是哪個類在生產,面對的都是 FruitFactory 這個介面
        FruitFactory appleFactory = new AppleFactory();
        Fruit apple = appleFactory.createFruit();
        apple.eat();
    }

}

抽象工廠模式

工廠方法模式，隨著產品越來越多，會產生越來越多的產品類和產品工廠，能不能把一類產品，抽離出來變成一個產品家族呢?

這意味著不再是每一個產品就對應一個產品工廠了
而是一類產品，對應一個產品類工廠

以菜鳥的為例子(感覺比較權威一點)

UML

首先從使用者的角度，要生產一個產品，一開始肯定是先找到那個產品所在的產品類工廠

如何找到產品類工廠?相當于產品類工廠也需要有人來創造他，又是處理多個產品的工廠類，我們叫他FactoryProducer

然后拿到具體的產品類工廠了，就要生產具體的產品，處理方式同上(if-else)
- 剩下的就是產品和父類產品了，具體實作代碼見下方

可以看到Shape工廠要負責多個Shape了，就回歸到簡單工廠，一個工廠處理多個產品(需要傳字串名字然后if-else)

抽象工廠和具體產品類工廠(注意需要把工廠類的方法都定義出來)

具體實作看子類

可以看到Shape產品類工廠，也得實作Color的方法，只不過return null罷了

同時，FactoryProducer也得處理多個，既要處理Shape也要處理Color

具體使用

MyDemo

抽象產品類工廠

package com.melo.mydesign.Factory.AbstractFactory.Factory;

import com.melo.mydesign.Factory.AbstractFactory.Product.Car.Car;
import com.melo.mydesign.Factory.AbstractFactory.Product.Fruit.Fruit;

public interface AbstractFactory {
    Fruit createFruit(String fruitName);

    Car createCar(String carName);
}

具體產品類工廠--Car

package com.melo.mydesign.Factory.AbstractFactory.Factory;

import com.melo.mydesign.Factory.AbstractFactory.Product.Car.Audi;
import com.melo.mydesign.Factory.AbstractFactory.Product.Car.BMW;
import com.melo.mydesign.Factory.AbstractFactory.Product.Car.Car;
import com.melo.mydesign.Factory.AbstractFactory.Product.Fruit.Fruit;


public class CarFactory implements AbstractFactory{
    @Override
    public Fruit createFruit(String fruitName) {
        return null;
    }

    public Car createCar(String carName){
        if(carName.equalsIgnoreCase("BMW")){
            return new BMW();
        }else if(carName.equalsIgnoreCase("Audi")) {
            return new Audi();
        }
        return null;
    }
}

具體產品類工廠--Fruit

package com.melo.mydesign.Factory.AbstractFactory.Factory;

import com.melo.mydesign.Factory.AbstractFactory.Product.Car.Car;
import com.melo.mydesign.Factory.AbstractFactory.Product.Fruit.Pear;
import com.melo.mydesign.Factory.AbstractFactory.Product.Fruit.Apple;
import com.melo.mydesign.Factory.AbstractFactory.Product.Fruit.Fruit;

public class FruitFactory implements AbstractFactory {
    public Fruit createFruit(String fruitName){
        if(fruitName.equalsIgnoreCase("Apple")){
            return new Apple();
        }else if(fruitName.equalsIgnoreCase("Pear")) {
            return new Pear();
        }
        return null;
    }

    @Override
    public Car createCar(String carName) {
        return null;
    }
}

FactoryProducer--負責生產產品類工廠的物件

package com.melo.mydesign.Factory.AbstractFactory.Factory;

public class FactoryProducer {

    public static AbstractFactory produceFactory(String factoryName){
        if(factoryName.equalsIgnoreCase("Fruit")){
            return new FruitFactory();
        }else if (factoryName.equalsIgnoreCase("Car")){
            return new CarFactory();
        }
        return null;
    }
}

Car類產品介面

package com.melo.mydesign.Factory.AbstractFactory.Product.Car;

//產品只關心使用,不關心創建
public interface Car {
    void eat();
}

Car類產品實作類

package com.melo.mydesign.Factory.AbstractFactory.Product.Car;

public class BMW implements Car {
    @Override
    public void eat() {
        System.out.println("寶馬");
    }
}

Fruit類產品

package com.melo.mydesign.Factory.AbstractFactory.Product.Fruit;

//產品只關心使用,不關心創建
public interface Fruit {
    void eat();
}

Fruit類實作類

package com.melo.mydesign.Factory.AbstractFactory.Product.Fruit;


import com.melo.mydesign.Factory.AbstractFactory.Product.Fruit.Fruit;

public class Pear implements Fruit {

    @Override
    public void eat() {
        System.out.println("吃梨子");
    }
}

消費者

package com.melo.mydesign.Factory.AbstractFactory;

import com.melo.mydesign.Factory.AbstractFactory.Factory.AbstractFactory;
import com.melo.mydesign.Factory.AbstractFactory.Factory.FactoryProducer;
import com.melo.mydesign.Factory.AbstractFactory.Product.Car.Car;

public class Consumer {
    public static void main(String[] args) {
        AbstractFactory carFactory = FactoryProducer.produceFactory("Car");
        Car bmw = null;
        if (carFactory != null) {
            bmw = carFactory.createCar("BMW");
        }
        if (bmw != null) {
            bmw.eat();
        }
    }
}

缺點

不再符合開閉原則了，因為本質是由簡單工廠去升級而來的，又回歸到了一個產品類工廠，需要處理多個產品的問題，**就需要if-else了 **

總結

一個小小的工廠模式，就把前邊學到的幾大原則: 開閉原則，依賴倒轉原則(善用抽象介面而不是具體實作) 體現得淋漓盡致.
- 產品一旦多起來，就要抽離出一個抽象的產品類介面，讓子類去實作他，使用者只關心抽象，而不關心具體的實作，不需要知道具體的類名，想生成蘋果就直接 Fruit apple = new Apple(); 而不用 Apple apple = new Apple();
- 而如果生產的程序變得復雜起來，比如蘋果還需要各種處理，就需要將創建的程序封裝起來，不暴露給使用者，這時就需要用到專門的工廠類來進行包裝了，外界只需要從工廠里邊拿就好了，傳一個簡單的"蘋果"字串，這就演變到了簡單工廠模式了
再然后我們發現一個簡單工廠類，名曰簡單，但是卻要處理各種各樣的產品，每次新增一個產品，都得去修改if-else代碼塊，不符合開閉原則
- 由此引入了 工廠方法模式 讓每一個產品就去對應有一個產品工廠，專門的工廠來生產產品，一個工廠只負責一個產品的生成，滿足了單一職責原則，同時每次新增產品，只需要多加一個產品工廠就好了，無需修改原來的工廠，又解決了開閉原則的問題
然而，隨著產品數量越來越大，單純一個工廠負責一個產品的話，工廠的數量也許會越來越多，而且，這些產品之前可能存在某些聯系，比如都是水果類，那我們何不抽離出一個水果工廠，來生產各式各樣的水果呢

看到這里可能有細心的讀者就發現了，一個工廠又要去負責生產多個產品了，那似乎又回到了簡單工廠模式，不符合開閉原則和單一職責了，是的，抽象工廠模式其實就是簡單工廠的升級版而已!

作者：『Melo~』
出處：https://www.cnblogs.com/melojun/
本文著作權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文鏈接，否則保留追究法律責任的權利，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/335134.html

標籤：其他

上一篇：工廠模式--擺脫你日復一日new物件卻依舊單身的苦惱！

下一篇：競賽最好用的平衡樹-Size Balanced Tree（SBT）【建議收藏】