前言

關(guān)于設(shè)計模式黔龟，是一個永遠說不完的也說不清的話題历等。畢竟在編程的世界里讨惩，沒有最好的設(shè)計模式，只有最合適的設(shè)計模式寒屯。甚至有些時候荐捻，程序或者問題不到一定的規(guī)模，嘗試所有的設(shè)計模式都是花架子寡夹。另外处面，在程序設(shè)計之初就談論設(shè)計模式有些為時過早，但在問題出現(xiàn)之后才想起來設(shè)計模式卻有為時已晚菩掏，畢竟后期代碼的重構(gòu)或者邏輯的優(yōu)化都不是一件輕輕松松就能完成的事情魂角。所以，在合適的地方在合適的時機使用合適的設(shè)計模式患蹂，恰好能體現(xiàn)出來一個開發(fā)者的優(yōu)秀程度或颊。
設(shè)計模式就像是武功的套路砸紊，每一個套路都有固定的招式。而每一個套路也不是萬能的囱挑，不同的套路解決不同的問題醉顽。初學武功的人，只能以模仿的方式一招一式的練習平挑，而大師級別的武術(shù)宗師心中卻不受這些套路的桎梏游添。長時間的習武，反反復復的練習通熄，早就把這些套路深深的印在了骨子里唆涝。必要的時候，就能不經(jīng)思考的下意識出招唇辨。同理廊酣，深刻理解并經(jīng)常應用設(shè)計模式的開發(fā)者，遇到問題的時候赏枚，可以熟練的篩選出來合適的設(shè)計模式亡驰。甚至有些時候，他們還可以把這些設(shè)計模式進行組合或者進行一些改造饿幅，來達到更好的效果凡辱，無招勝有招，心中無模式卻勝過有模式栗恩，這大概就是設(shè)計模式的最高境界透乾。

本篇文章要說的設(shè)計模式包括：簡單工廠模式、工廠模式磕秤、抽象工廠模式乳乌。之所以把他們放到一起講，因為這三個設(shè)計模式都屬于創(chuàng)建型模式亲澡，即這三個設(shè)計模式都是為了解決對象的創(chuàng)建而生钦扭。把這三個設(shè)計模式拿來一起講，可以更好的體現(xiàn)出來各自的優(yōu)缺點床绪。

（一）簡單工廠模式

簡單工廠模式又叫做靜態(tài)工廠方法客情，屬于創(chuàng)建型模式。前面已經(jīng)說過癞己，簡單工廠模式解決的是對象的創(chuàng)建問題膀斋，簡單工廠模式主要由三個角色構(gòu)成：工廠類、抽象產(chǎn)品類痹雅、具體產(chǎn)品類仰担。

1.1 簡單工廠模式定義

定義一個用于生產(chǎn)對象的類，封裝生產(chǎn)不同的產(chǎn)品實例的細節(jié)绩社，使創(chuàng)建對象的邏輯和客戶端分離摔蓝，客戶端只需向這個類發(fā)起請求即可獲得對應的產(chǎn)品實例赂苗，而無需關(guān)心對象的創(chuàng)建過程。
簡單工廠模式解決的問題：客戶端(此處的客戶端指的是程序中使用產(chǎn)品類的某個類)根據(jù)不同的業(yè)務場景創(chuàng)建不同的產(chǎn)品對象的問題贮尉，而無需關(guān)心產(chǎn)品的的創(chuàng)建細節(jié)拌滋。
使用了簡單工廠模式，客戶端不需要增加創(chuàng)建產(chǎn)品類的代碼猜谚，而創(chuàng)建產(chǎn)品類的代碼被轉(zhuǎn)移到了工廠類中败砂，客戶端通過調(diào)用工廠類的某個接口并且給這個接口傳入對應的參數(shù)，就可以獲得客戶端需要的產(chǎn)品類的對象魏铅。這樣的好處在于產(chǎn)品類的創(chuàng)建邏輯和客戶端實現(xiàn)類分離昌犹，客戶端不需要關(guān)心產(chǎn)品類的生產(chǎn)過程，只需要消費這個產(chǎn)品览芳。

1.2 簡單工廠模式UML類圖

簡單工廠模式

1.3 實例代碼

/// 簡單工廠類
enum ProductEnum {
    case ProductA
    case ProductB
}

