设计模式之装饰者模式

字数 1076阅读 46

装饰器模式(Decorator Pattern)

允许向一个现有的对象添加新的功能,同时又不改变其结构。这种类型的设计模式属于结构型模式,它是作为现有的类的一个包装。
这种模式创建了一个装饰类,用来包装原有的类,并在保持类方法签名完整性的前提下,提供了额外的功能。

优缺点:

优点:装饰类和被装饰类可以独立发展,不会相互耦合,装饰模式是继承的一个替代模式,装饰模式可以动态扩展一个实现类的功能。

缺点:多层装饰比较复杂。

关键代码: 1、Component 类充当抽象角色,不应该具体实现。 2、修饰类引用和继承 Component 类,具体扩展类重写父类方法。

使用场景

有两个参考依据

1. 扩展一个类的功能
2. 动态增加功能,动态撤销

场景和实现方式

应用开发中,常常会有搜索器的需求。假设这样一个场景,现在的搜索需求呢,是要搜索所有结果。好,这时候同事已经开发完了,很稳定,也上线成功了。搜索的关键方法是这样的,根据输入填充输出

T search(String userInput)

然后下个版本产品说要加各种标签来过滤搜索结果,这时候的做法通常是在定义的接口添加一个标签参数,如下。并修改原本稳定的搜索实现

T search(String userInput, String tag)

好,做完了,bug也修改完了,也稳定上线了。下个版本,产品想让搜索功能变得更智能,根据用户的搜索历史来匹配搜索结果。这时候你可能就会火大了,难道还要继续在 search 加一个搜索历史集合参数用来过滤?
这时候搜索方法应该就会很复杂了。

T search(String userInput, String tag, List<E> history)

机智的小伙伴,可能会选择方法重载方式,定义如上三个接口,分别实现,当然这完全可以。不过我们使用装饰者模式,定义搜索的抽象角色 Component 包含一个参数的搜索方法即可。

public interface Searcher<T> {

    /**
     * 执行用户输入搜索
     *
     * @param userInput
     * @return
     */
    T search(String userInput);
}

搜索的实现,简单实现,将内容填充到搜索结果封装。完成我们简单的搜索版本

public class SearchImpl implements Searcher<ResultEntity> {

    @Override
    public ResultEntity search(String userInput) {
        ResultEntity re = new ResultEntity();
        re.result = "搜索 " + userInput;
        re.size = 200;
        return re;
    }
}

当我们有标签过滤搜索的需求时,我们设计一个装饰者 TagSearchDecorate ,也实现我们的抽象角色 Searcher
同时,我们把搜索实现组合进来,实际的搜索还是用我们的 SearchImpl 来完成。 我们的装饰者添加一个设置搜索标签的方法,在取得搜索结果后通过标签过滤。

public class TagSearchDecorate implements Searcher<ResultEntity> {
    private Searcher<ResultEntity> mSearcher;
    private String tag;

    public TagSearchDecorate(Searcher<ResultEntity> searcher) {
        this.mSearcher = searcher;
    }

    @Override
    public ResultEntity search(String userInput) {
        ResultEntity result = mSearcher.search(userInput);
        result.result += "并根据" + tag + "过滤 ";
        filter(result);
        return result;
    }

    public void setTag(String tag) {
        this.tag = tag;
    }

    private void filter(ResultEntity resultEntity) {
        resultEntity.size = 100;
    }

}

这样就达到不修改默认实现,添加了过滤器的功能,对搜索功能进行了扩展。同时,如果我们有其他地方需要使用最初的搜索方法,我们也可以按以前的方式使用了

测试代码

    private static void decorate() {
        Searcher<ResultEntity> searcher = new SearchImpl();
        ResultEntity result = searcher.search("Android面试宝典");
        System.out.println(result.result + " " + result.size + "个结果");

        TagSearchDecorate tagSearch = new TagSearchDecorate(searcher);
        tagSearch.setTag("2017年");
        ResultEntity tagResult = tagSearch.search("Android面试宝典");
        System.out.println(tagResult.result + " " + tagResult.size + "个结果");
    }

测试结果

搜索 Android面试宝典 200个结果
搜索 Android面试宝典并根据2017年过滤  100个结果

还有上面提到的智能搜索功能,并不是所有的搜索都需要这样的功能,我们不需要把相关的接口暴露给不需要使用的开发者。上面的内容就能体现装饰者模式的好处了,就不继续扩展了。

当然了,缺点也比较明显,可能会产生很多的类;多层的装饰也会增加复杂度。

总结

例子很简单,在复杂的开发中,往往我们没有时间思考这么多,我们更倾向于简单的构思,然后就开始实现。这样并没有什么错,能简单快速的达到我们想要的效果,但我们可以尝试下一步,在封装的基础上用一些设计模式,让以后维护更轻松,更快捷。如果能在一开始就使用一些优秀的设计模式,何乐而不为呢?

码字不易,感谢阅读