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://scyanting.com/article/ddjpeeo.html
