工廠模式是使用頻率很高的一種設計模式，在面試中也經常問到，今天我們就來學習它。 為什麼要用工廠模式？ 解答這個問題前，我們先來瞭解什麼是工廠模式。 工廠模式其實也稱創建模式，是用於創建對象的一種方式。本質上就是用工廠方法來代替new實例化對象。 舉個例子：我們在編寫代碼的時候，在一個A類中通過new ...
工廠模式是使用頻率很高的一種設計模式，在面試中也經常問到，今天我們就來學習它。
為什麼要用工廠模式？
解答這個問題前，我們先來瞭解什麼是工廠模式。
工廠模式其實也稱創建模式，是用於創建對象的一種方式。本質上就是用工廠方法來代替new實例化對象。
舉個例子：我們在編寫代碼的時候，在一個A類中通過new的方式實例化了類B，那麼A類和B類之間就存在耦合，如果以後修改了B類的代碼和使用方式，例如需要在構造函數中傳入參數，那麼A類也就需要跟著修改了，一個類的依賴可能影響不大，但若有多個類依賴了B類，那麼這個工作量將會相當的大，這無疑是件非常痛苦的事。這種情況下，我們需要把創建實例的工作單獨分離，與調用方解耦，也就是使用工廠方法創建實例的工作封裝起來。這樣我們在需要調用對象的時候就不需要關心那些複雜的實例化問題。
工廠模式
工廠模式可分為兩類：簡單工廠模式和工廠模式。
簡單工廠模式
定義一個介面和實現類，建立一個工廠類這些實現類進行實例的創建。
我們用球來舉例，定義一個基本的介面Ball，和一個抽象方法Play (玩)，
public interface Ball {
void play();
}創建一個籃球的類和一個足球的類，並實現該介面，
public class BasketBall implements Ball {
public void play() {
System.out.println("打籃球~~~");
}
}public class FootBall implements Ball {
public void play() {
System.out.println("踢足球~~~");
}
}然後，創建一個工廠類，可以用於生產籃球或者足球，
public class BallFactory {
public Ball produce(String type) {
if ("basketball".equals(type)) {
return new BasketBall();
} else if ("football".equals(type)) {
return new FootBall();
}
return null;
}
}工廠類建好以後，我們就可以實例化工廠類，並調用 produce 方法來創建對應的實例對象，
public static void main(String[] args) {
BallFactory factory = new BallFactory();
Ball ball = factory.produce("basketball");
ball.play();
}結果輸出：打籃球~~~
這就是簡單工廠模式的基本實現，用關係圖來表示就是：
這種模式的優點是代碼簡單，能夠根據具體的參數返回對應的實例對象。
當然缺點也很明顯，就是工廠類集中了所有實例的創建邏輯，如果增加業務就要多出相應的工廠方法，不僅代碼可能變得臃腫，也容易違反GRASPR的高內聚的責任分配原則
工廠模式
又稱多態性工廠模式，是對簡單工廠模式的改進。工廠模式中，一個子類對應一個工廠類，這些工廠類都實現了一個工廠介面。這相當於把一個簡單工廠類拆分成多個工廠，這樣代碼就不會都耦合在同一個類里了。
具體的產品介面和實現類還是復用上面的代碼，我們只需關註工廠方法的邏輯即可，
先創建一個工廠的介面
public interface IFactory {
void produce();
}然後創建對應業務的工廠類
public class BasketFactory implements IFactory {
public Ball produce() {
return new BasketBall();
}
}public class FootFactory implements IFactory {
public Ball produce() {
return new FootBall();
}
}測試代碼
public static void main(String[] args) {
BasketFactory basketFactory = new BasketFactory();
Ball basket = basketFactory.produce();
FootFactory footFactory = new FootFactory();
Ball foot = footFactory.produce();
basket.play();
foot.play();
}輸出結果是：
打籃球~~~
踢足球~~如上所示，如果需要添加新的產品，如排球，我們就多寫一個工廠類即可，這樣就不會把所有的業務都耦合到一個工廠類中了，用關係圖表示如下：
最後，總結一下工廠模式的優點吧，
1、良好的封裝性，代碼結構清晰，調用者只需知道產品的類名即可，不需要知道創建對象的過程，降低代碼間的耦合。
2、擴展性優秀，如果增加一個產品類，只需增加一個對應的工廠類。
3、屏蔽產品類。產品類的實現如何變化，調用者都不需要關心，只需關心產品的介面，只要介面保持不變，系統中的上層模塊就不會發生變化。
4、工廠模式是典型的解耦框架，高層模塊只需要知道產品的抽象類，其他的實現類都不需要關心，符合迪米特法則，符合依賴倒置原則，符合里氏替換原則。
參考：
《設計模式之禪》
