专栏首页Golang语言社区Golang视角下的设计模式

Golang视角下的设计模式

这篇文章想聊聊Golang语言下的设计模式问题,我觉得这个话题还是比较有意思的。Golang没有像java那样对设计模式疯狂的迷恋,而是摆出了一份“看庭前花开花落,望天空云卷云舒”的姿态。

单例模式:

Gloang的单例模式该怎么写?随手写一个,不错,立马写出来了。但这个代码有什么问题呢?多个协程同时执行这段代码就会出现问题:instance可能会被赋值多次,这段代码是线程不安全的代码。那么如何保证在多线程下只执行一次呢?条件反射:加锁。。。加锁是可以解决问题。但不是最优的方案,因为如果有1W并发,每一个线程都竞争锁,同一时刻只有一个线程能拿到锁,其他的全部阻塞等待。让原本想并发得飞起来变成了一切认怂串行化。通过check-lock-check方式可以减少竞争。还有其他方式,利用sync/atomic和sync/once 这里只给出代码

  1. func NewSingleton() *singleton {
  2. if instance == nil {
  3. instance = &singleton{}
  4. }
  5. return instance
  6. }

复制代码

  1. func NewSingleton() *singleton {
  2. l.Lock() // lock
  3. defer l.Unlock()
  4. if instance == nil { // check
  5. instance = &singleton{}
  6. }
  7. return instance
  8. }

复制代码

  1. func NewSingleton() *singleton {
  2. if instance == nil { // check
  3. l.Lock() // lock
  4. defer l.Unlock()
  5. if instance == nil { // check
  6. instance = &singleton{}
  7. }
  8. }
  9. return instance
  10. }

复制代码

  1. func NewSingleton() *singleton {
  2. if atomic.LoadUInt32(&initialized) == 1 {
  3. return instance
  4. }
  5. mu.Lock()
  6. defer mu.Unlock()
  7. if initialized == 0 {
  8. instance = &singleton{}
  9. atomic.StoreUint32(&initialized, 1)
  10. }
  11. return instance
  12. }

复制代码

  1. func NewSingleton() *singleton {
  2. once.Do(func() {
  3. instance = &singleton{}
  4. })
  5. return instance
  6. }

复制代码

工厂模式:

工厂根据条件产生不同功能的类。工厂模式使用经常使用在替代new的场景中,让工厂统一根据不同条件生产不同的类。工厂模式在解耦方面将使用者和产品之间的依赖推给了工厂,让工厂承担这种依赖关系。工厂模式又分为简单工厂,抽象工厂。golang实现一个简单工厂模式如下:

  1. package main
  2. import (
  3. "fmt"
  4. )
  5. type Op interface {
  6. getName() string
  7. }
  8. type A struct {
  9. }
  10. type B struct {
  11. }
  12. type Factory struct {
  13. }
  14. func (a *A) getName() string {
  15. return "A"
  16. }
  17. func (b *B) getName() string {
  18. return "B"
  19. }
  20. func (f *Factory) create(name string) Op {
  21. switch name {
  22. case `a`:
  23. return new(A)
  24. case `b`:
  25. return new(B)
  26. default:
  27. panic(`name not exists`)
  28. }
  29. return nil
  30. }
  31. func main() {
  32. var f = new(Factory)
  33. p := f.create(`a`)
  34. fmt.Println(p.getName())
  35. p = f.create(`b`)
  36. fmt.Println(p.getName())
  37. }

复制代码

依赖注入:

具体含义是:当某个角色(可能是一个实例,调用者)需要另一个角色(另一个实例,被调用者)的协助时,在传统的程序设计过程中,通常由调用者来创建被调用者的实例。但在这种场景下,创建被调用者实例的工作通常由容器(IoC)来完成,然后注入调用者,因此也称为依赖注入。 Golang利用函数f可以当做参数来传递,同时配合reflect包拿到参数的类型,然后根据调用者传来的参数和类型匹配上之后,最后通过reflect.Call()执行具体的函数。下面的代码来自:https://www.studygolang.com/articles/4957 这篇文章上。

  1. package main
  2. import (
  3. "fmt"
  4. "reflect"
  5. )
  6. var inj *Injector
  7. type Injector struct {
  8. mappers map[reflect.Type]reflect.Value // 根据类型map实际的值
  9. }
  10. func (inj *Injector) SetMap(value interface{}) {
  11. inj.mappers[reflect.TypeOf(value)] = reflect.ValueOf(value)
  12. }
  13. func (inj *Injector) Get(t reflect.Type) reflect.Value {
  14. return inj.mappers[t]
  15. }
  16. func (inj *Injector) Invoke(i interface{}) interface{} {
  17. t := reflect.TypeOf(i)
  18. if t.Kind() != reflect.Func {
  19. panic("Should invoke a function!")
  20. }
  21. inValues := make([]reflect.Value, t.NumIn())
  22. for k := 0; k < t.NumIn(); k++ {
  23. inValues[k] = inj.Get(t.In(k))
  24. }
  25. ret := reflect.ValueOf(i).Call(inValues)
  26. return ret
  27. }
  28. func Host(name string, f func(a int, b string) string) {
  29. fmt.Println("Enter Host:", name)
  30. fmt.Println(inj.Invoke(f))
  31. fmt.Println("Exit Host:", name)
  32. }
  33. func Dependency(a int, b string) string {
  34. fmt.Println("Dependency: ", a, b)
  35. return `injection function exec finished ...`
  36. }
  37. func main() {
  38. // 创建注入器
  39. inj = &Injector{make(map[reflect.Type]reflect.Value)}
  40. inj.SetMap(3030)
  41. inj.SetMap("zdd")
  42. d := Dependency
  43. Host("zddhub", d)
  44. inj.SetMap(8080)
  45. inj.SetMap("www.zddhub.com")
  46. Host("website", d)
  47. }

