今天的Factory Method和上一篇Singleton同樣都屬於Creational Pattern，常運用於一定規模以上的程式中，現在就來認識它吧！

問題情境與解析

　　想像一下，一開始的應用程式只可以接受現金支付，但隨著科技的進步，大眾的消費方式也逐漸多元化，這時只能接受現金支付的應用程式為了跟上消費者的需求，就必須整合其他支付方式到應用程式中。

　　但是大多數的程式都與「現金」這個類別耦合，如果要新增其他類別，就必須得完整改過有關支付功能程式，才能夠整合完另一種之支付方式，維護成本相當高。 倘若日後又要新增其他類別，到最後程式碼看起來肯定非常混亂且許多地方重複。

　　使用工廠方法的話，會將「支付方式」作為一個工廠類別，而「支付的東西」作為產品的介面，不同的支付方式就會由不同的「支付工廠」（像是現金支付、LINE PAY、APPLE PAY等）去創建對應的「支付的東西」（像是現金、LINE PAY的QRcode、APPLE PAY感應等）。

Class Diagram

Skeleton Code

interface Product {
    void doSomething();
}

class ProductA implements Product {
    public void doSomething() {
        // work
    }
}

class ProductB implements Product {
    public void doSomething() {
        // work
    }
}

abstract class Factory {
    abstract Product cteateProduct();
}

class FactoryA extends Factory {
    public Product cteateProduct() {
        return new ProductA();
    }
}

class FactoryB extends Factory {
    public Product cteateProduct() {
        return new ProductB();
    }
}  

　　如果希望程式可以方便擴展內部組件的方法的話，使用工廠方法就可以滿足此需求，也可以避免重複的程式碼在應用程式運作中工作，以節省系統的資源。

除此之外，也歡迎大家走走逛逛關於我們團隊夥伴的文章

lu23770127 - SASS 基礎初學三十天

10u1 - 糟了！是世界奇觀！

juck30808 - Python - 數位行銷分析與 Youtube API 教學

SiQing47 - 前端？後端？你早晚都要全端的，何不從現在開始？