Java 8的装饰器模式
在最近的一篇文章中,我描述了装饰器模式如何拯救了我的一天。 我给出了一个小代码段,其中包含创建装饰器的最简单方法,但承诺Java 8会有更好的方法。
这里是:
用Java 8装饰
HyperlinkListener listener = this::changeHtmlViewBackgroundColor;
listener = DecoratingHyperlinkListener.from(listener).onHoverMakeVisible(urlLabel).onHoverSetUrlOn(urlLabel).logEvents().decorate(l -> new OnActivateHighlightComponent(l, urlLabel)).decorate(OnEnterLogUrl::new);
我将在文章的其余部分中说明如何到达那里。
我在GitHub上创建了一个小样本项目 ,我将从这里重复引用。 我只建议您检查一下它,因为它提供了更多详细信息。 它是公共领域 ,因此可以不受限制地使用该代码。
为了继续我的上一篇文章,它使用Swing的HyperlinkListener
作为装饰的基础。 由于该接口不是通用接口,并且仅具有一个仅带有一个参数的方法(对于lambda表达式而言非常好!),因此具有使其保持简单的附加优点。
总览
像其他帖子一样,该帖子也没有尝试教授模式本身。 (不过,我找到了另一个很好的解释 。)相反,它推荐了一种在Java 8中实现它的方法,以使其使用起来非常方便。 因此,该帖子严重依赖Java 8功能,尤其是默认方法和lambda表达式 。
这些图只是草图,并省略了许多细节。 更完整的是容易找到的 。
香草
在模式的通常实现中,存在一个接口(上面称为Component
),该接口将通过“常规”类以及所有装饰器以常规方式实现。
抽象装饰器类
装饰器通常从中间抽象基类( AbstractDecorator
)继承,从而简化了实现。 它使用另一个组件作为构造函数参数,并通过将所有调用转发给接口来实现接口本身。 因此,装饰组件的行为不变。
现在由子类来实际更改它。 他们通过有选择地重写那些他们想改变其行为的方法来做到这一点。 这通常包括对装饰组件的调用。
装饰器的创建
通常,不使用任何特殊技术来创建装饰器。 只是简单的构造函数。 使用复杂的装饰器,您甚至可以使用工厂。
我是静态构造方法的忠实拥护者,因此我使用它们并将构造方法设为私有。 为了使这些方法的调用者不了解细节,我将这些方法的返回类型声明为Component
,而不是装饰器的更详细类型。 例如,这可以在LogEventsToConsole中看到。
我的建议改变了装饰器的创建方式。
使用Java 8
要使用Java 8的所有功能,我建议为所有装饰器添加一个特殊的接口DecoratingComponent
。 装饰器的抽象超类实现了该接口,但像以前一样,仅保留对Component
的引用。
重要的是要注意,由于新接口的定义(请参阅下文),混凝土装饰器没有任何变化。 它们在模式的两种实现中都是完全相同的。 抽象类实际上也没有任何变化(请参见下文),因此切换到该解决方案不会产生明显的成本。
新介面
新接口DecoratingComponent
扩展了基本组件接口,并为装饰器提供了工厂方法。 这些是静态或默认/防御程序方法(因此它们已经实现,如果可以的话将是最终方法),并且不应声明任何抽象方法。 这样,新接口不会在继承树后面的实现上增加额外的负担。
关于以下代码示例:通用示例仅是为该帖子创建的。 涉及超链接侦听器的对象来自演示应用程序 。 最值得注意的是DecoratingHyperlinkListener
( 到源文件的链接 ),它扩展了Swing的HyperlinkListener 。
方法
该接口本身实际上非常简单,由三种类型的方法组成。
适配器
若要快速从Component
移至DecoratingComponent
,接口应具有静态方法,该方法采用第一个方法,然后返回后者。 由于DecoratingComponent
扩展了Component且未添加任何抽象方法,因此这很简单。 只需创建一个匿名实现,并将所有调用转发到已适配的component
。
通用方法如下所示:
静态适配器方法
static DecoratingComponent from(Component component) {DecoratingComponent adapted = new DecoratingComponent() {@Overridepublic SomeReturn someMethod(SomeArgument argument) {return component.someMethod(argument);}// ... more methods here ...};return adapted;
}
在DecoratingHyperlinkListener
情况下,它要容易得多,因为它是一个功能接口,因此可以使用lambda表达式:
'DecoratingHyperlinkListener'中的静态适配器方法
static DecoratingHyperlinkListener from(HyperlinkListener listener) {return event -> listener.hyperlinkUpdate(event);
}
通用装饰
这是接口的基本方法:
default DecoratingComponent decorate(Function<? super DecoratingComponent, ? extends DecoratingComponent>decorator) {return decorator.apply(this);
}
它从一个装饰组件到另一个装饰组件接受一个函数作为参数。 它将功能应用于自身以创建装饰的实例,然后将其返回。
可以在整个代码中使用此方法,以一种简单易读的方式装饰任何组件:
用'DecoratingComponent'装饰
Component some = ...;
DecoratingComponent decorated = DecoratingComponent// create an instance of 'DecoratingComponent' from the 'Component'.from(some)// now decorate it.decorate(component -> new MyCoolComponentDecorator(component, ...));// if you already have an instance of 'DecoratingComponent', it get's easier
decorated = decorated.decorate(component -> new MyBestComponentDecorator(component, ...));// constructor references are even clearer (but cannot always be used)
decorated = decorated.decorate(MyBestComponentDecorator::new);
混凝土装饰
您还可以添加使用具体装饰器装饰实例的方法:
“ DecoratingHyperlinkListener”中的混凝土装饰
default DecoratingHyperlinkListener logEvents() {return LogEventsToConsole.decorate(this);
}default DecoratingHyperlinkListener onHoverMakeVisible(JComponent component) {return OnHoverMakeComponentVisible.decorate(this, component);
}
它们使装饰非常简洁易读:
用'DecoratingComponent'装饰
DecoratingComponent decorated = ...
decorated = decorated.logEvents();
但是,是否应真正添加这些方法仍有待商de。 尽管它们非常方便,但是当它们创建循环依赖关系时,可以对它们进行强烈的争论。 装饰者不仅知道接口(它们是通过抽象超类间接实现的),现在接口也知道其实现。 通常,这是刺激性的代码气味。
最终召集尚未结束,但我建议采取务实的中间方法。 我让接口知道存在于同一包中的实现。 这将是通用的,因为它们没有引用其余代码中的任何具体内容。 但是我不会让它知道我在系统深处创建的每个疯狂装饰器。 (当然,除非将其称为the_kraken,否则我不会将所有这些装饰器都添加到同一包中。)
为什么需要额外的接口?
是的,是的,所有那些Java 8功能都非常不错,但是您不能简单地将这些方法添加到AbstractDecorator
吗? 好问题!
当然,我可以在这里添加它们。 但是由于两个原因,我不喜欢这种解决方案。
单一责任原则
首先,这将模糊类的职责。 新接口负责装饰Component
实例,抽象超类负责使装饰器易于实现。
这些不是相同的事物,并且由于相同的原因它们不会改变。 每当必须包含新的装饰器时,新的接口就可能更改。 每当Component
更改时,抽象类都会更改。
类型层次结构
如果将这些方法添加到AbstractDecorator
,则只能在此类实例上调用它们。 因此,所有装饰器都必须从该类继承,这限制了将来实现的范围。 谁知道,也许出现了一些非常好的理由,为什么另一个类不能成为AbstractDecorator
。
更糟糕的是,所有装饰器都必须公开一个事实,即它们是AbstractDecorator
。 突然有一个抽象类,它只是为了简化实现而创建的,它遍及整个代码库。
其他差异
除了引入新接口之外,模式的变化不会有太大变化。
对抽象装饰器类的更改
如果可以访问该类,则应让它实现DecoratingComponent
而不是Component
。 由于没有引入新的抽象方法,因此不需要进一步的更改。 上面的UML图中显示了这一点。
如果您不能更改类,则装饰器将仅实现Component
。 这将使您避免使用其构造函数来创建将组件映射到装饰组件的函数。 由于需要将该函数作为decorate
方法的参数,因此必须将该方法更改为如下所示:
通用装饰
// note the more general second type of the 'Function' interface
default DecoratingComponent decorate(Function<? super DecoratingComponent, ? extends Component> decorator) {// create the decorated instance as beforeComponent decorated = decorator.apply(this);// since it is no 'DecoratingComponent' use 'from' to turn it into onereturn from(decorated);
}
装饰的变化
无需更改这些类。 当然,除非您是使用静态工厂方法的那些疯狂的人之一。 比您必须确保它们将其返回类型声明为DecoratingComponent
否则您将处于与抽象超类无法实现新接口的情况相同的情况。 如果您不能更改装饰器类,则此处使用相同的解决方案。
例
因此,让我们从上方再次查看代码段:
用Java 8装饰
// create a 'HyperlinkListener' with a method reference
HyperlinkListener listener = this::changeHtmlViewBackgroundColor;
// decorate that instance with different behaviors
// (note that each call actually returns a new instance
// so the result has to be assigned to a variable)
listener = DecoratingHyperlinkListener// adapt the 'HyperlinkListener' to be a 'DecoratingHyperlinkListener'// (looks better if it is not on its own line).from(listener)// call some concrete decorator functions.onHoverMakeVisible(urlLabel).onHoverSetUrlOn(urlLabel).logEvents()// call the generic decorator function with a lambda expression.decorate(l -> new OnActivateHighlightComponent(l, urlLabel))// call the generic decorator function with a constructor reference.decorate(OnEnterLogUrl::new);
反射
我们了解了如何使用Java 8的静态和默认接口方法为装饰器模式创建流畅的API。 它使代码同时更加简洁和可读性,同时又不干扰模式的机制。
正因为如此,我们使用默认的方法来创建特质有关其作者Brian Goetz写道 :
了解默认方法的关键是,主要的设计目标是接口演变 ,而不是“将接口转变为(中等)特性”
对不起,布莱恩,这太诱人了。 ;)
对装饰器模式有一些见解? 想要改善我的想法还是批评它? 然后发表评论! 并且不要忘记在GitHub上检查代码 。
翻译自: https://www.javacodegeeks.com/2015/01/the-decorator-pattern-with-java-8.html
Java 8的装饰器模式相关推荐
- (设计模式七)java设计模式之装饰器模式
一.简介: 装饰器模式(Decorator Pattern)允许向一个现有的对象添加新的功能,同时又不改变其结构.这种类型的设计模式属于结构型模式,它是作为现有的类的一个包装.这种模式创建了一个装饰类 ...
- java设计模式之装饰器模式
一.装饰器模式简介 装饰器模式可以动态给一个对象添加一些额外的职责,同时又不改变其结构.就象在墙上刷油漆.使用Decorator模式相比用生成子类方式达到功能的扩充显得更为灵活.这种模式创建了一个装饰 ...
- Java 设计模式之装饰器模式
装饰器模式用于给原有对象增加新功能的场景, 拿食物冰淇淋,香草巧克力作为例子,给冰淇淋加香草,或者加巧克力,或者加香草和巧克力. 首先定义一个食物接口: /*** 装饰类和被装饰类共同继承的抽象类* ...
- java设计模式之 装饰器模式
装饰器模式 装饰器模式(Decorator Pattern)允许向一个现有的对象添加新的功能,同时又不改变其结构. 这种类型的设计模式属于结构型模式,它是作为现有的类的一个包装. 这种模式创建了一个装 ...
- java设计模式之装饰器模式(包装器模式)
显然设计模式往往追求开闭原则,所以往往是面向接口编程,那么万事万物就是先写接口,把需求弄出来,这里以一辆车子在陆地上跑为基础,对它进行装饰,使它可以具备更多的"功能",达到装饰的效 ...
- Java中InputStream装饰器模式的大家族
因为和输入流与之对应的还有输出流(即OutputStream),在此只针对输入流InputStream讨论. 1. 家族老大: 一说起家族中的老大,InputStream自然是当仁不让,在java的输 ...
- 装饰器模式代码举例(java语言版)
前言:为了解决子类膨胀问题,把被装饰的以关联的方式放入装饰类里面,装饰类添加新的功能,如果需要再扩展新功能的时候,那么可以考虑直接继承装饰类.下面是一个画圆的例子(其实ServletRequest.H ...
- java设计模式----装饰器模式
Decorator装饰器,顾名思义,就是动态地给一个对象添加一些额外的职责,就好比为房子进行装修一样.因此,装饰器模式具有如下的特征: 它必须具有一个装饰的对象. 它必须拥有与被装饰对象相同的接口. ...
- java外观设计修改_Java设计模式之外观模式和装饰器模式的设计(精选)
前言 本篇来学习下结构型模式的外观模式和装饰器模式. 外观模式 简介 外观模式隐藏系统的复杂性,并向客户端提供了一个客户端可以访问系统的接口.这种类型的设计模式属于结构型模式,它向现有的系统添加一个接 ...
最新文章
- Genome Biology:人体各部位微生物组时间序列分析
- JS监听手机物理返回键,返回到指定页面
- Word中你不得不学习的几个小技巧,让你不仅玩的溜,效率也贼高!
- Python 深度学习目标检测评价指标 :mAP、Precision、Recall、AP、IOU等
- 2015年58同城面试题
- Android: RecyclerView.ViewHolder、Adapter
- Day11多态部分-1 【1.1 多态的体现】
- c++11-auto,nullptr
- python 字典字符串转字典——urllib.request.Request发送get,post请求,发送json参数
- git安装【Windows】
- MYSQL:如何正确高效的使用 MySQL 索引?
- 进程通信之飞鸽传书2007绿色版
- python中解释说明符号_python注释以什么符号开始
- 【网络通信 -- 直播】ZLMediaServer -- 环境搭建与测试
- 爬虫笔记——东方财富科创板数据爬取(requests方法)
- SAM-DETR源码讲解
- 计算机浏览器应用程序,电脑打开IE浏览器显示找不到应用程序如何解决
- 深入浅出Linux操作系统指令与目录结构(二)
- IEEE-754标准与浮点数运算
- 【VUE】【VUE-CLI】【bootstrap】【jeecgboot】干部任免表前端
热门文章
- jQuery 表格实现
- 自增主键与UUID的优缺点
- springboot yml里面配置list 日期日期格式的postMen 发送json
- idea @Data 不起作用找不到 相关的注解
- ReviewForJob(2)算法分析
- ToolProvider.getSystemJavaCompiler() return null 的解决方法
- jmc线程转储_查找线程转储中的异常和错误
- java与java ee_Java EE 8 MVC:全局异常处理
- primefaces_PrimeFaces Mobile入门
- 每个Java开发人员都应该知道的10个基本工具