class SampleFactory: NSObject {
    /// 注意這里是類方法斜姥，即靜態(tài)方法，這就是靜態(tài)工廠方法一名的由來
    public class func product(product : ProductEnum) -> AbstractProduct {
        switch product {
        case .ProductA:
            return ConcreteProductA()
        case .ProductB:
            return ConcreteProductB()
        }
    }
}

/// 抽象產(chǎn)品類:
class AbstractProduct: NSObject {
    func interface() {
        
    }
}

/// 具體產(chǎn)品類A
/// 繼承自抽象產(chǎn)品類路操，覆寫抽象產(chǎn)品類的相應接口
class ConcreteProductA: AbstractProduct {
    override func interface() {
        print("簡單工廠模式：調(diào)用產(chǎn)品A實例方法")
    }
}

/// 具體產(chǎn)品類B
/// 繼承自抽象產(chǎn)品類疾渴，覆寫抽象產(chǎn)品類的相應接口
class ConcreteProductB: AbstractProduct {
    override func interface() {
        print("簡單工廠模式：調(diào)用產(chǎn)品B實例方法")
    }
}

/// 客戶端調(diào)用：
let facotry: SampleFactory = SampleFactory()
let productA: AbstractProduct = facotry.product(product: .ProductA)
productA.interface()
        
let productB: AbstractProduct = Factory.product(.ProductB)
productB.interface()

1.4 優(yōu)點

封裝對象的創(chuàng)建過程千贯，使創(chuàng)建對象的邏輯和客戶端分離屯仗。 在簡單工廠模式中，工廠類是整個模式的核心搔谴。在不使用簡單工廠模式之前魁袜，如果我們要在客戶端根據(jù)不同的場景創(chuàng)建不同的產(chǎn)品對象，我們就必須要寫一些類似于if...else if...else...這樣的條件分支語句敦第。在使用了簡單工廠模式后峰弹，原本屬于客戶端的邏輯判斷代碼，全部被轉(zhuǎn)移到了工廠類內(nèi)部芜果。所以鞠呈，工廠類代理了客戶端的一部分邏輯判斷功能。而客戶端不再關(guān)心產(chǎn)品的具體創(chuàng)建細節(jié)右钾，客戶端只需要調(diào)用工廠類的指定接口蚁吝，給這個接口傳入不同的參數(shù)，工廠類就會根據(jù)客戶端選擇傳遞的參數(shù)動態(tài)實例化相關(guān)的類舀射，然后給客戶端返回一個實例化的對象窘茁。在這個模式中，工廠類負責“生產(chǎn)”對象脆烟，而客戶端負責“消費”對象山林。工廠類和客戶端明確了各自的職責和權(quán)利。

1.5 缺點

不符合開放-封閉原則邢羔。上面已經(jīng)說過驼抹，在簡單工廠模式中桑孩，把原本屬于客戶端的邏輯判斷代碼轉(zhuǎn)移到了工廠類中，所以當需要增加或者刪除某個產(chǎn)品類的時候框冀，都需去工廠類中進行修改洼怔。這違反了編程中的開放封閉原則，即對擴展開放左驾，對修改封閉镣隶。如果不明白：每增加一個產(chǎn)品類，都要去工廠類中增加對應的條件分支代碼诡右，這就是對修改開放了安岂，所以違背了開放封閉原則。

1.6 注意

一定要使用靜態(tài)方法創(chuàng)建產(chǎn)品實例帆吻。工廠類中創(chuàng)建并返回產(chǎn)品實例的方法是類方法域那，即靜態(tài)方法，這也是該模式的靜態(tài)工廠方法別名的由來猜煮。所以次员，不要把這個方法寫成對象方法。

1.7 使用場景

1.客戶端不需要關(guān)心或者不需要參與具體產(chǎn)品類的創(chuàng)建細節(jié)王带。
2.工廠類中創(chuàng)建的產(chǎn)品對象不是很多淑蔚。
3.因為工廠類違背了開放-封閉原則，所以在工廠類不需要頻繁改動愕撰、產(chǎn)品類不常變化的地方可以考慮使用該模式刹衫。

（二）工廠方法模式

工廠方法模式經(jīng)常被叫做工廠方法，和簡單工廠模式一樣搞挣，也是屬于創(chuàng)建型模式带迟。工廠方法模式由抽象工廠類、具體工廠類囱桨、抽象產(chǎn)品類仓犬、具體產(chǎn)品類4個類構(gòu)成。

