读书就是赚钱

模版方法设计模式

golang策略模式的实现

场景老板:我们现在要开发一个文档系统,支持多种模式,在预览模式下只支持预览操作.编辑模式下,支持增删改查操作,你有什么好的方案你:好的老板,那就使用状态模式方案状态模式:我们通过状态对象封装了对上下文的动作.用不同的状态对象维护着对上下文对象操作的不同实现,达到可以横向扩展的效果.在这个例子中,我们把文档系统当成如图所示的上下文,里面维护几个不同的状态,预览状态、编辑状态,再把我们的增删改查的动作封装到这些状态里面,通过上下文对象去使用它们.以后我们如果要扩张其他的模式,增加一个状态即可.

场景老板:我们现在想要做一个监控系统,去监控一个对象的状态变化,设计一个方案你:好的老板,那就是使用观察者模式方案观察者模式,顾名思义就是用一些对象去观察另一些对象的行为.在这个设计模式中,观察方法是通过“主动”通知的形式.即在 被观察者 的对象中注册一批观察者,当 被观察者 自身的状态发生变化的时候,主动去通知观察者,并把自身的引用或者某些状态信息传递给观察者完成整个通知流程.观察者拿到目标对象的状态信息后就可以做相关的事宜.用聚合的方式解耦掉观察者与被观察者两者的逻辑.常用与监控,或者是

场景老板:对我们的现有记录做存档，后面可以恢复,设计一个代码的方案你:好的,老板.那就是使用备忘录模式方案备忘录模式,指的是用一个备忘录对象来记录原始对象的内部状态信息.原始对象利用备忘录对象对自己的属性做一次存档,然后可以通过这个备忘录对象对自己的属性做回滚.备忘录对象没有任何的功能,只是充当一个数据记录的作用.当然有人会说我们也可以通过深拷贝一个原始对象来做存档,但这样的话可能会导致这个克隆对象被误用.把存档的功能单独抽离出来是最好的,我也可以在原始对象的内部维护这个备忘录对象,这样就不会

场景老板:如果我们现在要实现一个群通知功能,群中的所有成员都能通知其他人,你觉得用什么设计模式比较好你:好的老板,那就使用中介模式方案中介模式,指的是用一个对象来封装一批成员对象,并暴露同一的接口,这个接口可以对这些成员对象施加一些动作.就如它的名称一样,像一个中介代理着他的成员对象去做一些事情,当然了,真正动手的是被他代理的实例.在这个场景中,我们用中介模式来代理被代理实例的功能,我们建立一个中间者,然后向中介者发一起一起群通知,然后中介者帮我们向所有注册的成员发起通知,这样就可以完成我们

场景老板:现在有一个对象拥有一个私有的属性,是一个列表.设计一个方案,在列表指针不暴露出去的情况下让这个列表能被迭代访问你:好的老板,那就使用迭代器模式方案迭代器模式,指的是用对象来封装访问一个列表的行为,其效果与for循环是一样的,但是保护了真正的列表可以不被外界访问,又能访问到列表的真正内容.在Java中我们也很经常用迭代器来做操作,像常用的List,Set,Map都可以通过那个对象创建一个迭代器对象,但是在golang中却没有,所以golang入门的同学了解这知识点可能比较陌生,下面我们

场景老板:现在我们要实现自己的一套规则引擎,解释自定义的语法,你有什么好的方案你:好的老板,那就是使用解释器模式方案解释器模式,用一波对象封装了对某种语法解析过程的实现.在这个设计模式中,使用统一的解释器接口规范了解释器的行为.使用不同的解释器实现不同的语法解析.除此之外,在这个模式中,还引入了上下文对象这个概念,是因为我们在对语法解析的过程不是某个对象一次就能处理完,所以引入了上下文对象去缓存处理过程中暂存数据,结果等.看的设计模式越多觉得每个模式越像,都是利用了对象之间的组合,依赖倒置来

