设计模式 7年前

golang 设计模式之简单工厂模式

作者头像 刘宇帅
2883 0

简单工厂模式(Sample Factory Pattern)是最常用的设计模式之一。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。
在工厂模式中,我们在创建对象时不会对客户端暴露创建逻辑,并且是通过使用一个共同的接口来指向新创建的对象。

介绍

  • 意图:提供一个创建对象的工厂,工厂类函数会根据不同的参数创建实现了同一接口的不同产品类。
  • 解决问题:主要解决接口选择的问题
  • 优点
    • 如果要创建一个产品对象只要知道其名字就可以了,不需要关心具体实现
    • 可扩展,只需要实现一个产品类就可以了
  • 缺点
    • 不同的实现都需要实现一个具体的类,提升系统复杂性
    • 新增产品类的时候需要修改创建对象的工厂类,增加系统依赖
  • 可应用场景举例
    • 日志:日志可被写入文件、api 接口、数据库、syslog 等不同的地方

实现

这里以日志场景实现

结构

代码

创建一个日志接口

// 日志接口
type Logger interface {
    Name() string
}

SysLog 的实现

// 系统日志
type SysLog struct {
}

func (s *SysLog) Name() string {
    return "sysLog"
}

FileLog 的实现

// 文件日志
type FileLog struct {
}

func (f *FileLog) Name() string {
    return "fileLog"
}

面向用户的工厂类实现

type LoggerFactory struct {
}

func (l *LoggerFactory) GetLogger(name string) (Logger, error) {
    switch name {
    case "sysLog":
        return new(SysLog), nil
    case "fileLog":
        return new(FileLog), nil
    default:
        return nil, fmt.Errorf("logger %s not found", name)
    }
}

测试用例

func TestSimpleFactory(t *testing.T) {
    loggerFactory := new(LoggerFactory)
    sysLog, err := loggerFactory.GetLogger("sysLog")
    if err != nil {
        t.Errorf("get SysLog error: %s", err.Error())
    }
    if sysLog.Name() != "sysLog" {
        t.Errorf("get SysLog name error: %s", sysLog.Name())
    }

    fileLog, err := loggerFactory.GetLogger("fileLog")

    if err != nil {
        t.Errorf("get FileLog error: %s", err.Error())
    }

    if fileLog.Name() != "fileLog" {
        t.Errorf("get FileLog name error: %s", fileLog.Name())
    }
}

测试输出:

> $ go test
PASS
ok      github.com/yushuailiu/go-algorithm/pattern/simpleFactory    0.005s

源码地址

作者头像

刘宇帅

非著名程序员,全栈开发工程师,长期专注系统开发与架构设计。

提示

功能待开通!


暂无评论~

相关文章

golang 设计模式之抽象工厂模式

抽象工厂模式(Abstract Factory Pattern)是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。 介绍 意图:提供一个创建一系列相关或则相互依赖对象的接口,而无需指定他们依赖的类。 解决问题:主要解决接口选择的问题 优点:调用方面向接口编程,不用关心具体实现 缺点:扩展新的产品复杂,新增一个新产品需要修改工厂接口和所有工厂类 可应用场景 系统主题:比如一个游戏主题分为男生主题、女生主题 实现 以系统主题为例 结构 代码 游戏颜色 // 颜色接口 type Color interface {

依赖注入、控制反转容器、服务定位器

在了解依赖注入和服务定位器之前先了解以下两种模式的思想基础:依赖倒置原则和控制反转 依赖倒置原则(Dependence Inversion Principle,DIP) 定义 高层次的模块不应该依赖于低层次的模块,两者都应该依赖于抽象接口。 抽象接口不应该依赖于具体实现。而具体实现则应该依赖于抽象接口。 问题由来 类A直接依赖于类B,假如要将类A改为依赖类C,则必须修改类A的代码来完成,这种场景下一般A类为业务类,而B、C类为底层模块,假如因此修改了A类代码,会给程序带来不必要的风险。 解决方案 将A类修改为依赖接口D,类B和类C分别实现接口D,类A通过接口D和B、C发生关联,这样会大

设计模式概述

设计模式(Design pattern)代表了最佳的实践,通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。 设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样。项目中合理地运用设计模式可以完美地解决很多问题,每种模式在现实中都有相应的原理来与