zhangbeizhen 2019-06-27
装饰模式是在不必改变原类文件和使用继承的情况下,动态地扩展一个对象的功能。它是 通过创建一个包装对象,也就是装饰来包裹真实的对象。
1 装饰对象和真实对象有相同的接口。这样客户端对象就能以和真实对象相同的方式和装饰对 象交互。 2 装饰对象包含一个真实对象的引用(reference) 3 装饰对象接受所有来自客户端的请求。它把这些请求转发给真实的对象。 4 装饰对象可以在转发这些请求以前或以后增加一些附加功能。这样就确保了在运行时,不用 修改给定对象的结构就可以在外部增加附加的功能。在面向对象的设计中,通常是通过继承 来实现对给定类的功能扩展。
1. 需要扩展一个类的功能,或给一个类添加附加职责。 2. 需要动态的给一个对象添加功能,这些功能可以再动态的撤销。 3. 需要增加由一些基本功能的排列组合而产生的非常大量的功能,从而使继承关系变的不现 实。 4. 当不能采用生成子类的方法进行扩充时。一种情况是,可能有大量独立的扩展,为支持每 一种组合将产生大量的子类,使得子类数目呈爆炸性增长。另一种情况可能是因为类定义 被隐藏,或类定义不能用于生成子类。
1. Decorator模式与继承关系的目的都是要扩展对象的功能,但是Decorator可以提供比继 承更多的灵活性。 2. 通过使用不同的具体装饰类以及这些装饰类的排列组合,设计师可以创造出很多不同行为 的组合。
1. 这种比继承更加灵活机动的特性,也同时意味着更加多的复杂性。 2. 装饰模式会导致设计中出现许多小类,如果过度使用,会使程序变得很复杂。 3. 装饰模式是针对抽象组件(Component)类型编程。但是,如果你要针对具体组件编程时, 就应该重新思考你的应用架构,以及装饰者是否合适。当然也可以改变Component接口, 增加新的公开的行为,实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。
1. 如果只有一个Concrete Component类而没有抽象的Component接口时,可以让Decorator 继承Concrete Component。 2. 如果只有一个Concrete Decorator类时,可以将Decorator和Concrete Decorator合 并。
在图中,cachey这个接口类,被所有类实现了 这里有一个比较特别的类----PerpetualCache.class
由于类太多,这里只晒三个类结构图
这样,大概大家都对这几个类和装饰器了解了吧。
在mybatis中缓存的功能由接口Cache类定义,使用了装饰器设计模式,存储和缓存的功能由 PerpetualCache类实现,然后通过其他的装饰器来对PerpetualCache类进行缓存策略控制。 如上图,可以这样理解,PerpetualCache是基类,其它实现的Cache的类都是对基类的扩 展,也就是装饰来包裹真实的对象。 扩展了类的功能,也可以说是附加了一些方法。使得具有很好的灵活性。
1. FifoCache:先进先出算法,缓存回收策略 2. LoggingCache:输出缓存命中的日志信息 3. LruCache:最近最少使用算法,缓存回收策略 4. ScheduledCache:调度缓存,负责定时清空缓存 5. SerializedCache:缓存序列化和反序列化存储 6. SoftCache:基于软引用实现的缓存管理策略 7. SynchronizedCache:同步的缓存装饰器,用于防止多线程并发访问 8. WeakCache:基于弱引用实现的缓存管理策略
mybatis缓存同样分为一级缓存和二级缓存:
二级缓存对象的默认类型为PerpetualCache,如果配置的缓存是默认类型,则mybatis 会根据配置自动追加一系列装饰器。
Cache对象之间的引用顺序为:
SynchronizedCache–>LoggingCache–>SerializedCache–>ScheduledCache–>LruCache–>PerpetualCache
mybatis源码 ------https://gitee.com/SmileSnake/...
参数资料
装饰器模式概念
如果有侵权,马上删除