手记

大战设计模式(第二季)【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/p/10460003.html 

 转载请注明出处


0人推荐
随时随地看视频
慕课网APP