大战设计模式（第二季）【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 

 转载请注明出处