Go设计模式学习——开闭原则

1 开闭原则

对扩展开放、修改关闭 (Open Closed Principle)

software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification

直译: 软件实体（模块、类、方法等）应该 “ 对扩展开放、对修改关闭 ”。

白话: 添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。

重要性: 大部分设计模式是为了解决代码的扩展性问题而存在的，主要遵从的设计原则:开闭原则。

1.1 问题

• 怎样的代码改动才被定义为‘扩展’
• 怎样的代码改动才被定义为‘修改’
• 怎么才算满足或违反‘开闭原则’
• 修改代码就一定意味着违反‘开闭原则’吗

同样的代码改动，在粗代码粒度，可能被认定为“修改”；在细代码粒度，可能又被认定为“扩展”。

开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发。

核心: 尽量让修改操作更集中、更少、更上层，让最核心、最复杂部分逻辑代码满足开闭原则。

1.2 指导思想

1.2.1 底层思维

• 扩展意识
• 抽象意识
• 封装意识

思考: 代码未来可能有哪些需求变更、如何设计代码结构

预留: 事先留好扩展点，以便在未来需求变更的时候，不需要改动代码整体结构、做到最小代码改动的情况下，新的代码能够很灵活地插入到扩展点上

识别: 识别出代码可变部分和不可变部分之后，我们要将可变部分封装起来，隔离变化，提供抽象化的不可变接口，给上层系统使用. 当具体的实现发生变化的时候，我们只需要基于相同的抽象接口，扩展一个新的实现，替换掉老的实现即可，上游系统的代码几乎不需要修改。

1.2.2 如何应用

可以根据每个人的开发工作所属领域进行区分: 偏业务还是偏技术?

• 业务系统
  • 对业务有足够的了解
  • 知道当下以及未来可能要支持的业务需求
• 通用的、偏底层的系统(框架、组件、类库)
  • 它们会被如何使用？
  • 今后你打算添加哪些功能？
  • 使用者未来会有哪些更多的功能需求？

可以通过业界成熟的手段践行开闭原则思想:

• 多态
• 依赖注入
• 基于接口而非实现编程
• 大部分的设计模式（比如，装饰、策略、模板、职责链、状态等）

1.2.3 多态栗子

/**
 * @Author wangshuai52
 * @desc 当接口请求个数超过某个阈值发出告警
 * @aim Go语言-开闭原则
 */
package main

import "fmt"

// 报警规则
type AlertRule struct{}

// tps阈值
func (a *AlertRule) GetTpsCount(api string) int64 {
	return 10
}

// 错误数阈值
func (a *AlertRule) GetErrCount(api string) int64 {
	return 10
}

// 告警通知
type Notification struct{}

func (n *Notification) Notify(level string) {
	fmt.Println("APP Notify: ", level)
}

// 监控接口
type Alert struct {
	rule         *AlertRule
	notification *Notification
}

// 构造函数创建实例，如果单实例参考之前文档单实例创建方式
func NewAlert(rule *AlertRule, notification *Notification) *Alert {
	return &Alert{
		rule:         rule,
		notification: notification,
	}
}

// 检查
func (a *Alert) check(api string, requestCnt, errCnt, durationOfSeconds int64) {
	// 每秒事务处理数
	tps := requestCnt / durationOfSeconds
	// tps告警
	if tps > a.rule.GetTpsCount(api) {
		a.notification.Notify("请求数太多了!")
	}
	// 错误数告警
	if errCnt > a.rule.GetErrCount(api) {
		a.notification.Notify("错误数太多了!")
	}
}

// main主函数
func main() {
	aa := NewAlert(&AlertRule{}, &Notification{})
	aa.check("pay", 100, 100, 1)
}

运行结果

以上代码实现非常简单，但是当需要增加一个新功能，比如当每秒钟超时请求个数超过某个阈值，需要触发告警通知，针对以上代码设计需要修改两处：

• 修改check接口增加timeout入参
• check内部增加超时逻辑相关代码

//接口处增加timeout入参
func (a *Alert) check(api string, requestCnt, errCnt, durationOfSeconds int64) {
	// 每秒事务处理数
	tps := requestCnt / durationOfSeconds
	// tps告警
	if tps > a.rule.GetTpsCount(api) {
		a.notification.Notify("请求数太多了!")
	}
	// 错误数告警
	if errCnt > a.rule.GetErrCount(api) {
		a.notification.Notify("错误数太多了!")
	}
	//此处增加超时逻辑,并扩展rule和Notify
}

借鉴开闭原则进行优化:

UML类图:

• 蓝色是go的构造函数(直接写的函数实现)
• 红色是新增超时告警时需要新增的代码

抽象理解如图所示,红色为需要新增的部分代码

package main

import "fmt"

// 告警处理器群 实例
type Alertx struct {
	AlertHandlers []AlertHandler // 注册存储不同告警功能模块
}

// 告警处理器
type AlertHandler interface {
	Check(info ApiInfo)
}

// Api数据指标
type ApiInfo struct {
	Api        string
	RequestCnt int64
	ErrCnt     int64
	DurOfSecs  int64
	TimeoutCnt int64
}