2.1 工廠方法定義

定義一個用于創(chuàng)建對象的接口舍肠，讓子類決定實例化哪一個產(chǎn)品類搀继，工廠方法使一個類的實例化延遲到其子類。

2.2 工廠方法UML類圖

工廠方法模式

2.3 實例代碼

/// 抽象工廠類
// MARK:- 工廠類要實現(xiàn)的接口
protocol IFactory {
    // 工廠類實現(xiàn)該接口用于生產(chǎn)產(chǎn)品實例貌夕，抽象工廠類實現(xiàn)該接口律歼；具體工廠類重寫該接口，返回具體的產(chǎn)品實例
    func Manufacture() -> AbstractProduct;
}

// MARK:- 抽象工廠類
class AbstractFactory: NSObject,IFactory {
    func Manufacture() -> AbstractProduct {
        return AbstractProduct()
    }
}

/// 抽象產(chǎn)品類
//MARK: 產(chǎn)品類需要實現(xiàn)的接口啡专，抽象產(chǎn)品類實現(xiàn)該方法险毁，具體產(chǎn)品類覆寫該方法
protocol IProduct {
    func operation()
}

// 抽象產(chǎn)品類
class AbstractProduct: NSObject,IProduct {
    func operation() {
        print("工廠方法模式：調(diào)用了抽象產(chǎn)品實現(xiàn)的接口")
    }
}

/// 具體工廠類
class ConcreteFactoryA: AbstractFactory {
    override func Manufacture() -> AbstractProduct {
        return ConcreteProductA()
    }
}

class ConcreteFactoryB: AbstractFactory {
    override func Manufacture() -> AbstractProduct {
        return ConcreteProductB()
    }
}

/// 具體產(chǎn)品類
class ConcreteProductA: AbstractProduct {
    override func operation() {
        print("工廠方法模式：調(diào)用了產(chǎn)品A實現(xiàn)的接口")
    }
}

class ConcreteProductB: AbstractProduct {
    override func operation() {
        print("工廠方法模式：調(diào)用了產(chǎn)品B實現(xiàn)的接口")
    }
}

/// 客戶端調(diào)用
let factoryA : AbstractFactory = ConcreteFactoryA()
let productA : AbstractProduct = factoryA.Manufacture()
productA.operation()

let factoryB : AbstractFactory = ConcreteFactoryB()
let productB : AbstractProduct = factoryB.Manufacture()
productB.operation()

2.4 優(yōu)點

工廠方法模式克服了簡單工廠模式的缺點，即簡單工廠模式違背的開放封閉原則。簡單工廠模式的產(chǎn)品類和分支語句耦合畔况，每增加一個產(chǎn)品類鲸鹦，就要去工廠類中增加相應的分支語句。而工廠方法模式抽象出來一個接口跷跪，這個接口就是創(chuàng)建抽象產(chǎn)品的工廠方法馋嗜，這個接口由抽象工廠類實現(xiàn)，具體的工廠類進行覆寫以生產(chǎn)不同的具體產(chǎn)品吵瞻。以后我們再增加某個產(chǎn)品葛菇，只需要增加對應的具體工廠類和具體產(chǎn)品類。而無需修改原有的工廠類橡羞，這樣就不會違背開放封閉原則眯停。
工廠方法符合單一職責原則，即每一個具體的工廠類只負責生產(chǎn)一種具體的產(chǎn)品卿泽。

2.5 缺點

1. 添加新的產(chǎn)品類時莺债，還要添加對應的工廠類。這樣签夭，每增加一個產(chǎn)品類齐邦，都要創(chuàng)建兩個類，有多少個具體的產(chǎn)品類第租，就要有多少個具體的工廠類措拇。這就意味著，會有更多的類需要參與程序的編譯煌妈。
2. 一個具體的工廠類只能創(chuàng)建一類產(chǎn)品儡羔。
3. 為了達到程序的擴展性，工廠方法模式引入了抽象類璧诵，在客戶端代碼中均使用抽象類進行定義實例，增加了程序的抽象性和理解的難度仇冯。且在實現(xiàn)時可能需要用到DOM之宿、反射等技術(shù)，增加了系統(tǒng)的實現(xiàn)難度苛坚。
4. 雖然保證了工廠方法內(nèi)的對修改關(guān)閉比被，但對于使用工廠方法的類，如果要更換另外一種產(chǎn)品泼舱，仍然需要修改實例化的具體工廠類等缀；