复制代码

装饰器模式:

装饰器模式:允许向一个现有的对象添加新的功能,同时又不改变其结构。这种类型的设计模式属于结构型模式,它是作为现有的类的一个包装。这种模式创建了一个装饰类,用来包装原有的类,并在保持类方法签名完整性的前提下,提供了额外的功能。我们使用最为频繁的场景就是http请求的处理:对http请求做cookie校验。

  1. package main
  2. import (
  3. "fmt"
  4. "log"
  5. "net/http"
  6. )
  7. func autoAuth(h http.HandlerFunc) http.HandlerFunc {
  8. return func(w http.ResponseWriter, r *http.Request) {
  9. cookie, err := r.Cookie("Auth")
  10. if err != nil || cookie.Value != "Authentic" {
  11. w.WriteHeader(http.StatusForbidden)
  12. return
  13. }
  14. h(w, r)
  15. }
  16. }
  17. func hello(w http.ResponseWriter, r *http.Request) {
  18. fmt.Fprintf(w, "Hello, World! "+r.URL.Path)
  19. }
  20. func main() {
  21. http.HandleFunc("/hello", autoAuth(hello))
  22. err := http.ListenAndServe(":5666", nil)
  23. if err != nil {
  24. log.Fatal("ListenAndServe: ", err)
  25. }
  26. }

复制代码

还有很多其他模式,这里不一一给出了,写这篇文章的目的是想看看这些模式在golang中是如何体现出来的,框架或者类库应该是设计模式常常出没的地方。深入理解设计模式有助于代码的抽象,复用和解耦,让代码与代码之间更加低耦合。

本文分享自微信公众号 - Golang语言社区(Golangweb)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2017-09-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Golang视角下的设计模式

    这篇文章想聊聊Golang语言下的设计模式问题,我觉得这个话题还是比较有意思的。Golang没有像java那样对设计模式疯狂的迷恋,而是摆出了一份“看庭前花开花...

    李海彬
  • 甜品店切蛋糕问题(动态规划,Go语言实现)

    问题重现: 小Y最近在甜品店工作,其工作是切蛋糕。现在有n个顾客来购买蛋糕,并且每个顾客有一个到达的时间,以及需要买的蛋糕的长度ai。由于小Y每次只能服务一个顾...

    李海彬
  • go语言中的interface使用实例

    go语言中的interface是一组未实现的方法的集合,如果某个对象实现了接口中的所有方法,那么此对象就实现了此接口。与其它面向对象语言不同的是,go中无需显示...

    李海彬
  • Golang视角下的设计模式

    这篇文章想聊聊Golang语言下的设计模式问题,我觉得这个话题还是比较有意思的。Golang没有像java那样对设计模式疯狂的迷恋,而是摆出了一份“看庭前花开花...

    李海彬
  • 验证二叉搜索树

    大忽悠爱学习
  • 5330. 分裂二叉树的最大乘积(dfs)

    题目链接:https://leetcode-cn.com/contest/weekly-contest-174/problems/maximum-product...

    Ch_Zaqdt
  • 《剑指 offer》刷题记录之:回溯法

    回溯法可以看成蛮力法的升级版,它从解决问题每一步的所有可能选项里系统地选择出一个可行的解决方案。回溯法非常适合由「多个步骤」组成的问题,并且每个步骤都有多个选项...

    口仆
  • 独到的见解,关于分布式事务,我有这些话要说

    这几天看分布式事务相关的知识,网上的信息都是大同小异,但总感觉理解起来比较费劲,不够接地气,所以自己按照自己的理解宏观的总结了一下,因为是纯理论的,没图,看着可...

    Java程序猿阿谷
  • 从Linux系统磁盘空间不足引发的Zabbix服务器数据库迁移

            之前一直没有去关心Zabbbix服务器存储空间问题,最近Zabbix报警提示/根目录磁盘空间不足,于是登录Zabbix看了一下,发现根目录只有1...

    木子-Lee
  • 一向低调的小伙放了个大招,搞定了微服务接口单测依赖问题

    在微服务架构中,服务之间的依赖是很常见的事情。在开发过程中都是并行开发的,前端会依赖后端的接口,后端也有可能会依赖其他后端服务的接口。

    猿天地

扫码关注云+社区

领取腾讯云代金券