装饰器模式(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个结果
还有上面提到的智能搜索功能,并不是所有的搜索都需要这样的功能,我们不需要把相关的接口暴露给不需要使用的开发者。上面的内容就能体现装饰者模式的好处了,就不继续扩展了。
当然了,缺点也比较明显,可能会产生很多的类;多层的装饰也会增加复杂度。
总结
例子很简单,在复杂的开发中,往往我们没有时间思考这么多,我们更倾向于简单的构思,然后就开始实现。这样并没有什么错,能简单快速的达到我们想要的效果,但我们可以尝试下一步,在封装的基础上用一些设计模式,让以后维护更轻松,更快捷。如果能在一开始就使用一些优秀的设计模式,何乐而不为呢?
码字不易,感谢阅读
网友评论