2.6 工廠方法 vs 簡單工廠

1. 相比較簡單工廠模式，工廠方法沒有使用靜態(tài)方法創(chuàng)建產(chǎn)品娇昙，而是使用工廠的對象方法創(chuàng)建產(chǎn)品實例尺迂，即，客戶端先創(chuàng)建具體的工廠實例，然后再使用這個工廠實例創(chuàng)建對應的產(chǎn)品實例噪裕。
2. 工廠方法模式解決了簡單工廠模式違背開放封閉原則的問題蹲盘。
3. 客戶端實例化產(chǎn)品時，使用簡單工廠模式膳音，客戶端不需要關(guān)心產(chǎn)品實例的創(chuàng)建過程召衔。工廠方法模式把簡單工廠模式的邏輯又搬到了客戶端，使用工廠方法模式祭陷，客戶端選擇判斷的邏輯還是存在的苍凛，客戶端還是需要書寫額外的邏輯來決定實例化哪一個工廠類，繼而再讓工廠對象創(chuàng)建對應的產(chǎn)品對象兵志。

2.7 使用場景

1. 當一個類不知道它所需要的對象的類時毫深，在工廠方法模式中，客戶端不需要知道具體產(chǎn)品類的類名毒姨，只需要知道所對應的工廠即可哑蔫；
2. 當一個類希望通過其子類來指定創(chuàng)建對象時，在工廠方法模式中弧呐，對于抽象工廠類只需要提供一個創(chuàng)建產(chǎn)品的接口闸迷，而由其子類來確定具體要創(chuàng)建的對象，利用面向?qū)ο蟮亩鄳B(tài)性和里氏代換原則俘枫，在程序運行時腥沽，子類對象將覆蓋父類對象，從而使得系統(tǒng)更容易擴展鸠蚪。

（三）抽象工廠模式

和簡單工廠今阳、工廠方法一樣，抽象工廠模式也是一種創(chuàng)建型模式茅信。和簡單工廠工廠方法相比盾舌，抽象工廠更具有普遍性，更具有抽象性蘸鲸。和工廠方法一樣妖谴，抽象工廠模式也是又由抽象工廠類、具體工廠類酌摇、抽象產(chǎn)品類膝舅、具體產(chǎn)品類4個類構(gòu)成。

3.1 抽象工廠模式定義

為創(chuàng)建一系列相關(guān)或相互依賴的對象提供一個接口窑多，而且無需指定他們的具體的類仍稀。

3.2 抽象工廠模式UML類圖

抽象工廠模式

抽象工廠模式中有兩個比較難以理解的概念，分別是產(chǎn)品樹（或產(chǎn)品系列）和產(chǎn)品簇概念的埂息。在抽象工廠模式中技潘，有多少個抽象產(chǎn)品類遥巴，就有多少個產(chǎn)品樹，因為抽象產(chǎn)品類和其衍生的若干個具體產(chǎn)品類在形式上組成了一個樹狀結(jié)構(gòu)崭篡，所以稱之為產(chǎn)品樹挪哄。而不同的產(chǎn)品樹中相互關(guān)聯(lián)的產(chǎn)品組成了一個產(chǎn)品簇，一個具體的工廠類可以生產(chǎn)一個產(chǎn)品簇內(nèi)的所有類型的產(chǎn)品實例琉闪。上面的UML中的ConcreteProductA1和ConcreteProductA2組成了一個產(chǎn)品簇迹炼，這個產(chǎn)品簇內(nèi)的所有產(chǎn)品可以由ConcreteFacotory1來生產(chǎn)。同理颠毙，ConcreteProductA2和ConcreteProductB2組成了另一個產(chǎn)品簇斯入，這個產(chǎn)品簇內(nèi)的產(chǎn)品可以由ConcreteFactory2來生產(chǎn)。而抽象工廠模式是針對于產(chǎn)品簇這一概念的蛀蜜。因為每個具體工廠可以實例化多種產(chǎn)品實例刻两。這些產(chǎn)品實例實際上是有一定關(guān)聯(lián)的，或者說這些產(chǎn)品實例是有一定共同特點的滴某。以下用使用蘋果手機和諾基亞手機來舉例說明產(chǎn)品樹和產(chǎn)品簇的概念磅摹。

