十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
最近复习设计模式
创新互联公司公司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)
基本设计思路:
类型转换、类型断言、动态派发。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 映射存储组),每个组只进行一次访问,组内每个协程会获得对应结果的一个拷贝。
结构:
逻辑:
细节:
部件:
如有错误,请批评指正。
大家好,我是小白,有点黑的那个白。
最近遇到一个问题,因为业务需求,需要对接第三方平台.
而三方平台提供的一些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语言中函数选项模式的优缺点