一個菜鳥的設計模式之旅，文章可能會有不對的地方，懇請大佬指出錯誤，

編程旅途是漫長遙遠的，在不同時刻有不同的感悟，本文會一直更新下去，

程式介紹

由于 Go 中缺少類和繼承等 OOP 特性，所以無法使用 Go 來實作經典的工廠方法模式，不過，我們仍然能實作模式的基礎版本，即簡單工廠，案例中使用工廠結構體來構建多種型別的武器，因此工廠方法模式代碼使用 C# 表示，

Gun: AK47 gun
Power: 4
Gun: Musket gun
Power: 1

程式代碼、簡單工廠模式 Golang

首先，創建一個名為 i-Gun的介面，其中將定義一支槍所需具備的所有方法，然后是實作了 iGun 介面的 gun槍支結構體型別，兩種具體的槍支——ak47與 mus-ket火槍 ——兩者都嵌入了槍支結構體，且間接實作了所有的 i-Gun方法，

gun-Fac-to-ry槍支工廠結構體將發揮工廠的作用，即通過傳入引數構建所需型別的槍支， main.go 則扮演著客戶端的角色，其不會直接與 ak47或 mus-ket進行互動，而是依靠 gun-Fac-to-ry來創建多種槍支的實體，僅使用字符引數來控制生產，

iGun.go: 產品介面

package main

type IGun interface {
    setName(name string)
    setPower(power int)
    getName() string
    getPower() int
}

gun.go: 具體產品

package main

type Gun struct {
    name  string
    power int
}

func (g *Gun) setName(name string) {
    g.name = name
}

func (g *Gun) getName() string {
    return g.name
}

func (g *Gun) setPower(power int) {
    g.power = power
}

func (g *Gun) getPower() int {
    return g.power
}

ak47.go: 具體產品

package main

type Ak47 struct {
    Gun
}

func newAk47() IGun {
    return &Ak47{
        Gun: Gun{
            name:  "AK47 gun",
            power: 4,
        },
    }
}

musket.go: 具體產品

package main

type musket struct {
    Gun
}

func newMusket() IGun {
    return &musket{
        Gun: Gun{
            name:  "Musket gun",
            power: 1,
        },
    }
}

gunFactory.go: 工廠

package main

import "fmt"

func getGun(gunType string) (IGun, error) {
    if gunType == "ak47" {
        return newAk47(), nil
    }
    if gunType == "musket" {
        return newMusket(), nil
    }
    return nil, fmt.Errorf("Wrong gun type passed")
}

main.go: 客戶端代碼

package main

import "fmt"

func main() {
    ak47, _ := getGun("ak47")
    musket, _ := getGun("musket")

    printDetails(ak47)
    printDetails(musket)
}

func printDetails(g IGun) {
    fmt.Printf("Gun: %s", g.getName())
    fmt.Println()
    fmt.Printf("Power: %d", g.getPower())
    fmt.Println()
}

Console: 輸出

Gun: AK47 gun
Power: 4
Gun: Musket gun
Power: 1

程式代碼、工廠方法模式 C#

程式功能和簡單工廠相同，用工廠方法模式實作，

Gun.cs: 武器類

namespace 工廠方法;

public abstract class Gun
{
    protected Gun(string name, int power)
    {
        Name = name;
        Power = power;
    }

    public string Name { get; private set; }

    public int Power { get; private set; }

    public void setName(string name)
    {
        Name = name;
    }

    public void setPower(int power)
    {
        Power = power;
    }
}

public class AK47 : Gun
{
    public AK47() : base("ak47", 10)
    {
    }
}

public class Musket : Gun
{
    public Musket() : base("musket", 5)
    {
    }
}

Factory.cs: 工廠類

namespace 工廠方法;

public interface GunFactory
{
    Gun createGun();
}

public class AK47Factory : GunFactory
{
    public Gun createGun()
    {
        Console.WriteLine("正在生產AK47");
        return new AK47();
    }
}

public class MusketFactory : GunFactory
{
    public Gun createGun()
    {
        Console.WriteLine("正在生產Musket");
        return new Musket();
    }
}

Program.cs: 客戶端代碼

using 工廠方法;

GunFactory gunFactory = new AK47Factory();

Gun ak47_1 = gunFactory.createGun();
Gun ak47_2 = gunFactory.createGun();

gunFactory = new MusketFactory();

Gun Musket_1 = gunFactory.createGun();

List<Gun> guns = new List<Gun>() { ak47_1, ak47_2, Musket_1 };

foreach (Gun gun in guns)
{
    Console.WriteLine($"武器名字：{gun.Name}");
    Console.WriteLine($"武器傷害：{gun.Power}");
}

Console: 輸出

正在生產AK47
正在生產AK47
正在生產Musket
武器名字：ak47
武器傷害：10
武器名字：ak47
武器傷害：10
武器名字：musket
武器傷害：5

思考總結

什么是簡單工廠模式

簡單工廠模式也是工廠模式的一種，但不屬于23種設計模式，

目的使客戶端與產品解耦，將產品創建實體程序從客戶端代碼中獨立出去，生成具體物件的邏輯判斷也從客戶端分離至簡單工廠類中，

簡單工廠模式的最大優點在于工廠類中包含了必要的邏輯判斷，根據客戶端的選擇條件動態實體化相關的類，對于客戶端來說，去除了與具體產品的依賴，

但簡單工廠違背了開放-封閉原則，導致每次添加新類別的時候，都需要去修改工廠類的分支case判斷，可以用反射動態生成實體解決，

簡單工廠反射案例：我的設計模式之旅、01 策略模式、簡單工廠、反射 - 小能日記

什么是工廠方法模式