场景老板:我们有一个业务的组件实现是第三方,他们暴露的接口非常细粒度,我们要根据不同的接口组成一个指令,并且指令能复用,你有什么好的方案你:好的,老板,那就使用命令模式方案命令模式,就是利用一些实现同一接口的对象对真正的业务对象行为进行封装,成为一个可以复用的、另外组合的实现方式.如图所示,我们可以针对某一个业务对象定义一个命令接口,再创造不同的命令实现,在这些命令实现中,每个都聚合了真正的业务对象,通过实现接口方法,完成对业务对象行为的封装.所以能达到场景的要求.命令模式看起来很像外观模式

场景老板:最近在开发工作流,里面涉及一个逐级审批的场景,你有什么好方案你:好的老板,那就是使用责任链模式方案责任链模式,实现同一接口的不同对象通过聚合聚合在一起,在逻辑处理过程中,可自行选择是否交给上一级进行处理.像链条的每一个节点一样,一环扣一环,可以在某一环进行断路控制非法参数或者直接完成流程,或从头到尾做完全部处理再走下一步逻辑,类似过滤链的逻辑.在类似这个逐层审批的场景中,每一层级的审批就是责任链中的节点,我们可以在节点中进行逻辑判断,直接审批、拒绝、或者向上一级汇报.还可以很轻松的增

场景老板:如何不动声色的在一个对象干活的时候做些其他事情,比如监控他的启动,收集他的完成情况等等你:好的老板,那就使用代理模式方案代理模式,即创建一个代理类,将真正实现服务的对象聚合在其内部,然后暴露接口让真正的对象去干活,这时,便可以真正对象干活的前置后置做一些事情,可以做监控,采集日志等一系列东西.代理模式也是才用聚合代替继承的方法来给对象增加能力,有很好的扩展性.感觉设计模式研究多了,几乎都是面向接口编程,用聚合代替继承,也是跟go语言设计的初衷一致.用go来玩设计模式实在是泰简单了.

场景老板:我们系统中会重复使用一个不可变的类对象,想个办法,让整个系统都使用这同一个对象你:好的老板,那就是使用蝇量模式方案蝇量模式也称为享元模式,如名字说的一样,就是系统里面不同场景使用某个不可变对象时,都使用那同一个对象.这里强调不可变,是因为整个对象会被全局使用,所以他的状态不能被外部所改变.使用一个蝇量工厂,工厂缓存着蝇量对象,每当客户端需要使用的时候,直接返回缓存中的那个对象.看起来跟之前说过的单例模式非常相似,是的,单例模式也是一个享元模式.实现see:https://gith

场景老板:想个办法,封装一套复杂的流程,给一个接口方便对接的厂商调用你:好的,老板,那就是使用外观模式方案外观模式也称为门面模式,通过组合或聚合的方式继承一个和多个对象,封装调用这些对象的复杂流程,暴露出去一个简单的接口给使用者调用.这个模式常常用于openapi的场景,很好的解决了对于复杂流程的封装问题实现see:https://github.com/jjtHappy/design-pattern-so-simplepackage mainimport "fmt"type Co

场景老板:考虑一下,如何在不改动代码的情况下,给一个现有的类增加功能你:好的,老板那就使用装饰者模式方案装饰者模式是通过组合的方法给某个类增加能力的一种设计模式,通过与目标继承同一个接口,并组合目标类对象,将装饰者自己打造成为一个升级版的目标类.在这样的扩展下,做到开闭原则,能在不改变原有代码的情况下给某个类增加能力.实现see:https://github.com/jjtHappy/design-pattern-so-simplepackage mainimport "fmt"

场景老板:让你做一个组织架构的实现,怎么实现可扩展性最高?你:好的老板,那就是使用组合模式方案组合模式,指的是就是用接口做抽象,在这个接口内部组合自己,形成一个树型结构.像组织架构,课表,等等可以形成树状的实体,都可以用组合模式来做一个实现,这样我们可以不断的演化节点类型而对总体的节点不用修改,不断的扩展这棵树的体积而不用动旧代码实现see:https://github.com/jjtHappy/design-pattern-so-simplepackage mainimport

