偷梁换柱之装饰模式(Decorator)

最新推荐文章于 2024-10-19 21:23:33 发布

sdw360

最新推荐文章于 2024-10-19 21:23:33 发布

阅读量89

点赞数

分类专栏：设计模式文章标签：设计模式

本文链接：https://blog.csdn.net/sdw360/article/details/84627372

版权

设计模式专栏收录该内容

2 篇文章 0 订阅

订阅专栏

装饰模式基本含义是:能够动态的为一个对象添加一些额外的功能。

在面向对象的世界里，对于为一个对象添加一些额外的功能，我们很自然的会想到一个面向对象的重要特征：继承，通过使用继承我们可以获得：对父类的方法进行覆盖对子类添加新的方法

既然使用继承有这么多的好处，那我们为什么还要费力搞出一个装饰模式呢？

因为继承这种语法特性是在编译期就“额外添加” 的功能确定好了的，这就决定了继承这种方式注定是静态的，无法满足我们在运行期添加新功能的欲望。而且随着我们要获取的功能的增多，子类急剧膨胀；另一方面，java的单继承规则也限定了继承这种方式的灵活性。

为了解决这种为了动态添加对象额外的行为职责而过度地依赖继承来进行行为扩展---装饰(Decorator)模式横空出世...

装饰模式中涉及的角色：

1.原始接口：Component

2.默认的目标实现类：TagartComponent---对原始接口的默认实现在装饰模式中是有待进行装饰的类，其中operate方法被作为有待扩展的方法

3.装饰实现类：ComponentDecorator---与默认实现类同样实现了原始接口，装饰实现类既可以是抽象类也可以是具体的实现类，其内部封装了一个目标实现类的对象作为其内部变量具体装饰实现类：ComponentDecoratorA，ComponentDecoratorB：继承装饰实现类，我们可以在这些具体的装饰实现类内部通过装饰实现类的默认目标实现类的对象invoke TagartComponent.operate()。然后对其行为职责进行装饰，也可以添加addBehavior进行新添行为职责。

自此，我们可以总结出要实现装饰模式的基本条件： 默认目标实现类与装饰实现类共同实现了原始接口装饰实现类或其子类中持有默认目标实现类的引用

使用装饰模式的最大好处就是：可以在运行期对对象进行行为职责扩展，而且对于扩展非常方便

对于装饰模式的应用也是屡见不鲜，像

HttpServletRequest HttpServletRequestWrapper HttpServletResponse HttpServletResponseWrapper

此处不表...

我心目中目前我觉得将装饰模式实践的最好的是：

/**
 * Wraps an XWork type conversion class for as an OGNL TypeConverter
 */
public class OgnlTypeConverterWrapper implements ognl.TypeConverter {

    private TypeConverter typeConverter;//注意这里并不是ognl.TypeConverter
    
    public OgnlTypeConverterWrapper(TypeConverter conv) {
        if (conv == null) {
            throw new IllegalArgumentException("Wrapped type converter cannot be null");
        }
        this.typeConverter = conv;
    }
    
    public Object convertValue(Map context, Object target, Member member,
            String propertyName, Object value, Class toType) {
        return typeConverter.convertValue(context, target, member, propertyName, value, toType);
    }
    
    public TypeConverter getTarget() {
        return typeConverter;
    }
}

By the way:这里的原始接口和装饰实现类持有的引用并不以同一个Class Type，

一个是com.opensymphony.xwork2.conversion.TypeConverter。

一个是 ognl.TypeConverter。

struts2在引入Ognl时，在TypeConverter扩展方面做的非常巧妙。 Struts2并没有使用Ognl本身的ognl.TypeConverter接口作为其原始接口，而是自己搞了一个与ognl.TypeConverter拥有相同方法的接口： com.opensymphony.xwork2.conversion.TypeConverter。

这样做一方面将XWork的TypeConverter的实现细节很好的屏蔽，另一方面，将XWork对TypeConverter的扩展实现纳入到XWork容器管理，也有利于XWork自身在装饰器中插入框架提供的用户自定义的TypeConverter 功能扩展。