Go设计模式(3)-设计原则
上一篇文章Go设计模式(2)-面向对象分析与设计里讲过,做设计最重要的是保留合适的扩展点。如何才能设计出合适的扩展点呢?
这篇文章会讲解一下经典的设计原则。这些设计原则大家可能都听过,但可能没有想过为什么会提炼出这些原则,它们有什么作用。对内一个设计原则,我会尽量找到一个实例,说明它的重要性。通过实例来感受原则,比起只看枯燥的文字有效的多。
在这里需要说明一点,设计原则是一种思想,设计模式是这种思想的具象化。所以当我们真正领悟到这种思想后,设计的时候会事半功倍。
本文要阐述的原则如下:
- 单一职责原则
- 开放-封闭原则
- 里氏替换原则
- 接口隔离原则
- 依赖倒转原则
- 迪米特法则
单一职责原则
理解原则
单一职责原则(SRP):一个类只负责完成一个职责或者功能。不要设计大而全的类,要设计粒度小、功能单一的类。单一职责原则是为了实现代码高内聚、低耦合,提高代码的复用性、可读性、可维护性。
实施
不同的应用场景、不同阶段的需求背景、不同的业务层面,对同一个类的职责是否单一,可能会有不同的判定结果。实际上,一些侧面的判断指标更具有指导意义和可执行性,比如,出现下面这些情况就有可能说明这类的设计不满足单一职责原则:
- 类中的代码行数、函数或者属性过多;
- 类依赖的其他类过多,或者依赖类的其他类过多;
- 私有方法过多;
- 比较难给类起一个合适的名字;
- 类中大量的方法都是集中操作类中的某几个属性。
实例
假设我们要做一个在手机上玩的俄罗斯方块游戏,Game类可以设计如下:
type Game struct {x int64y int64
}
func (game *Game) Show() {fmt.Println(game.x, game.y)
}
func (game *Game) Move() {game.x--game.y++
}
游戏的显示和移动都放在类Game里。后面需求变更了,不但要在手机上显示,还需要再电脑上显示,而且还有两人对战模式,这些更改主要和显示有关。
这时最好将Show和Move拆分到两个函数,这样不但可以复用Move的逻辑,而且今后无论如何更改Show,都不会影响Move所在的类。
但因为一开始Game职责不单一,整个系统中很多位置使用同一个Game变量调用Show和Move,对这些位置的改动和测试是十分浪费时间的。
开放-封闭原则
理解原则
对扩展开放、修改关闭(OCP):添加一个新的功能,应该是通过在已有代码基础上扩展代码(新增模块、类、方法、属性等),而非修改已有代码(修改模块、类、方法、属性等)的方式来完成。
- 第一点,开闭原则并不是说完全杜绝修改,而是以最小的修改代码的代价来完成新功能的开发。
- 第二点,同样的代码改动,在粗代码粒度下,可能被认定为“修改”;在细代码粒度下,可能又被认定为“扩展”。
实施
我们要时刻具备扩展意识、抽象意识、封装意识。在写代码的时候,我们要多花点时间思考一下,这段代码未来可能有哪些需求变更,如何设计代码结构,事先留好扩展点,以便在未来需求变更的时候,在不改动代码整体结构、做到最小代码改动的情况下,将新的代码灵活地插入到扩展点上。
很多设计原则、设计思想、设计模式,都是以提高代码的扩展性为最终目的的。特别是23种经典设计模式,大部分都是为了解决代码的扩展性问题而总结出来的,都是以开闭原则为指导原则的。最常用来提高代码扩展性的方法有:多态、依赖注入、基于接口而非实现编程,以及大部分的设计模式(比如,装饰、策略、模板、职责链、状态)。
实例
假设我们要做一个API接口监控告警,如果TPS或Error超过指定值,则根据不同的紧急情况通过不同方式(邮箱、电话)通知相关人员。根据Go设计模式(2)-面向对象分析与设计里讲的方案,我们先找出类。
业务实现流程为:
- 获取异常指标
- 获取异常数据,和异常指标进行比较
- 通知相关人员
所以,我们可以设置三个类,AlertRules存放报警规则,Notification用来通知,Alert用来比较。
//存储报警规则
type AlertRules struct {}func (alertRules *AlertRules) GetMaxTPS(api string) int64 {if api == "test" {return 10}return 100
}
func (alertRules *AlertRules) GetMaxError(api string) int64 {if api == "test" {return 10}return 100
}const (SERVRE = "SERVRE"URGENT = "URGENT"
)//通知类
type Notification struct {}func (notification *Notification) Notify(notifyLevel string) bool {if notifyLevel == SERVRE {fmt.Println("打电话")} else if notifyLevel == URGENT {fmt.Println("发短信")} else {fmt.Println("发邮件")}return true
}//检查类
type Alert struct {alertRules *AlertRulesnotification *Notification
}func CreateAlert(a *AlertRules, n *Notification) *Alert {return &Alert{alertRules: a,notification: n,}
}
func (alert *Alert) Check(api string, tps int64, errCount int64) bool {if tps > alert.alertRules.GetMaxTPS(api) {alert.notification.Notify(URGENT)}if errCount > alert.alertRules.GetMaxError(api) {alert.notification.Notify(SERVRE)}return true
}
func main() {alert := CreateAlert(new(AlertRules), new(Notification))alert.Check("test", 20, 20)
}
虽然程序比较简陋,但是是面向对象的,而且能跑。
对于这个需求,有很多可能的变动点,最可能变的是增加新的报警指标。现在新需求来了,如果每秒内接口超时量超过指定值,也需要报警,我们需要怎么做?
如果在原有代码上修改,我们需要
AlertRules上添加新的规则
Check函数增加新的入参timeoutCount
Check函数中增加新的判断逻辑
if timeoutCount > alert.alertRules.GetMaxTimeoutCount(api) {alert.notification.Notify(SERVRE) }
这会导致一些问题,一是Check可能在多个地方被引用,所以这些位置都需要进行修改,二是更改了Check逻辑,需要重新做这部分的测试。如果说我们做第一版没有预料到这些变化,但现在我们找到了可能的变更点,我们是否有好的方案能够做好扩展,让下次改动量最小?
我们把Alert中Check做的事情拆散,放到对应的类里,这些类都实现了AlertHandler接口。
//优化
type ApiStatInfo struct {api stringtps int64errCount int64timeoutCount int64
}type AlertHandler interface {Check(apiStatInfo ApiStatInfo) bool
}type TPSAlertHandler struct {alertRules *AlertRulesnotification *Notification
}func CreateTPSAlertHandler(a *AlertRules, n *Notification) *TPSAlertHandler {return &TPSAlertHandler{alertRules: a,notification: n,}
}func (tPSAlertHandler *TPSAlertHandler) Check(apiStatInfo ApiStatInfo) bool {if apiStatInfo.tps > tPSAlertHandler.alertRules.GetMaxTPS(apiStatInfo.api) {tPSAlertHandler.notification.Notify(URGENT)}return true
}type ErrAlertHandler struct {alertRules *AlertRulesnotification *Notification
}func CreateErrAlertHandler(a *AlertRules, n *Notification) *ErrAlertHandler {return &ErrAlertHandler{alertRules: a,notification: n,}
}func (errAlertHandler *ErrAlertHandler) Check(apiStatInfo ApiStatInfo) bool {if apiStatInfo.errCount > errAlertHandler.alertRules.GetMaxError(apiStatInfo.api) {errAlertHandler.notification.Notify(SERVRE)}return true
}type TimeOutAlertHandler struct {alertRules *AlertRulesnotification *Notification
}func CreateTimeOutAlertHandler(a *AlertRules, n *Notification) *TimeOutAlertHandler {return &TimeOutAlertHandler{alertRules: a,notification: n,}
}func (timeOutAlertHandler *TimeOutAlertHandler) Check(apiStatInfo ApiStatInfo) bool {if apiStatInfo.timeoutCount > timeOutAlertHandler.alertRules.GetMaxTimeOut(apiStatInfo.api) {timeOutAlertHandler.notification.Notify(SERVRE)}return true
}
Alert类增加成员变量handlers []AlertHandler,并添加如下函数
//版本2
func (alert *Alert) AddHanler(alertHandler AlertHandler) {alert.handlers = append(alert.handlers, alertHandler)
}
func (alert *Alert) CheckNew(apiStatInfo ApiStatInfo) bool {for _, h := range alert.handlers {h.Check(apiStatInfo)}return true
}
调用方式如下:
func main() {alert := CreateAlert(new(AlertRules), new(Notification))alert.Check("test", 20, 20)//版本2,alert其实已经不需要有成员变量AlertRules和Notification了a := new(AlertRules)n := new(Notification)alert.AddHanler(CreateTPSAlertHandler(a, n))alert.AddHanler(CreateErrAlertHandler(a, n))alert.AddHanler(CreateTimeOutAlertHandler(a, n))apiStatInfo := ApiStatInfo{api: "test",timeoutCount: 20,errCount: 20,tps: 20,}alert.CheckNew(apiStatInfo)
}
这样今后无论增加多少报警指标,只需要创建新的Handler类,放入到alert中即可。代码改动量极小,而且不需要重复测试。
系统还有许多改动点,大家可以自己尝试去改动一下,所有代码位置:https://github.com/shidawuhen/asap/blob/master/controller/design/3principle.go
里式替换原则
理解原则
里氏替换原则(LSP):子类对象能够替换程序(program)中父类对象出现的任何地方,并且保证原来程序的逻辑行为(behavior)不变及正确性不被破坏。
多态与里氏替换原则的区别:多态是面向对象编程的一大特性,也是面向对象编程语言的一种语法。它是一种代码实现的思路。而里式替换是一种设计原则,是用来指导继承关系中子类该如何设计的,子类的设计要保证在替换父类的时候,不改变原有程序的逻辑以及不破坏原有程序的正确性。
实施
里式替换原则不仅仅是说子类可以替换父类,它有更深层的含义。
子类在设计的时候,要遵守父类的行为约定(或者叫协议)。父类定义了函数的行为约定,那子类可以改变函数的内部实现逻辑,但不能改变函数原有的行为约定。这里的行为约定包括:函数声明要实现的功能;对输入、输出、异常的约定;甚至包括注释中所罗列的任何特殊说明。所以我们可以通过几个点判断是否违反里氏替换原则:
- 子类违背父类声明要实现的功能:如排序函数,父类按照金额排序,子类按照时间排序
- 子类违背父类对输入、输出、异常的约定
- 子类违背父类注释中所罗列的任何特殊说明
实例
里氏替换原则可以提高代码可扩展性。假设我们需要做一个发送信息的功能,最初只需要发送站内信。
type Message struct {}
func (message *Message) Send() {fmt.Println("message send")
}
func LetDo(notify *Message) {notify.Send()
}
func main() {LetDo(new(Message))
}
实现完成后,许多地方都调用LetDo发送信息。后面想用SMS替换站内信,处理起来就很麻烦了。所以最好的方案是使用里氏替换原则,丝毫不影响新的通知方法接入。
//里氏替换原则
type Notify interface {Send()
}
type Message struct {}func (message *Message) Send() {fmt.Println("message send")
}type SMS struct {}func (sms *SMS) Send() {fmt.Println("sms send")
}func LetDo(notify Notify) {notify.Send()
}func main() {//里氏替换原则LetDo(new(Message))
}
接口隔离原则
理解原则
接口隔离原则(ISP):客户端不应该强迫依赖它不需要的接口
接口隔离原则与单一职责原则的区别:单一职责原则针对的是模块、类、接口的设计。接口隔离原则提供了一种判断接口的职责是否单一的标准:通过调用者如何使用接口来间接地判定。如果调用者只使用部分接口或接口的部分功能,那接口的设计就不够职责单一。
实施
如果把“接口”理解为一组接口集合,可以是某个微服务的接口,也可以是某个类库的接口等。如果部分接口只被部分调用者使用,我们就需要将这部分接口隔离出来,单独给这部分调用者使用,而不强迫其他调用者也依赖这部分不会被用到的接口。
如果把“接口”理解为单个API接口或函数,部分调用者只需要函数中的部分功能,那我们就需要把函数拆分成粒度更细的多个函数,让调用者只依赖它需要的那个细粒度函数。
如果把“接口”理解为OOP中的接口,也可以理解为面向对象编程语言中的接口语法。那接口的设计要尽量单一,不要让接口的实现类和调用者,依赖不需要的接口函数。
实例
假设项目用到三个外部系统:Redis、MySQL、Kafka。其中Redis和Kafaka支持配置热更新。MySQL和Redis有显示监控功能。对于这个需求,我们需要怎么设计接口?
一种方式是将所有功能放到一个接口中,另一种方式是将这两个功能放到不同的接口中。下面的代码按照接口隔离原则编写:
//接口隔离原则
type Updater interface {Update() bool
}type Shower interface {Show() string
}type RedisConfig struct {}func (redisConfig *RedisConfig) Connect() {fmt.Println("I am Redis")
}func (redisConfig *RedisConfig) Update() bool {fmt.Println("Redis Update")return true
}func (redisConfig *RedisConfig) Show() string {fmt.Println("Redis Show")return "Redis Show"
}type MySQLConfig struct {}func (mySQLConfig *MySQLConfig) Connect() {fmt.Println("I am MySQL")
}func (mySQLConfig *MySQLConfig) Show() string {fmt.Println("MySQL Show")return "MySQL Show"
}type KafkaConfig struct {}func (kafkaConfig *KafkaConfig) Connect() {fmt.Println("I am Kafka")
}func (kafkaConfig *KafkaConfig) Update() bool {fmt.Println("Kafka Update")return true
}func ScheduleUpdater(updater Updater) bool {return updater.Update()
}
func ServerShow(shower Shower) string {return shower.Show()
}func main() {//接口隔离原则fmt.Println("接口隔离原则")ScheduleUpdater(new(RedisConfig))ScheduleUpdater(new(KafkaConfig))ServerShow(new(RedisConfig))ServerShow(new(MySQLConfig))
}
这种方案比起将Update和Show放在一个interface中有如下好处:
- 不需要做无用功。MySQL不需要写热更新函数,Kafka不需要写监控显示函数
- 复用性、扩展性好。如果接入新的系统,只需要监控显示函数,只需要实现Shower接口,就能复用ServerShow的功能。
依赖倒转原则
理解原则
依赖倒转原则(DIP):高层模块不要依赖低层模块。高层模块和低层模块应该通过抽象(abstractions)来互相依赖。除此之外,抽象(abstractions)不要依赖具体实现细节(details),具体实现细节(details)依赖抽象(abstractions)。
实施
在程序代码中传递参数时或在关联关系中,尽量引用层次高的抽象层类,即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明,以及数据类型的转换等,而不要用具体类来做这些事情。核心思想是:要面向接口编程,不要面向实现编程。
实践
这个可以直接用里式替换中的例子来讲解。LetDo就使用了依赖倒转原则,提高了代码的扩展性,可以灵活地替换依赖的类。
迪米特法则
理解原则
迪米特法则(LOD):不该有直接依赖关系的类之间,不要有依赖;有依赖关系的类之间,尽量只依赖必要的接口
实施
迪米特法则主要用来实现高内聚低耦合。
高内聚:就是指相近的功能应该放到同一个类中,不相近的功能不要放到同一个类中
松耦合:在代码中,类与类之间的依赖关系简单清晰
减少类之间的耦合,让类越独立越好。每个类都应该少了解系统的其他部分。一旦发生变化,需要了解这一变化的类就会比较少。
实践
假设我们要做一个搜索引擎爬取网页的功能,功能点为
- 发起请求
- 下载网页
- 分析网页
所以我们设置三个类NetworkTransporter负责底层网络、用于获取数据,HtmlDownloader下载网页,Document用于分析网页。下面是符合迪米特法则的代码
//迪米特法则
type Transporter interface {Send(address string, data string) bool
}
type NetworkTransporter struct {}func (networkTransporter *NetworkTransporter) Send(address string, data string) bool {fmt.Println("NetworkTransporter Send")return true
}type HtmlDownloader struct {transPorter Transporter
}func CreateHtmlDownloader(t Transporter) *HtmlDownloader {return &HtmlDownloader{transPorter: t}
}func (htmlDownloader *HtmlDownloader) DownloadHtml() string {htmlDownloader.transPorter.Send("123", "test")return "htmDownloader"
}type Document struct {html string
}func (document *Document) SetHtml(html string) {document.html = html
}func (document *Document) Analyse() {fmt.Println("document analyse " + document.html)
}func main() {//迪米特法则fmt.Println("迪米特法则")htmlDownloader := CreateHtmlDownloader(new(NetworkTransporter))html := htmlDownloader.DownloadHtml()doc := new(Document)doc.SetHtml(html)doc.Analyse()
}
这种写法可以对应迪米特法则的两部分
- 不该有直接依赖关系的类之间,不要有依赖。Document不需要依赖HtmlDownloader,Document作用是分析网页,怎么得到网页是不需要关心的。这样做的好处是无论HtmlDownloader怎么变动,Document都不需要关心。
- 有依赖关系的类之间,尽量只依赖必要的接口。HtmlDownloader下载网页必须依赖NetworkTransporter,此处使用接口是为将来如果有更好的底层网络功能,可以迅速替换。当然,此处有点过渡设计的感觉,主要为了契合一下迪米特法则。具体是否需要这么设计,还是根据具体情况来判断。
总结
终于写完了这6个原则,不过对我的好处也很明显,重新梳理知识结构,对原则的理解也更深了一步。宏观上看,这些原则都是为了实现可复用、可扩展、高内聚、低耦合的目的。现在大家在掌握了Go面向对象语法、如何做面向对象分析与设计、面向对象设计原则的基础上,可以做一些面向对象的事情了。
原则是道,设计模式是术,后面会写一些设计模式相关的内容。
本文所有代码位置为:https://github.com/shidawuhen/asap/blob/master/controller/design/3principle.go
资料
- 设计模式-golang实现之七大设计原则
- 设计模式之美
最后
大家如果喜欢我的文章,可以关注我的公众号(程序员麻辣烫)
我的个人博客为:https://shidawuhen.github.io/
往期文章回顾:
技术
- Go设计模式(3)-设计原则
- Go设计模式(2)-面向对象分析与设计
- 支付接入常规问题
- HTTP2.0基础教程
- Go设计模式(1)-语法
- MySQL开发规范
- HTTPS配置实战
- Go通道实现原理
- Go定时器实现原理
- HTTPS连接过程
- 限流实现2
- 秒杀系统
- 分布式系统与一致性协议
- 微服务之服务框架和注册中心
- Beego框架使用
- 浅谈微服务
- TCP性能优化
- 限流实现1
- Redis实现分布式锁
- Golang源码BUG追查
- 事务原子性、一致性、持久性的实现原理
- CDN请求过程详解
- 常用缓存技巧
- 如何高效对接第三方支付
- Gin框架简洁版
- InnoDB锁与事务简析
- 算法总结
读书笔记
- 原则
- 资治通鉴
- 敏捷革命
- 如何锻炼自己的记忆力
- 简单的逻辑学-读后感
- 热风-读后感
- 论语-读后感
- 孙子兵法-读后感
思考
- 服务端团队假期值班方案
- 项目流程管理
- 对项目管理的一些看法
- 对产品经理的一些思考
- 关于程序员职业发展的思考
- 关于代码review的思考
- Markdown编辑器推荐-typora
Go设计模式(3)-设计原则相关推荐
- 设计一个矩形类rectangle_万字长文带你捋清六种设计模式的设计原则(建议收藏)...
对于设计模式,自己很早之前就看了好多本设计模式书籍,其中一些还看了好几遍,也一直希望自己能在编码的时候把这些设计模式用上去.可是,在日常的打码中,用的最多的就是单例,其次是观察者和建造者模式 ( bu ...
- 设计模式 - 七大设计原则(一)
设计模式 - 七大设计原则(一) 概述 简单介绍一下七大设计原则: 开闭原则:是所有面向对象设计的核心,对扩展开放,对修改关闭 依赖倒置原则:针对接口编程,依赖于抽象而不依赖于具体 单一职责原则:一个 ...
- 【设计模式】设计原则
[设计模式]设计原则 在软件开发中,为了提高软件系统的可维护性和可复用性,增加软件的可扩展性和灵活性,程序员要尽量根据6条原则来开发程序,从而提高软件开发效率.节约软件开发成本和维护成本. 1 开闭原 ...
- 设计模式-六大设计原则(附加实际开发建议以及计算器例子)
使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性.设计模式使代码编制真正工程化,是软件工程的基石脉络,如同大厦的结构一样. 文章结构: 1.单一职责原则(SRP): 2.里氏替换原 ...
- Java设计模式-七大设计原则
Java设计模式 设计模式七大原则 设计模式的目的 编写软件过程中,程序员面临着来自 耦合性,内聚性以及可维护性,可扩展性,重用性,灵活性 等多方面的挑战,设计模式是为了让程序(软件),具有更好 代码 ...
- 后端学习 - 设计模式与设计原则
文章目录 设计原则 1 单一职责原则 2 开闭原则 3 Liskov 替换原则 4 依赖倒置原则 5 接口隔离原则 6 迪米特法则 设计模式:创建型模式 1 工厂模式 2 抽象工厂模式 3 单例模式 ...
- systemverilog硬件设计及建模_UVM方法学与设计模式(一):从OOP的本质,设计模式到设计原则...
面向对象编程(OOP)是业界使用非常广泛的一种编程范式.以C++的OOP为例,其包含通常我们所说的OOP三大要素:继承.封装和多态. C++ OOP 组成 C++的OOP内容相对来说比SystemVe ...
- 设计模式与设计原则 —— 一句话
一.设计原则 二.设计模式 范围\目的 创建型模式 结构型模式 行为型模式 类模式 工厂方法 (类)适配器 模板方法.解释器 对象模式 单例 原型 抽象工厂 建造者 代理 (对象)适配器 桥接 装饰 ...
- 设计模式七大设计原则
文章目录 1.什么是设计模式 2.单一职责原则 3.开闭原则 4.接口隔离原则 5.依赖倒置原则 6.迪米特法则(最少知道原则) 7.里式替换原则 8.组合优于继承 设计模式主要是为了满足一个字 变, ...
最新文章
- 情感分析:基于循环神经网络
- 在程序中集成地址簿、电子邮件和地图功能
- 【GAN优化】长文综述解读如何定量评价生成对抗网络(GAN)
- [华为机试练习题]5.IP地址推断有效性
- SAP C4C里没有选择Port binding的url Mashup行为分析
- MS SQL Server中的CONVERT日期格式化大全
- 《操作系统知识点整理》
- 软键盘弹起,导致底部被顶上去
- DataTables—服务器端翻页
- 企业千人千面管理模式_一汽解放青岛汽车有限公司荣获“2020(第十六届)中国企业教育先进单位百强”...
- 4.8 定位一组元素
- ambari 2.7 下安装httpfs
- 工控网络安全分支-电力行业网络安全建设
- python中θ符号怎么打出来_Python打印特殊符号及对应编码解析
- Python安装过程中出现“找不到指定的路径”的解决办法
- 重庆php就业前景,重庆就业前景最好的十大专业是哪些_中职中专网
- 2015美国大学计算机科学专业排名,2015年US News美国大学计算机专业排名
- kill命令详解kill -9、kill -15区别
- ctfshow SSRF web351-web360 wp
- 《脱颖而出——成功网店经营之道》一2.2 进货攻略
热门文章
- Neovim 打造 Java IDE
- Axure原型的设计规范(更新中)
- surface 哪个系列适合java开发,微软Surface系列有这么多,我到底该选哪台才好?...
- 技术流风格的PPT要怎样制作设计?
- 加拿大访问学者家属如何办理探亲签证?
- adams2015怎么把工具栏打开_剪映怎么玩的更好?教你0基础也能秒会的剪映三大进阶级功能!...
- ADAMS基础到测量 后处理 参数优化设计视频教程
- 【微信小程序系列】微信小程序连接后端数据库(SSM)案例
- 微信公众号运营 新手必知的五大运营攻略
- 微信小程序git开发步骤和注意事项