场景老板:一直听你说面向接口编程,那你举一个设计模式告诉我什么叫tm的面向接口编程你:好的老板,那就使用桥接模式方案桥接模式就是面向接口编程的最好体现.桥接模式就是自己创建一个所谓的桥接器,这个桥接器里面有一个属性是一个接口类型的,这个桥接器不维护接口的实现,而是open一个方法,让桥接器的使用者把实现传递给它,然后桥接器用这个真正的接口实现去干活.桥接器就是面向接口编程,通过接口嫁接任意的实现,达到可扩展的效果.假如当前的实现不满足要求,那么随时随地增加实现去扩展.实现see:htt

场景老板:现在有一个遗留的接口跟一个现存的类,这个类没有实现这个接口,在不改动原来代码的情况下想个法子让这个类具备这个接口的功能你:好的老板,那就使用适配器模式方案在这个场景下我们可以使用适配器模式来解决这个问题.我们通过增加一个适配器去实现目标接口,并传递现存的那个类给它,由这个适配器来适配这个类的接口功能.采用适配器,我们可以在不变动原来代码的情况下,增加某个类的功能(即被动实现某个接口,在适配器中编写适配逻辑).这里建议使用聚合的方式来让适配器拥有任意类的功能.在Go中没有继承,所以

场景老板:现在咱们要搞个单例,整个系统跑起来就只能有一个对象,实现吧你:好的老板,那就使用单例模式.方案我们使用单例设计模式可以解决这个问题.单例指的就是在某个类的内部维护自己一个对象实例,并只能通过单一接口暴露出去.一般我们实现单例可以用饿汉模式和懒汉模式.说白了就是先创建好对象等待着,还是等你要的时候我再给你创建.两个方式都可以实现,唯一的区别是在实现懒汉的时候要考虑并发性的问题.单例的作用场景一般是用在全局只用一个对象的场合,比如我们手机打开一个APP,这个进程就是一个单例,下次点击

场景老板:我们要大规模生产一种产品,每个产品的规模大小都是一模一样的,实现吧你:好的,那就使用原型(蝇量)模式方案我们使用原型模式,通过拷贝的方法,拷贝一个对象自身的属性,产生一个一摸一样的自己来满足这个需求.注意:一般我们说的拷贝分深拷贝跟浅拷贝,也就是所谓的值拷贝和指针拷贝.Golang天生就是一个中意值拷贝的语言,只要你不刻意去使用指针,那么就是一个值拷贝参数传递模式.实现see:https://github.com/jjtHappy/design-pattern-so-simpl

场景老板:生产一类复杂的产品,这些产品有同样的生产规模,都需要经过N道复杂工序制作.不同产品的工序处理方式可能有些区别,以后可能还会有这样的产品出来,设计一个做产品的方案吧你:好的老板,那就使用建造者模式方案1.考虑产品的生产工序复杂,所以我们可以把生产产品的过程封在建造者内部.对每一道步骤定义为一个方法,由客户自行调用完成.注意其实这里还可以多一个所谓的指导者角色,就是指导生产产品的过程.2.多种产品的规模相同,但是工序不同,所以可以用抽象对具体产品做抽象3.对待不同的产品需要不同的建造者

场景老板:设计一个万能工厂,目前可以生产产品A跟B,以后可能要生产C,D…这些产品都属于同一个产品族你:好的老板,那就使用抽象工厂模式方案产品会随时间推移而增加,这些产品的属性相似,我们可以称为他们是一个产品族,我们使用一个抽象工厂(即能生产同一产品族的万能工厂)解决这个问题,这样我们的代码就可以无限扩展实现see:githubpackage mainimport "fmt"type Product stringtype AbstractFactory interface {

场景老板:“设计一个让工厂生产产品的场景,现在目前有工厂A生产A跟工厂B生产B,未来可能还有C跟D,写代码吧”你:“好的,工厂模式可以搞定”方案工厂跟产品都会随时间推移进行增加,所以我们可以用接口跟抽象类来描述工厂跟产品,通过具体的实现来表示每一个不同的工厂跟产品,这样我们的代码就可以无限扩展实现package mainimport "fmt"//工厂接口type AbstractFactory interface { Produce() AbstractProduct}