Golang工厂模式最佳实践：简单工厂与抽象工厂对比

简单工厂适合单一维度的对象创建，抽象工厂用于多维度产品族的一致性构建。简单工厂根据参数决定实例类型，适用于种类少、结构固定的场景，如日志记录器的创建；抽象工厂则提供一组接口创建相关对象，确保产品族一致性，如跨平台UI控件的构建。两者区别在于适用对象数量、扩展性和一致性保证，选型应基于业务需求与扩展方向。

在 Golang 项目中，工厂模式是构建复杂对象时常用的设计模式之一。它通过封装对象的创建逻辑，提升代码的可维护性和扩展性。其中，简单工厂和抽象工厂是最常见的两种实现方式，但它们适用的场景有所不同。

简单工厂：适合单一维度的对象创建

简单工厂并不是 GoF 提出的标准设计模式，但在实际开发中非常常见。它通过一个工厂类根据传入的参数决定创建哪一种产品类的实例。

使用场景：

• 对象种类较少，且都在同一层级结构中
• 创建逻辑集中、不频繁变化
• 调用方只需要知道输入参数，不需要关心具体实现

举个例子，假设我们要根据不同类型创建日志记录器（Logger）：

type Logger interface {
    Log(msg string)
}

type ConsoleLogger struct{}
func (l ConsoleLogger) Log(msg string) {
    fmt.Println("Console:", msg)
}

type FileLogger struct{}
func (l FileLogger) Log(msg string) {
    // 写入文件逻辑
}

func NewLogger(logType string) Logger {
    switch logType {
    case "console":
        return ConsoleLogger{}
    case "file":
        return FileLogger{}
    default:
        panic("Unsupported logger type")
    }
}

这种方式简单直接，适用于小型系统或模块内部使用。

抽象工厂：应对多维度的产品族

当系统中存在多个产品族，并且这些产品之间需要保持一致性时，就需要使用抽象工厂模式。它提供了一组用于创建一系列相关或依赖对象的接口，而无需指定其具体类。

使用场景：

• 存在多个产品族，比如不同平台下的 UI 控件（WindowsButton + WindowsTextBox vs MacButton + MacTextBox）
• 需要确保一组相关对象一起使用，避免混用
• 希望隐藏产品族的实现细节，仅暴露接口

例如，在一个跨平台的应用中，我们可能需要创建不同的组件：

type Button interface {
    Click()
}

type TextBox interface {
    Input(text string)
}

// Windows 工厂
type WindowsFactory struct{}

func (f WindowsFactory) CreateButton() Button {
    return WindowsButton{}
}

func (f WindowsFactory) CreateTextBox() TextBox {
    return WindowsTextBox{}
}

// Mac 工厂
type MacFactory struct{}

func (f MacFactory) CreateButton() Button {
    return MacButton{}
}

func (f MacFactory) CreateTextBox() TextBox {
    return MacTextBox{}
}

这样做的好处是，调用者只需选择一个工厂，就能获得一整套兼容的对象组合。

简单工厂 vs 抽象工厂：区别与选型建议

建议如下：

• 如果只是创建几个简单的对象，优先考虑简单工厂。
• 如果产品之间有明确的“家族”关系，或者未来可能扩展多个产品族，抽象工厂更适合。
• 抽象工厂虽然结构清晰，但也带来了更多接口和结构定义，不要为了用模式而用模式。
• 在 Golang 中，由于没有继承机制，抽象工厂更依赖于接口组合来实现，因此要注意接口设计的合理性。

总的来说，简单工厂适合快速上手和小规模使用，抽象工厂适合大型系统或需要良好扩展性的场景。两者各有优劣，关键在于理解当前业务需求和未来的扩展方向。

基本上就这些。