个人主页:金鳞踏雨
个人简介:大家好,我是金鳞,一个初出茅庐的Java小白
目前状况:22届普通本科毕业生,几经波折了,现在任职于一家国内大型知名日化公司,从事Java开发工作
我的博客:这里是CSDN,是我学习技术,总结知识的地方。希望和各位大佬交流,共同进步 ~
使用组合替代继承,对原生对象的方法做增强,增加新的行为和能力。
一、实现原理
装饰器设计模式(Decorator)是一种结构型设计模式,它允许动态地为对象添加新的行为。它通过创建一个包装器来实现,即将对象放入一个装饰器类中,再将装饰器类放入另一个装饰器类中,以此类推,形成一条包装链。
在不改变原有对象的情况下,动态地添加新的行为或修改原有行为。
代码实现
1、定义一个接口或抽象类,作为被装饰对象的基类。
public interface Component {
void operation();
}
在这个示例中,我们定义了一个名为 Component 的接口,它包含一个名为 operation 的抽象方法,用于定义被装饰对象的基本行为。
2、定义一个具体的被装饰对象,实现基类中的方法。
public class ConcreteComponent implements Component {
@Override
public void operation() {
System.out.println("ConcreteComponent is doing something...");
}
}
在这个示例中,我们定义了一个名为 ConcreteComponent 的具体实现类,实现了 Component 接口中的 operation 方法。
3、定义一个抽象装饰器类,继承基类,并将被装饰对象作为属性。
public abstract class Decorator implements Component {
// 装饰器设计模式 使用组合的形式进行装饰
protected Component component;
public Decorator(Component component) {
this.component = component;
}
@Override
public void operation() {
component.operation();
}
}
在这个示例中,我们定义了一个名为 Decorator 的抽象类,继承了 Component 接口,并将被装饰对象作为属性。在 operation 方法中,我们调用被装饰对象的同名方法。
4、定义具体的装饰器类,继承抽象装饰器类,并实现增强逻辑。
public class ConcreteDecoratorA extends Decorator {
public ConcreteDecoratorA(Component component) {
System.out.println("这是第一次包装...");
super(component);
}
@Override
public void operation() {
super.operation();
System.out.println("ConcreteDecoratorA is adding new behavior...");
}
}
public class ConcreteDecoratorB extends Decorator {
public ConcreteDecoratorB(Component component) {
System.out.println("这是第二次包装...");
super(component);
}
@Override
public void operation() {
super.operation();
System.out.println("ConcreteDecoratorB is adding new behavior...");
}
}
在这个示例中,我们定义了一个名为 ConcreteDecoratorA 的具体装饰器类,继承了 Decorator 抽象类,并实现了 operation 方法的增强逻辑。在 operation 方法中,我们先调用被装饰对象的同名方法,然后添加新的行为。
5、使用装饰器增强被装饰对象。
public class Main {
public static void main(String[] args) {
Component component = new ConcreteComponent();
// 进行第一次包装
component = new ConcreteDecoratorA(component);
// 进行第二次包装
component = new ConcreteDecoratorB(component);
component.operation();
}
}
在这个示例中,我们先创建了一个被装饰对象 ConcreteComponent,然后通过 ConcreteDecoratorA 类创建了一个装饰器,并将被装饰对象作为参数传入。最后,调用装饰器的 operation 方法,这样就可以实现对被装饰对象的增强。
装饰器设计模式,包装后可以继续包装...类似于套娃。一层一层,逐步增强!!!
装饰器与静态代理的区别
装饰器模式和静态代理模式最大的区别——目的不同!
代理模式的目的是为了控制对对象的访问,它在对象的外部提供一个代理对象来控制对原始对象的访问。代理对象和原始对象通常实现同一个接口或继承同一个类,以保证二者可以互相替代。
装饰器模式的目的是为了动态地增强对象的功能,它在对象的内部通过一种包装器的方式来实现。装饰器模式中,装饰器类和被装饰对象通常实现同一个接口或继承同一个类,以保证二者可以互相替代。装饰器模式也被称为包装器模式。
需要注意的是,装饰器模式虽然可以实现动态地为对象增加行为,但是会增加系统的复杂性,因此在使用时需要仔细权衡利弊。
二、使用场景
在 Java 中,装饰器模式的应用非常广泛,特别是在 I/O 操作中。Java 中的 I/O 类库就是使用装饰器模式来实现不同的数据流之间的转换和增强的。
1.从IO库的设计理解装饰器
打开文件 test.txt,从中读取数据。
其中,InputStream 是一个抽象类,FileInputStream 是专门用来读取文件流的子类。BufferedInputStream 是一个支持带缓存功能的数据读取类,可以提高数据读取的效率
InputStream in = new FileInputStream("D:/test.txt");
InputStream bin = new BufferedInputStream(in);
byte[] data = new byte[128];
while (bin.read(data) != -1) {
//...
}
初看上面的代码,我们会觉得 Java IO 的用法比较麻烦,需要先创建一个 FileInputStream 对象,然后再传递给 BufferedInputStream 对象来使用。
为什么Java IO 为什么不设计一个继承 FileInputStream 并且支持缓存的 BufferedFileInputStream 类呢?
这样直接创建一个 BufferedFileInputStream 类对象,打开文件读取数据,用起来岂不是更加简单?
InputStream bin = new BufferedFileInputStream("/user/wangzheng/test.txt");
byte[] data = new byte[128];
while (bin.read(data) != -1) {
//...
}
(1)基于继承的设计方案(能实现,不靠谱)
如果 InputStream 只有一个子类 FileInputStream 的话,那我们在 FileInputStream 基础之上,再设计一个孙子类 BufferedFileInputStream,这样子是完全可以的,毕竟继承结构还算简单!
但实际上,继承 InputStream 的子类有很多。我们需要给每一个 InputStream 的子类,再继续派生支持缓存读取的子类。
除了支持缓存读取之外,如果我们还需要对功能进行其他方面的增强,比如下面的 DataInputStream 类,支持按照基本数据类型(int、boolean、long 等)来读取数据。
FileInputStream in = new FileInputStream("/user/wangzheng/test.txt");
DataInputStream din = new DataInputStream(in);
int data = din.readInt();
在这种情况下,如果我们继续按照继承的方式来实现的话,就需要再继续派生出 DataFileInputStream、DataPipedInputStream 等类。如果我们还需要既支持缓存、又支持按照基本类型读取数据的类,那就要再继续派生出 BufferedDataFileInputStream、BufferedDataPipedInputStream 等 n 多类。
这还只是附加了两个增强功能,如果我们需要附加更多的增强功能,那就会导致组合爆炸,类继承结构变得无比复杂,代码既不好扩展,也不好维护。
(2)基于装饰器模式的设计方案
组合优于继承,建议使用组合来替代继承!!!
针对刚刚的继承结构过于复杂的问题,我们可以通过将继承关系改为组合关系来解决。
public abstract class InputStream {
//...
public int read(byte b[]) throws IOException {
return read(b, 0, b.length);
}
public int read(byte b[], int off, int len) throws IOException {
//...
}
public long skip(long n) throws IOException {
//...
}
public int available() throws IOException {
return 0;
}
public void close() throws IOException {}
public synchronized void mark(int readlimit) {}
public synchronized void reset() throws IOException {
throw new IOException("mark/reset not supported");
}
public boolean markSupported() {
return false;
}
}
public class BufferedInputStream extends InputStream {
protected volatile InputStream in;
protected BufferedInputStream(InputStream in) {
this.in = in;
}
//...实现基于缓存的读数据接口...
}
public class DataInputStream extends InputStream {
protected volatile InputStream in;
protected DataInputStream(InputStream in) {
this.in = in;
}
//...实现读取基本类型数据的接口
}
那装饰器模式就是简单的“用组合替代继承”吗?
当然不是!从 Java IO 的设计来看,装饰器模式相对于简单的组合关系,还有两个比较特殊的地方!
1、装饰器类和原始类继承同样的父类,这样我们可以对原始类“嵌套”多个装饰器类。
比如,下面这样一段代码,我们对 FileInputStream 嵌套了两个装饰器类:BufferedInputStream 和 DataInputStream,让它既支持缓存读取,又支持按照基本数据类型来读取数据。
// 逐次增强!
InputStream in = new FileInputStream("/user/wangzheng/test.txt");
InputStream bin = new BufferedInputStream(in);
DataInputStream din = new DataInputStream(bin);
int data = din.readInt();
2、装饰器类是对功能的增强,这也是装饰器模式应用场景的一个重要特点。
实际上,符合“组合关系”这种代码结构的设计模式有很多,比如之前讲过的代理模式,还有现在的装饰器模式。尽管它们的代码结构很相似,但是每种设计模式的意图是不同的!!!
例如,代理模式中,代理类附加的是跟原始类无关的功能,而在装饰器模式中,装饰器类附加的是跟原始类相关的增强功能。
// 代理模式的代码结构(下面的接口也可以替换成抽象类)
public interface IA {
void f();
}
public class A impelements IA {
public void f() {
//...
}
}
public class AProxy impements IA {
private IA a;
public AProxy(IA a) {
this.a = a;
}
public void f() {
// 新添加的代理逻辑
a.f();
// 新添加的代理逻辑
}
}
// 装饰器模式的代码结构(下面的接口也可以替换成抽象类)
public interface IA {
void f();
}
public class A impelements IA {
public void f() {
// ...
}
}
public class ADecorator impements IA {
private IA a;
public ADecorator(IA a) {
this.a = a;
}
public void f() {
// 功能增强代码
a.f();
// 功能增强代码
}
}
BufferedInputStream为什么不直接继承InputStream?
实际上,如果去查看 JDK 的源码,你会发现,BufferedInputStream、DataInputStream 并非继承自 InputStream,而是另外一个叫 FilterInputStream 的类。那这又是出于什么样的设计意图,才引入这样一个类呢?
InputStream 是一个抽象类而非接口,而且它的大部分函数(比如 read()、available())都有默认实现,按理来说,我们只需要在 BufferedInputStream 类中重新实现那些需要增加缓存功能的函数就可以了,其他函数继承 InputStream 的默认实现。但实际上,这样做是行不通的!
对于即便是不需要增加缓存功能的函数来说,BufferedInputStream 还是必须把它重新实现一遍,简单包裹对 InputStream 对象的函数调用;如果不重新实现,那 BufferedInputStream 类就无法将最终读取数据的任务,委托给传递进来的 InputStream 对象来完成。
public class BufferedInputStream extends InputStream {
protected volatile InputStream in;
protected BufferedInputStream(InputStream in) {
this.in = in;
}
// f()函数不需要增强,只是重新调用一下InputStream in对象的f()
public void f() {
in.f();
}
}
实际上,DataInputStream 也存在跟 BufferedInputStream 同样的问题。为了避免代码重复,Java IO 抽象出了一个装饰器父类 FilterInputStream。
InputStream 的所有的装饰器类(BufferedInputStream、DataInputStream)都继承自这个装饰器父类。这样,装饰器类只需要实现它需要增强的方法就可以了,其他方法继承装饰器父类的默认实现。
public class FilterInputStream extends InputStream {
protected volatile InputStream in;
protected FilterInputStream(InputStream in) {
this.in = in;
}
public int read() throws IOException {
return in.read();
}
public int read(byte b[]) throws IOException {
return read(b, 0, b.length);
}
public int read(byte b[], int off, int len) throws IOException {
return in.read(b, off, len);
}
public long skip(long n) throws IOException {
return in.skip(n);
}
public int available() throws IOException {
return in.available();
}
public void close() throws IOException {
in.close();
}
public synchronized void mark(int readlimit) {
in.mark(readlimit);
}
public synchronized void reset() throws IOException {
in.reset();
}
public boolean markSupported() {
return in.markSupported();
}
}
总的来说,当 BufferedInputStream 继承自 FilterInputStream 时,它可以非常轻松地扩展 FilterInputStream 的行为,从而实现了输入流的缓冲功能。如果 BufferedInputStream 直接继承自 InputStream,那么它就需要重新实现所有 InputStream 的方法,包括一些可能不需要修改的方法,这会使代码变得复杂且容易出错。
2.MyBatis的缓存设计
创建缓存的过程
useNewCache方法用于配置Mapper是否使用一个全新的缓存实例,而不共享缓存实例
public Cache useNewCache(Class<? extends Cache> typeClass,
Class<? extends Cache> evictionClass,
Long flushInterval,
Integer size,
boolean readWrite,
boolean blocking,
Properties props) {
Cache cache = new CacheBuilder(currentNamespace)
// 根据类型生成实例,并进行配置
.implementation(valueOrDefault(typeClass, PerpetualCache.class))
.addDecorator(valueOrDefault(evictionClass, LruCache.class)) // 添加装饰器
.clearInterval(flushInterval)
.size(size)
.readWrite(readWrite)
.blocking(blocking)
.properties(props)
.build();
configuration.addCache(cache);
currentCache = cache;
return cache;
}
默认的缓存如下,本质就是维护了一个简单的HashMap
public class PerpetualCache implements Cache {
private final String id;
private final Map<Object, Object> cache = new HashMap<>();
public PerpetualCache(String id) {
this.id = id;
}
@Override
public void putObject(Object key, Object value) {
cache.put(key, value);
}
@Override
public Object getObject(Object key) {
return cache.get(key);
}
// ...省略其他的简单的方法
}
缓存的构建过程
public Cache build() {
// 设置默认的cache实现,并绑定默认的淘汰策略
setDefaultImplementations();
// 利用反射创建实例
Cache cache = newBaseCacheInstance(implementation, id);
// 设置properties属性
setCacheProperties(cache);
// 不应用装饰自定义缓存,自定义缓存需要自己实现对应的特性,如淘汰策略等
// 通常情况自定义缓存有自己的独立配置,如redis、ehcache
if (PerpetualCache.class.equals(cache.getClass())) {
for (Class<? extends Cache> decorator : decorators) {
cache = newCacheDecoratorInstance(decorator, cache);
setCacheProperties(cache);
}
// 这是标准的装饰器,这里使用了装饰器设计模式
cache = setStandardDecorators(cache);
} else if (!LoggingCache.class.isAssignableFrom(cache.getClass())) {
cache = new LoggingCache(cache);
}
return cache;
}
MyBatis会使用装饰者设计模式,对默认cache进行装饰,使其具有LRU的能力
private void setDefaultImplementations() {
if (implementation == null) {
implementation = PerpetualCache.class;
if (decorators.isEmpty()) {
// decorators是成员变量,装饰器,饰器具备LRU的能力
decorators.add(LruCache.class);
}
}
}
LruCache实现如下,默认情况下的LRU算法实现是基于LinkedHashMap实现的
public class LruCache implements Cache {
// 代理目标缓存
private final Cache delegate;
private Map<Object, Object> keyMap;
private Object eldestKey;
// LruCache用来装饰默认的缓存,这里实现了缓存的高级特性
public LruCache(Cache delegate) {
this.delegate = delegate;
setSize(1024);
}
@Override
public String getId() {
return delegate.getId();
}
@Override
public int getSize() {
return delegate.getSize();
}
// 设置长度,构建一个LinkedHashMap,重写removeEldestEntry
public void setSize(final int size) {
// 第三个参数accessOrder为true,可以使LinkedHashMap维护一个【访问顺序】
// 最近被访问的数据会被放在链表的尾部,天然实现lru
keyMap = new LinkedHashMap<Object, Object>(size, .75F, true) {
private static final long serialVersionUID = 4267176411845948333L;
// 重写该方法,父类直接返回false
// 只要实际容量size() 大于 初始化容量 size 认定当前的缓存已经满了
// 该方法会在LinkedHashMap的afterNodeInsertion方法中被主动调用
// 会将头节点当作eldest删除
@Override
protected boolean removeEldestEntry(Map.Entry<Object, Object> eldest) {
boolean tooBig = size() > size;
if (tooBig) {
// 同时将这个这个key复制给成员变量eldestKey
eldestKey = eldest.getKey();
}
return tooBig;
}
};
}
// put一个缓存的过程
// 放入当前的缓存值,淘汰eldestKey
@Override
public void putObject(Object key, Object value) {
delegate.putObject(key, value);
cycleKeyList(key);
}
// get一个缓存的过程
// 获得该值,同时提升key热度,主动访问一下keyMap.get(key)
@Override
public Object getObject(Object key) {
keyMap.get(key);
return delegate.getObject(key);
}
@Override
public Object removeObject(Object key) {
return delegate.removeObject(key);
}
@Override
public void clear() {
delegate.clear();
keyMap.clear();
}
// 循环key的集合
private void cycleKeyList(Object key) {
keyMap.put(key, key);
if (eldestKey != null) {
delegate.removeObject(eldestKey);
eldestKey = null;
}
}
}
最后使用其他的装饰器对cache进行装饰,使其就有更多的能力
private Cache setStandardDecorators(Cache cache) {
try {
MetaObject metaCache = SystemMetaObject.forObject(cache);
// 设置大小,默认1024
if (size != null && metaCache.hasSetter("size")) {
metaCache.setValue("size", size);
}
if (clearInterval != null) {
cache = new ScheduledCache(cache);
((ScheduledCache) cache).setClearInterval(clearInterval);
}
if (readWrite) {
cache = new SerializedCache(cache);
}
cache = new LoggingCache(cache);
cache = new SynchronizedCache(cache);
if (blocking) {
cache = new BlockingCache(cache);
}
return cache;
} catch (Exception e) {
throw new CacheException("Error building standard cache decorators. Cause: " + e, e);
}
}
三、总结
装饰器模式主要解决继承关系过于复杂的问题,通常是通过组合来替代继承。
它主要的作用是给原始类添加功能。这也是判断是否该用装饰器模式的一个重要的依据。除此之外,装饰器模式还有一个特点,那就是可以对原始类嵌套使用多个装饰器。为了满足这个应用场景,在设计的时候,装饰器类需要跟原始类继承相同的抽象类或者接口。
Q: 在学习代理设计模式的时候,我们通过装饰者模式给 InputStream 添加缓存读取数据功能。那对于“添加缓存”这个应用场景来说,我们到底是该用代理模式还是装饰器模式呢?你怎么看待这个问题?
事实上对于绝大多数的"添加缓存"的业务场景,核心目的主要就是想增强对象的功能(即增加缓存功能),而并不是控制对对象的访问,所以装饰器模式可能会更合适。但是假如,我们想强制对持久层增加一个本地缓存,代理设计模式也是很好的选择。
文章到这里就结束了,如果有什么疑问的地方,可以在评论区指出~
希望能和大佬们一起努力,诸君顶峰相见文章来源:https://www.toymoban.com/news/detail-724108.html
再次感谢各位小伙伴儿们的支持!!!文章来源地址https://www.toymoban.com/news/detail-724108.html
到了这里,关于【23种设计模式】装饰器模式的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!