抽象工廠模式示例

上圖中，蘋果手機是一個產(chǎn)品系列（或稱產(chǎn)品樹）霎奢，諾基亞手機是另一個產(chǎn)品系列户誓。而蘋果手機和諾基亞手機系列下都有5英寸和6英寸的手機，那么5英寸的蘋果手機和5英寸的諾基亞手機就構(gòu)成了一個產(chǎn)品簇幕侠。這個產(chǎn)品簇的產(chǎn)品可以由5InchFactory這個工廠來生產(chǎn)帝美。

3.3 實例代碼

/// 抽象工廠類
protocol IFactory {
    func createProductA() -> AbstractProductA
    func createProductB() -> AbstractProductB
}

class AbstractFactory: NSObject, IFactory {
    func createProductA() -> AbstractProductA {
        return AbstractProductA()
    }
    
    func createProductB() -> AbstractProductB {
        return AbstractProductB()
    }
}

/// 抽象產(chǎn)品類A
protocol IProductA {
    func operationA()

}

class AbstractProductA: NSObject, IProductA {
    func operationA() {
        
    }
}

/// 抽象產(chǎn)品類B
protocol IProductB {
    func operationB()
}

class AbstractProductB: NSObject, IProductB {
    func operationB() {
        
    }
}

/// 具體工廠類1
class ConcreteFactory1: AbstractFactory {
    func createProductA() -> AbstractProductA {
        return ConcreteProductA1()
    }
    
    func createProductB() -> AbstractProductB {
        return ConcreteProductB1()
    }
}

/// 具體工廠類2
class ConcreteFactory2: AbstractFactory {
    func createProductA() -> AbstractProductA {
        return ConcreteProductA2()
    }
    
    func createProductB() -> AbstractProductB {
        return ConcreteProductB2()
    }
}

/// 具體產(chǎn)品類A1
class ConcreteProductA1: AbstractProductA {
    override func operationA() {
        print("調(diào)用了ConcreteProductA1的接口")

    }
}

/// 具體產(chǎn)品類A2
class ConcreteProductA2: AbstractProductA {
    func operationA() {
        print("調(diào)用了ConcreteProductA2的接口")
    }
}

/// 具體產(chǎn)品類B1
class ConcreteProductB1: AbstractProductB {
    override func operationB() {
        print("調(diào)用了ConcreteProductB1的接口")
    }
}

/// 具體產(chǎn)品類B2
class ConcreteProductB2: AbstractProductB {
    override func operationB() {
        print("調(diào)用了ConcreteProductB2的接口")
    }
}

/// 客戶端調(diào)用
        let factory1 = ConcreteFactory1()
        let productA1 = factory1.createProductA()
        let productB1 = factory1.createProductB()
        
        productA1.operationA()
        productB1.operationB()
        
        let factory2 = ConcreteFactory2()
        let productA2 = factory2.createProductA()
        let productB2 = factory2.createProductB()
        
        productA2.operationA()
        productB2.operationB()

3.4 抽象工廠 vs 工廠方法

工廠方法模式的定義是：定義一個用于創(chuàng)建對象的接口，讓子類決定實例化哪一個產(chǎn)品類晤硕，工廠方法使一個類的實例化延遲到其子類悼潭。抽象工廠的定義是：為創(chuàng)建一系列相關(guān)或相互依賴的對象提供一個接口，而且無需指定他們的具體的類舞箍。

從UML類圖中舰褪，不難看出，抽象工廠模式和工廠方法模式是非常相似的创译，只不過抽象工廠模式比工廠方法模式多了一些抽象類和具體的產(chǎn)品類抵知。這就是他們的區(qū)別所在。二者的區(qū)別在于：工廠方法的產(chǎn)品類單一软族，工廠方法有一個抽象工廠類和一個抽象產(chǎn)品類，有若干個具體工廠類和具體產(chǎn)品類残制，每一個具體的工廠類都對應一個具體產(chǎn)品類立砸。每種具體工廠類只能實例化一種具體產(chǎn)品類。所以具體的工廠類和具體的產(chǎn)品類的個數(shù)是相等的初茶。而抽象工廠模式是針對于解決多個系列的產(chǎn)品而誕生的颗祝。即在抽象工廠模式中，抽象產(chǎn)品不止有一種。如果我們把一種抽象產(chǎn)品比作成一個產(chǎn)品系列（或者比作一棵產(chǎn)品樹）螺戳，那么抽象工廠模式下會有多個系列（或多棵產(chǎn)品樹）搁宾。每個產(chǎn)品系列下又有包括多種不同類型的產(chǎn)品。以下是工廠方法模式和抽象工廠的比對：