// 处理器群 构造函数
func NewAlertx() *Alertx {
	return &Alertx{
		AlertHandlers: make([]AlertHandler, 0),
	}
}

// 处理器群 添加 处理器
func (a *Alertx) AddHandler(aHandler AlertHandler) {
	a.AlertHandlers = append(a.AlertHandlers, aHandler)
}

// 处理器群 轮询处理
func (a *Alertx) CheckAll(aInfo ApiInfo) {
	for _, handler := range a.AlertHandlers {
		handler.Check(aInfo)
	}
}

// 报警规则
type AlertRule struct{}

// tps阈值
func (a *AlertRule) GetTpsCount(api string) int64 {
	return 10
}

// 错误数阈值
func (a *AlertRule) GetErrCount(api string) int64 {
	return 10
}

// 告警通知
type Notification struct{}

func (n *Notification) Notify(level string) {
	fmt.Println("APP Notify: ", level)
}

// 实现AlertHandler接口，按照TPS规则
type TpsAlertHandler struct {
	rule         *AlertRule
	notification *Notification
}

func NewTpsAlertHandler(rule *AlertRule, notification *Notification) *TpsAlertHandler {
	return &TpsAlertHandler{
		rule:         rule,
		notification: notification,
	}
}
func (t *TpsAlertHandler) Check(info ApiInfo) {
	tps := info.RequestCnt / info.DurOfSecs
	if tps > t.rule.GetTpsCount(info.Api) {
		t.notification.Notify("TPS 太高了!!")
	}
	fmt.Println("TPS处理完成")
}

// 实现AlertHandler接口，按照Err规则实现
type ErrAlertHandler struct {
	rule         *AlertRule
	notification *Notification
}

func NewErrAlertHandler(rule *AlertRule, notification *Notification) *ErrAlertHandler {
	return &ErrAlertHandler{
		rule:         rule,
		notification: notification,
	}
}

// 实现AlertHandler接口
func (e *ErrAlertHandler) Check(info ApiInfo) {
	if info.ErrCnt > e.rule.GetErrCount(info.Api) {
		e.notification.Notify("ERR数 太高了!!")
	}
	fmt.Println("Err处理完成")
}

//------------------------------------
// 新增超时处理,struct也要新增数据字段TimeoutCnt

func (a *AlertRule) GetTimeoutCount(api string) int64 {
	return 10
}

type TimeoutAlertHandler struct {
	rule         *AlertRule
	notification *Notification
}

func NewTimeoutAlertHandler(rule *AlertRule, notification *Notification) *TimeoutAlertHandler {
	return &TimeoutAlertHandler{
		rule:         rule,
		notification: notification,
	}
}

func (t *TimeoutAlertHandler) Check(info ApiInfo) {
	if info.TimeoutCnt > t.rule.GetTimeoutCount(info.Api) {
		t.notification.Notify("Timeout数 太高了!!")
	}
	fmt.Println("Timeout处理完成")
}

//------------------------------------
func main() {
	alerts := NewAlertx()
	infos := ApiInfo{
		Api:        "pay",
		RequestCnt: 100,
		ErrCnt:     100,
		DurOfSecs:  1,
		TimeoutCnt: 100,
	}
	alerts.AddHandler(NewTpsAlertHandler(&AlertRule{}, &Notification{}))
	alerts.AddHandler(NewErrAlertHandler(&AlertRule{}, &Notification{}))
	alerts.AddHandler(NewTimeoutAlertHandler(&AlertRule{}, &Notification{}))
	alerts.CheckAll(infos)
}

运行结果:

1.3 总结

1.3.1 唯一不变的是变化本身

• 即便我们对业务、对系统有足够的了解，那也不可能识别出所有的扩展点
• 即便你能识别出所有的扩展点，为这些地方都预留扩展点，这样做的成本也是不可接受的。
• 我们没必要为一些太遥远的、不一定发生的需求去提前买单，做过度设计。

1.3.2 最佳实践

• 对于一些比较确定的、短期内可能就会扩展，或者需求改动对代码结构影响比较大的情况，或者实现成本不高的扩展点，在编写代码的时候之后，我们就可以事先做些扩展性设计。
• 对于一些不确定未来是否要支持的需求，或者实现起来比较复杂的扩展点，我们可以等到有需求驱动的时候，再通过重构代码的方式来支持扩展的需求。

1.3.3 扩展性与可读性

提高代码扩展性也有成本。代码的扩展性会跟可读性相冲突。

为了更好地支持扩展性，我们对代码进行了重构工作，重构之后的代码要比之前的代码复杂很多，理解起来也更加有难度。很多时候，我们都需要在扩展性和可读性之间做权衡。

在某些场景下，代码的扩展性很重要，我们就可以适当地牺牲一些代码的可读性；

在另一些场景下，代码的可读性更加重要，那我们就适当地牺牲一些代码的可扩展性。

1.4 结束语

没有一个放之四海而皆准的参考标准，全凭实际的应用场景来决定。

对拓展开放是为了应对变化(需求)，对修改关闭是为了保证已有代码的稳定性