Fork me on GitHub

大战设计模式(第二季)【4】———— 从源码看装饰者模式

前言

装饰者模式在实际中应用也很多,装饰比继承要灵活,但是同时装饰的过多也会导致业务上面看上去难以理解,所以合理的使用很重要。对于装饰者模式来说还有一个比较重要的点就是抽象,抽象出来的内容很重要,决定了后续装饰的难度。

装饰模式基础:https://www.cnblogs.com/linkstar/p/7637675.html

 

从BufferedReader来看

我们知道在jdk中有一个Reader和BufferedReader,BufferedReader是一个缓冲的输入流,每次读取一部分到缓冲中;操作完缓冲中的这部分数据之后,再从Reader中读取下一部分的数据。
BufferedReader就是Reader的一个装饰者


可以看到,很明显BufferedReader的构造方法中传入一个Reader,内部有一个私有的Reader,装饰之后返回出去。

 

从spring的TransactionAwareCacheDecorator来看


从结构和命名上面已经很明显看出装饰者模式了,我们来说说他具体是怎么用的。
TransactionAwareCacheDecorator是处理spring有事务的时候缓存的类,我们在使用spring的cache注解实现缓存的时候,当出现事务的时候,那么缓存的同步性就需要做相应的处理了,于是就有了这个装饰者。
我们可以看到下面的方法中:增加了对事务的支持,在事务提交、回滚的时候分别对Cache的数据进行处理,来实现目的。

具体细节就不详细说明了,有兴趣的小伙伴可以往下看。这里主要说明,装饰者模式在这里的意义。因为并非所有的方法都会使用事务,有的普通方法就不需要装饰,有的就需要,所以就使用了装饰者来完成。

 

从MyBatis中看装饰者

上面我们看的spring中有缓存,然后对缓存做了装饰,那我们同样就能想到MyBatis中也有缓存,是不是也存在这样的模式呢?果然也是。

看的这里我们就明白了,MyBatis对Cache的装饰更多,有各种各样的装饰者。
这里简单先说一下MyBatis的缓存,默认情况下是没有开启缓存的,很多人也可能从来没用到缓存,如果要开启缓存需要使用标签
<cache
eviction="FIFO"
flushInterval="60000"
size="512"
readOnly="true"/>
这个配置创建了一个 FIFO 缓存,并每隔 60 秒刷新,存数结果对象或列表的 512 个引用,而且返回的对象被认为是只读的,因此在不同线程中的调用者之间修改它们会 导致冲突。
其中缓存的策略FIFO就是为什么有这么多装饰者的原因了,不同的装饰者对应了不同的缓存策略。

 

总结

装饰者模式的核心就是,装饰者继承实现抽象的产品,并在内部私有一个产品,利用构造方法对传入的产品进行装饰,返回装饰后的产品。

 

 

 

 

作者:LinkinStar
转载请注明出处
全部分类请看:https://www.cnblogs.com/linkstar/category/1087887.html

 

posted @   LinkinStar  阅读(586)  评论(0编辑  收藏  举报
编辑推荐:
· go语言实现终端里的倒计时
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
阅读排行:
· 周边上新:园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源!
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器
· DeepSeek如何颠覆传统软件测试?测试工程师会被淘汰吗?
点击右上角即可分享
微信分享提示