189 8069 5689

go语言实现设计模式 go语言编写

手撸golang 行为型设计模式 委派模式

最近复习设计模式

创新互联公司公司2013年成立,先为浮梁等服务建站,浮梁等地企业,进行企业商务咨询服务。为浮梁企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。

拜读谭勇德的设计模式就该这样学

本系列笔记拟采用golang练习之

委派模式(Delegate Pattern)又叫作委托模式,基本作用就是负责任务的调用和分配,是一种特殊的静态代理模式,可以理解为全权代理模式,但是代理模式注重过程,而委派模式注重结果。

委派模式有3个参与角色。

(1)抽象任务角色(ITask):定义一个抽象接口,它有若干实现类。

(2)委派者角色(Delegate):负责在各个具体角色实例之间做出决策,判断并调用具体实现的方法。

(3)具体任务角色(Concrete):真正执行任务的角色。

_

delegate_pattern_test.go

定义消息接口

消息的基类, 实现IMsg接口

表示原样返回的消息, 用于PING/PONG心跳. 继承自BaseMsg

表示获取服务器时间的消息. 继承自BaseMsg

消息处理器接口. 调度器和具体消息处理器, 均需要实现此接口.

全局消息调度器, 是所有客户端消息的统一入口. 用于注册消息处理器, 按类型分发消息. 实现IMsgHandler接口.

专门处理EchoMsg消息的处理器. 实现IMsgHandler接口.

专门处理TimeMsg消息的处理器, 实现IMsgHandler接口.

委派模式的优点

通过任务委派能够将一个大型任务细化,然后通过统一管理这些子任务的完成情况实现任务的跟进,加快任务执行的效率。

委派模式的缺点

任务委派方式需要根据任务的复杂程度进行不同的改变,在任务比较复杂的情况下,可能需要进行多重委派,容易造成紊乱。

_

(end)

Go语言设计与实现(上)

基本设计思路:

类型转换、类型断言、动态派发。iface,eface。

反射对象具有的方法:

编译优化:

内部实现:

实现 Context 接口有以下几个类型(空实现就忽略了):

互斥锁的控制逻辑:

设计思路:

(以上为写被读阻塞,下面是读被写阻塞)

总结,读写锁的设计还是非常巧妙的:

设计思路:

WaitGroup 有三个暴露的函数:

部件:

设计思路:

结构:

Once 只暴露了一个方法:

实现:

三个关键点:

细节:

让多协程任务的开始执行时间可控(按顺序或归一)。(Context 是控制结束时间)

设计思路: 通过一个锁和内置的 notifyList 队列实现,Wait() 会生成票据,并将等待协程信息加入链表中,等待控制协程中发送信号通知一个(Signal())或所有(Boardcast())等待者(内部实现是通过票据通知的)来控制协程解除阻塞。

暴露四个函数:

实现细节:

部件:

包: golang.org/x/sync/errgroup

作用:开启 func() error 函数签名的协程,在同 Group 下协程并发执行过程并收集首次 err 错误。通过 Context 的传入,还可以控制在首次 err 出现时就终止组内各协程。

设计思路:

结构:

暴露的方法:

实现细节:

注意问题:

包: "golang.org/x/sync/semaphore"

作用:排队借资源(如钱,有借有还)的一种场景。此包相当于对底层信号量的一种暴露。

设计思路:有一定数量的资源 Weight,每一个 waiter 携带一个 channel 和要借的数量 n。通过队列排队执行借贷。

结构:

暴露方法:

细节:

部件:

细节:

包: "golang.org/x/sync/singleflight"

作用:防击穿。瞬时的相同请求只调用一次,response 被所有相同请求共享。

设计思路:按请求的 key 分组(一个 *call 是一个组,用 map 映射存储组),每个组只进行一次访问,组内每个协程会获得对应结果的一个拷贝。

结构:

逻辑:

细节:

部件:

如有错误,请批评指正。

Go语言实践模式 - 函数选项模式(Functional Options Pattern)

大家好,我是小白,有点黑的那个白。

最近遇到一个问题,因为业务需求,需要对接第三方平台.

而三方平台提供的一些HTTP(S)接口都有统一的密钥生成规则要求.

为此我们封装了一个独立的包 xxx-go-sdk 以便维护和对接使用.

其中核心的部分是自定义HTTP Client,如下:

一些平台会要求appKey/appSecret等信息,所以Client结构体就变成了这样,这时参数还比较少, 而且是必填的参数,我们可以提供构造函数来明确指定。

看起来很满足,但是当我们需要增加一个 Timeout 参数来控制超时呢?

或许你会说这还不简单,像下面一样再加一个参数呗

那再加些其他的参数呢?那构造函数的参数是不是又长又串,而且每个参数不一定是必须的,有些参数我们又会考虑默认值的问题。

为此,勤劳但尚未致富的 gophers 们使用了总结一种实践模式

首先提取所有需要的参数到一个独立的结构体 Options,当然你也可以用 Configs 啥的.

然后为每个参数提供设置函数

这样我们就为每个参数设置了独立的设置函数。返回值 func(*Options) 看着有点不友好,我们提取下定义为单个 Option 调整一下代码

当我们需要添加更多的参数时,只需要在 Options 添加新的参数并添加新参数的设置函数即可。

比如现在要添加新的参数 Timeout

这样后续不管新增多少参数,只需要新增配置项并添加独立的设置函数即可轻松扩展,并且不会影响原有函数的参数顺序和个数位置等。

至此,每个选项是区分开来了,那么怎么作用到我们的 Client 结构体上呢?

首先,配置选项都被提取到了 Options 结构体重,所以我们需要调整一下 Client 结构体的参数

其次,每一个选项函数返回 Option,那么任意多个就是 ...Option,我们调整一下构造函数 NewClient 的参数形式,改为可变参数,不再局限于固定顺序的几个参数。

然后循环遍历每个选项函数,来生成Client结构体的完整配置选项。

那么怎么调用呢?对于调用方而已,直接在调用构造函数NewClient()的参数内添加自己需要的设置函数(WithXXX)即可

当需要设置超时参数,直接添加 WithTimeout即可,比如设置3秒的超时

配置选项的位置可以任意设置,不需要受常规的固定参数顺序约束。

可以看到,这种实践模式主要作用于配置选项,利用函数支持的特性来实现的,为此得名 Functional Options Pattern,优美的中国话叫做「函数选项模式」。

最后, 我们总结回顾一下在Go语言中函数选项模式的优缺点


文章标题:go语言实现设计模式 go语言编写
转载注明:http://cdxtjz.cn/article/ddjpeeo.html

其他资讯