3.5 優(yōu)點

1. 易于在不同的產(chǎn)品簇之間切換膏燃。要想切換不同的產(chǎn)品簇茂卦，只需要切換具體工廠。即初始化不同的具體工廠實例就可以達到不同產(chǎn)品類型的切換组哩。如下：

// 如果從產(chǎn)品1切換到產(chǎn)品2等龙，那么只需要把下面初始化factory1改為初始化factory2即可，其他地方無需改動伶贰。
// let factory1 = ConcreteFactory1()
let factory2 =ConcreteFactory2()
let productA = factory1.createProductA()
let productB = factory1.createProductB()
        

3.6 缺點

1. 擴充產(chǎn)品的繁瑣蛛砰。抽象工廠雖然看起來已經(jīng)很完美了，他可以應用于不同產(chǎn)品的切換幕袱，但是對于增加一個產(chǎn)品樹暴备，抽象工廠模式卻是比較麻煩的。比如我們現(xiàn)在需要增加一個產(chǎn)品樹C们豌，針對于上面只有兩個具體工廠類的情況涯捻，我們除了增加一個AbstractProductC類，還需要增加2個類：ConcreteProductC1和ConcreteProductC2望迎，分別對應于ConcreteFactory1和ConcreteFactory2障癌。除此之外，我們還要在AbstractFactory類中增加一個createProductC()接口辩尊、還要在ConcreteFactory1和ConcreteFactory2中實現(xiàn)這個新增的接口涛浙。
   不難發(fā)現(xiàn)，當我們?yōu)槌橄蠊S模式增加一個產(chǎn)品樹的時候摄欲，除了增加對應的產(chǎn)品類之外轿亮，還要對所有的工廠類（抽象工廠類和所有的具體工廠類）進行擴張，這種修改顯然是麻煩且繁瑣的胸墙。

抽象工廠模式中我注，側(cè)重的是工廠類也就是產(chǎn)品簇，而非產(chǎn)品類迟隅。

3.7 使用場景

1. 適用于程序中不同配置的切換但骨。比如數(shù)據(jù)庫的切換励七、屏幕主題的切換、夜間模式的切換等等奔缠。
2. 不適用于擴展新的產(chǎn)品類掠抬。

（四）總結(jié)

1. 簡單工廠和工廠方法模式側(cè)重的是產(chǎn)品類，工廠類是為了產(chǎn)品類而生的校哎。對于抽象工廠模式特占，側(cè)重的是工廠類蚯嫌，一個工廠類可以創(chuàng)建一個產(chǎn)品簇中的產(chǎn)品泞歉。
2. 簡單工廠對于增加新的產(chǎn)品是比較麻煩的锰提，需要修改的地方比較多，工廠方法可以任意輕松地擴展新的產(chǎn)品類阳准。
3. 簡單工廠模式適用于相對簡單的情況和產(chǎn)品類不經(jīng)常增減的地方氛堕。工廠方法模式是對簡單工廠的改進，更加符合開放-封閉原則野蝇。抽象工廠模式是對工廠方法模式的進一步抽象讼稚，用來生產(chǎn)不同產(chǎn)品簇的全部產(chǎn)品，適用于不同產(chǎn)品切換的情景绕沈。和簡單工廠一樣锐想，抽象工廠對產(chǎn)品的擴展支持的不好。

參考文章

抽象工廠模式-與-工廠方法模式區(qū)別
《大話設(shè)計模式》

文／VV木公子（簡書作者）
PS:如非特別說明乍狐，所有文章均為原創(chuàng)作品赠摇，著作權(quán)歸作者所有，轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)浅蚪，并注明出處藕帜。

如果有技術(shù)問題，歡迎加入QQ群進行交流惜傲，群聊號碼：194236752洽故。