装饰者模式
设计模式的基本原则,对内关闭修改。
Decorator Pattern,装饰者模式,也叫包装器模式(Wrapper Pattern):将一个对象包装起来,增加新的行为和责任。一定是从外部传入,并且可以没有顺序,按照代码的实际需求随意挑换顺序。当使用装饰器模式时,通常将原始对象作为一个参数传给装饰者的构造器。注重功能拓展,关注于在一个对象上动态的添加方法,在同一个方法下实现更多的功能。装饰者能够在运行时递归地被构造。
类图
涉及角色:
- Component:被装饰对象基类,定义对象的接口,可以给这些对象动态增加功能;
- ConcreteComponent:具体被装饰对象,定义具体的对象,Decorator可以给它增加额外的功能;
- Decorator:抽象装饰者类,持有一个指向Component实例(也就是具体被装饰对象)的引用,且定义与Component一致的接口;
- ConcreteDecorator:具体装饰者对象,实现抽象装饰者角色,负责为具体构件添加额外功能。
适用场景:
- 在不影响其他对象的情况下,以动态透明的方式给单个对象添加职责;
- 处理那些可以撤消的职责;
- 当不能采用生成子类的方法进行扩充时。一种情况是,可能有大量独立的扩展,为支持每一种组合将产生大量的子类,使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏,或类定义不能用于生成子类
OO原则:动态地将责任附加到对象上。想要扩展功能,装饰者提供有别于继承的另一种选择。原有的不能满足现有的需求,对原有的进行增强。
装饰和继承
除了继承,装饰者模式也可以扩展行为。实际上是因为继承的弊端,大师们提出装饰者模式。
继承是面向对象编程中的一种机制,一个类可以继承另一个类的属性和方法。被继承的类称为父类或基类,继承的类称为子类或派生类。
优点
- 代码重用:子类可重用父类的方法和属性
- 简单明了:继承关系一目了然,易理解
缺点
- 耦合性高:子类与父类紧密耦合,修改父类可能会影响所有子类
- 灵活性低:继承是静态的,不能在运行时改变
- 违背单一职责原则:子类往往会继承父类的所有功能,可能导致类职责过多
总结
- 装饰者模式提供一种动态组合对象行为的方法,灵活性更高,遵循开闭和单一职责原则,但会增加复杂性
- 继承提供一种静态的代码重用机制,简单明了,但耦合性高,灵活性低
选择哪种模式取决于具体需求:如果需要动态扩展对象行为,使用装饰者模式;如果希望简单地重用代码,使用继承。
实例
Java IO
BufferedInputStream
BufferedOutputStream
BufferedReader
BufferedWriter
当使用InputStream读取数据时,每次可能都会进行实际的IO操作,而BufferedInputStream会先将一部分数据读入缓冲区,后续的读取操作可以直接从缓冲区获取,减少IO次数。
BufferedInputStream并没有改变FileInputStream的基本结构和接口,只是为其添加缓冲特性。
Spring
Spring中的装饰者在类名上有两种表现:
- 类名中含有Wrapper
- 类名中含有Decorator
TransactionAwareCacheDecorator:实现Cache接口
外观模式
Facade,外观模式的定义:提供一个统一的高层接口,用来访问子系统中的一批接口,让子系统更容易使用。
当需要简化并统一一批接口时,考虑使用外观模式,依托于子系统执行。注重多个类的集成、统一适配。通过外观的封装,使应用程序只能看到外观对象,而不会看到具体的细节对象,降低应用程序的复杂度,提高可维护性。
该模式把一些复杂的流程封装成一个简单接口供外部用户使用,涉及3个角色:
- 门面角色:外观模式的核心。它被客户角色调用,它熟悉子系统的功能。内部根据客户角色的需求预定几种功能的组合。
- 子系统角色:实现子系统的功能。它对客户角色和Facade时未知的。它内部可以有系统内的相互交互,也可以由供外界调用的接口。
- 客户角色:通过调用Facede来完成要实现的功能。
优点:
- 解耦合:客户端和子系统解耦,让子系统内部的模块功能更容易扩展和维护;
- 易用性:客户端不需要知道子系统内部实现或构成,只需要跟Facade类交互;
- 层次性:有些方法是对系统外的,有些方法是系统内部相互交互的使用的。子系统把那些暴露给外部的功能集中到Facade类中,这样就可以实现客户端的使用,很好的隐藏子系统内部的细节。
满足的设计原则:莫忒耳原则,又称最少知识原则。
缺点(局限性):
- 对子系统的所有操作都交给Facade类来处理,受到Facade类的约束;比如Facade类里可能没有对某个子系统单独的操作,如果需要,则新增方法;
- 这样可能会导致更多的包装对象被制造出来,以处理和其他组件的沟通,可能会导致复杂度和开发时间的增加,降低运行时性能。
实例
SLF4J,参考Java日志框架SLF4J。
Spring
MeterFacade用于APM系统中的Metric监控,有3个子接口:CounterFacade、TimerFacade、GaugeFacade
Tomcat
RequestFacade:Request到HttpServletRequest封装
ResponseFacade:Request到HttpServletResponse封装
StandardWrapperFacade:StandardWrapper到ServletConfig封装
ApplicationContextFacade:ApplicationContext到ServletContext封装
适配器
Adapter,适配器允许通常因为接口不兼容而不能在一起工作的类工作在一起,做法是将类自己的接口包裹在一个已存在的类中。将一个对象包装起来改变接口,注重接口兼容,匹配新接口,适配类持有新的目标对象。
适配器模式有三种形式:
- 对象适配器:通过组合满足用户期待接口,还降低代码间的不良耦合。推荐使用;适配器与适配者之间是关联(?)关系;
- 类适配器:当客户在接口中定义期望的行为时,就可以应用适配器模式,提供一个实现该接口的类,并且扩展已有的类,通过创建子类来实现适配;适配器与适配者之间是继承关系;
- 缺省适配器模式:Default Adapter Pattern,又称为单接口适配器模式,是类适配器模式的变体。当不需要实现一个接口所提供的所有方法时,可先设计一个抽象类实现该接口,并为接口中每个方法提供一个默认实现,那么该抽象类的子类可以选择性地覆盖父类的某些方法来实现需求。
涉及角色:
- Target:目标类,客户需要的接口。注意:由于这里讨论的是类适配器模式,因此目标不可以是类;
- Adaptee:适配者类,是被适配的角色,已存在且无法被修改,因此需要被适配,一般无法获取该类的源代码;
- Adapter:适配器类,核心类,将Adaptee和Target进行适配,即把Adaptee类转换成目标类。
优点:
- 解耦:将目标类和适配者类解耦,通过引入一个适配器类来重用现有的适配者类,无须修改原有结构;
- 复用:适配者在原有系统中可正常使用,在目标类中可充当新角色;
- 扩展:可通过配置文件很方便地更换适配器,也可在不修改原有代码的基础上增加新适配器,符合开闭原则。
对象适配器模式还有如下优点:
- 一个对象适配器可以把多个不同的适配者适配到同一个目标;
- 由于适配器和适配者之间是关联关系,因此可以适配一个适配者的子类,符合里氏代换原则。
缺点:
- Java不支持多继承,一个适配器只能适配一个适配者;
- 适配者类不能为final类;
- 类适配器模式中的目标类只能为接口,不能为类。
对象适配器模式的缺点:当需要置换适配者类的某些方法时,需要把适配者的子类当做真正的适配者,实现过程较为复杂。
适用场景:
- 系统需要使用现有的类,而这些类的接口不符合系统的接口;
- 想要建立一个可重用的类,用于与一些彼此之间没有太大关联的一些类,包括一些可能在将来引进的类一起工作;
- 两个类所做的事情相同或相似,但具有不同接口时;
- 旧的系统开发的类已经实现一些功能,但客户端却只能以别的接口的形式访问,但不希望手动更改原有类时;
- 使用第三方组件,组件接口定义和自己定义的不同,不希望修改自己的接口,但是要使用第三方组件接口的功能。
实例
JDK
Java IO中,如:InputStreamReader、StringReader、OutputStreamWriter、ByteArrayInputStream等。InputStreamReader是一个适配器,Reader是适配者,InputStream是目标。ByteArrayInputStream和OutputStreamWriter同理。
使用IDEA自带的Diagrams插件查看类的依赖关系,注意要勾选Show Dependencies按钮:
StringReader是适配器,Reader是适配者,String是目标。
Spring
Spring AOP,AdvisorAdapter接口:
public interface AdvisorAdapter {
boolean supportsAdvice(Advice advice);
MethodInterceptor getInterceptor(Advisor advisor);
}
Advisor链需要的是MethodInterceptor(拦截器)对象,所以每一个Advisor中的Advice都要适配成对应的MethodInterceptor对象。
其实现类有3个:
HandlerAdapter
Spring MVC核心组件。
比较
适配器模式和装饰者模式
相同点:
- 都是结构型设计模式,都使用组合思想,即通过将一个对象传递给另一个对象来实现功能的扩展或转换;
- 两者都不会修改原有类的代码,只是通过增加新的类来实现新的功能。
不同点:
- 目的:
- 适配器模式旨在解决接口不兼容的问题,使现有类可以与其他类协同工作;
- 装饰者模式则是为了动态地扩展对象的功能,而不改变其结构。
- 实现方式:
- 适配器模式通常涉及两个不兼容接口的转换,适配器本身只实现接口兼容,不增加新的行为;
- 装饰者模式不改变原对象接口,通过组合和方法包装来添加新行为。
- 适用场景:
- 期望复用的已有的类,与新系统不兼容时,可考虑使用适配器模式;
- 期望可以动态地为对象添加额外的功能,且功能可随时开启或关闭时,可考虑使用装饰者模式。
以Java IO流举例:
- 将一个类适配到另一个类,InputStreamReader将Reader类适配到InputStream,实现字节流到字符流的准换;
- FilterInputStream继承InputStream,BufferedInputStream继承自FilterInputStream,是具体的装饰器实现者,将InputStream读取的内容保存在内存中,而提高读取性能。
外观模式和装饰者模式
相同点:都是结构型设计模式,都通过组合来实现其功能,装饰者模式侧重于增强对象的功能,而外观模式侧重于简化系统接口。
不同点:
- 目的:
- 装饰者模式的目的是通过包装对象来动态扩展其功能;
- 外观模式的目的是通过提供一个简化的接口来隐藏系统复杂性。
- 实现方式:
- 装饰者模式在同一个接口层次上通过递归组合的方式增加行为;
- 外观模式通过创建一个高层接口来简化对复杂子系统的访问。
- 使用场景:
- 装饰者模式适用于需要动态扩展对象功能的场景;
- 外观模式适用于通过封装来简化与复杂子系统交互的场景。
代理模式和装饰者模式
与原对象实现同一个接口,必须要实现原接口和持有真实的对象,才能称之为代理类。代理模式一定是自身持有这个对象,不需要从外部传入。用代理模式,代理类可以对它的客户隐藏一个对象的具体信息。当使用代理模式时,常常在一个代理类中创建一个对象的实例。注重隔离限制,关注于控制对对象的访问,让外部不能访问你实际的调用对象,如权限控制。代理和真实对象之间的关系通常在编译时就已经确定。