工廠方法是一種創建型設計模式，其在父類中提供一個創建物件的方法，允許子類決定實體化物件的型別，

工廠方法模式：定義一個用于創建物件的介面，讓子類決定實體化哪一個類，工廠方法使一個類的實體化延遲到子類，

工廠方法類（創建者類）：主要職責并非是創建產品，其中通常會包含一些核心業務邏輯，這些邏輯依賴于由工廠方法回傳的產品物件，子類可通過重寫工廠方法并使其回傳不同型別的產品來間接修改業務邏輯，

主要解決：主要解決介面選擇的問題，客戶端將所有產品視為抽象的介面，客戶端知道所有產品都提供該介面要求的方法，并不關心其具體實作方式，

何時使用：

我們明確地計劃不同條件下創建不同實體時，
當你在撰寫代碼的程序中，如果無法預知物件確切類別及其依賴關系時，可使用工廠方法，
希望用戶能擴展你軟體庫或框架的內部組件，可使用工廠方法，
希望復用現有物件來節省系統資源，而不是每次都重新創建物件，可使用工廠方法，在處理大型資源密集型物件（資料庫連接、檔案系統和網路資源）時，你會經常碰到這種資源需求，
在許多設計作業的初期都會使用工廠方法（較為簡單，而且可以更方便地通過子類進行定制），隨后演化為使用抽象工廠、原型或生成器（更靈活但更加復雜），

如何解決：讓其子類實作工廠介面，回傳的也是一個抽象的產品，使用特殊的工廠方法代替對于物件建構式new的直接呼叫，

實作步驟：

讓所有產品遵循同一介面，改介面必須宣告對所有產品都有意義的方法，
在工廠方法類（創建類中）添加一個空的工廠方法，該方法的回傳型別必須遵循通用的產品介面，
找到對于產品建構式的所有參考，依次替換為對工廠方法的呼叫，并將創建產品的代碼移入工廠方法，（類似簡單工廠，此時switch分支是龐大的）
為每種產品撰寫創建者子類，在子類中重寫工廠方法，將基本方法的相關創建代碼移動到工廠方法中，子類過多時，可以給子類創建者傳入引數，判斷生成，
如果代碼經過上述移動后，基礎工廠方法中已經沒有任何代碼，你可以將其轉變為抽象類，如果基礎工廠方法中還有其他陳述句，你可以將其設定為該方法的默認行為，一般總是把創建者基類作為抽象類，

關鍵代碼：創建程序在其子類執行，

應用實體：

您需要一輛汽車，可以直接從工廠里面提貨，而不用去管這輛汽車是怎么做出來的，以及這個汽車里面的具體實作，
Hibernate 換資料庫只需換方言和驅動就可以，

優點：

一個呼叫者想創建一個物件，只要知道其名稱就可以了，
開閉原則，擴展性高，如果想增加一個產品，只要擴展一個工廠類就可以，
屏蔽產品的具體實作，呼叫者只關心產品的介面，避免創建者和具體產品之間的緊密耦合，
單一職責原則，你可以將產品創建代碼放在程式的單一位置，從而使得代碼更容易維護，

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

使用場景：

日志記錄器：記錄可能記錄到本地硬碟、系統事件、遠程服務器等，用戶可以選擇記錄日志到什么地方，
資料庫訪問，當用戶不知道最后系統采用哪一類資料庫，以及資料庫可能有變化時，
設計一個連接服務器的框架，需要三個協議，"POP3"、"IMAP"、"HTTP"，可以把這三個作為產品類，共同實作一個介面，

注意事項：

作為一種創建類模式，在任何需要生成復雜物件的地方，都可以使用工廠方法模式，有一點需要注意的地方就是復雜物件適合使用工廠模式，而簡單物件，特別是只需要通過 new 就可以完成創建的物件，無需使用工廠模式，如果使用工廠模式，就需要引入一個工廠類，會增加系統的復雜度，
創建物件的邏輯判斷依舊在客戶端中實作，

與其他模式的關系：

抽象工廠模式通常基于一組工廠方法，但你也可以使用原型模式來生成這些類的方法，
你可以同時使用工廠方法和迭代器來讓子類集合回傳不同型別的迭代器，并使得迭代器與集合相匹配，
工廠方法是模板方法的一種特殊形式，同時，工廠方法可以作為一個大型模板方法中的一個步驟，

思考物件復用的方法

首先，你需要創建存盤空間來存放所有已經創建的物件，
當他人請求一個物件時，程式將在物件池中搜索可用物件，
然后將其回傳給客戶端代碼，
如果沒有可用物件，程式則創建一個新物件（并將其添加到物件池中），

四個步驟的代碼必須位于同一處，確保重復代碼不會污染程式！

參考資料

《Go語言核心編程》李文塔
《Go語言高級編程》柴樹彬、曹春輝
《大話設計模式》程杰
《深入設計模式》亞歷山大·什韋茨
設計模式講解和代碼示例
菜鳥教程

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

標籤：設計模式

上一篇：我的設計模式之旅、00 前置知識

下一篇：設計模式之中介者模式

我的設計模式之旅、09 工廠方法、簡單工廠

程式介紹

程式代碼、簡單工廠模式 Golang

iGun.go: 產品介面

gun.go: 具體產品

ak47.go: 具體產品

musket.go: 具體產品

gunFactory.go: 工廠

main.go: 客戶端代碼

Console: 輸出

程式代碼、工廠方法模式 C#

Gun.cs: 武器類

Factory.cs: 工廠類

Program.cs: 客戶端代碼

Console: 輸出

思考總結

什么是簡單工廠模式

什么是工廠方法模式

思考物件復用的方法

參考資料