`
playfish
  • 浏览: 292400 次
  • 性别: Icon_minigender_1
  • 来自: 福州
社区版块
存档分类
最新评论

《让僵冷的翅膀飞起来》系列之三——从Adapter模式到Decorator模式

    博客分类:
  • Java
阅读更多

一、 考察对象的Adapter模式

从上文看到,经过引入Adapter模式,原有的结构得到了改进。但我们还需要从客户的角度分析程序,使结构更加地合理。(这里,我们仅限于考察对象的Adapter模式。类的Adapter模式不存在下述问题。这也印证了一个事实,就是:对象的Adapter模式和类的Adapter模式各有优势,也各有缺点,设计时应根据实际情况考察。)

1、扩展的功能是否合理?

假设用户希望调用VedioMedia同时具有Play()和Resize()功能。从前面的描述来看,客户只需要实例化VedioAdapter类对象,就可以调用了。看来结构是正确的。

2、类型的扩展是否合理?

从目前的需求来看,要调用RM和MPEG类型的对象,没有任何问题。但是正如吕震宇所说,在VedioMedia类的Resize()方法中有一股腐化的味道。坏味道的根源就是if 条件语句。如果要增加新的视频类型,就需要修改Resize()方法了。这是一个设计的权衡。其实这个味道虽然够坏,但好处是简单,也不用更多的对象;但耦合性比较差。

如果我们的目标是希望更好的架构以支持耦合的松散,目前的结构就需要微调了。调整后的类图如下:


 

这样需要改变VedioAdapter类的代码:
public abstract class VedioAdapter:IVedioScreen
{
 protected vedioMedia _vedio;
 
 public VedioAdapter(vedioMedia vedio)
 {
  _vedio = vedio;
 }

 public void Play()
 {
  _vedio.Play();  
 }

public abstract void Resize();
}

然后实现RMAdapter和MPEGAdatper:
public class RMAdapter:VedioAdapter
{
 public RMAdapter(VedioMedia vedio):base(vedio){}
 
 public override void Resize()
 {
  MessageBox.Show("Change the RM screen's size.");
 }
}
(MPEGAdapter的代码省略)

这样一改,要扩展就容易了,不过比之以前设计要复杂些,希望不会有人说我过度设计。如果要考虑正确性的话,RMAdapter的构造函数还需要考虑异常情况。由于构造函数的参数为VedioMedia类型,因此,客户在调用时可能会传入MPEG类型,此时RMAdapter类型的Play()行为就会发生改变。这也是和Decorator最大的不同,就是我们必须限制对象的Play()方法不能做任何改变。
public RMAdapter(VedioMedia vedio):base(vedio)
{
 if (!(vedio is RM))
  throw new Exception("VedioMedia object is not correct!");
}

3、 是否与原有客户系统兼容?

如果在原有的客户系统中提供了如下的类及方法:
public class MediaFile
{
 public static void Play(IMedia media)
 {
  media.Play();
 }
}

那么客户如下的调用是没有任何问题的:
MediaFile.Play(new RM());

然而,当客户要使用新的Adapter对象呢?例如:
MediaFile.Play(new RMAdapter());
显然是有问题了,因为RMAdpater类没有实现IMedia接口,且RMAdpater类的Play()方法和IMedia接口的Play()方法在性质上也是有区别的。此时,采用原有的设计就不正确了。改进的方法很简单,就是让VedioAdapter类实现IMedia接口就可以了:


 

public abstract class VedioAdapter:IVedioScreen,IMedia
{
 ……
}

根据吕震宇所说,当VedioAdapter类实现IMedia接口时,言外之意就是该Adapter也适合AudioMedia类型了。是否如此呢?可以说是一半对,一半不对。对的原因,是由于AudioMedia类也实现了IMedia接口;但别忘了,我们适配的并非类,而是对象,也就是在 VedioAdapter中传递进来的VedioMedia对象。(如果我们将传递进来的对象扩展为IMedia,那就糟糕了。震宇兄的结论就完全成立了。)同时,我们在构造函数的异常处理,也保证了AudioMedia类型对于VedioAdapter是非法的。

写到这里,我觉得本文已经超出了原来的设想,有些研究的味道了。嗯,还算不错。那么就继续研究下去吧。

二、 引入Decorator模式

按照最初的需求,我引入Decorator模式试一试。最初的需求是,需要为RM和MPEG类在不改变原有代码的情况下,添加Resize()方法,而其原来的Play()方法不变。调整设计类图:


 上图的橙红色区域为Decorator模式的主体,至于IVedioScreen接口,仅仅是为VedioDecorator增加Resize()方法而引入的,其本身与Decorator无关,除非我要实现的Decorator功能,通过该接口来实现。代码如下:
public abstract class VedioDecorator:VedioMedia,IVedioScreen
{
 private VedioMedia _vedio;
 
 public VedioAdapter(vedioMedia vedio)
 {
  _vedio = vedio;
 }

 public VedioMedia Vedio
 {
  get {return _vedio;}
 }
public abstract void Resize();
}

注意看,与前面Adapter模式的VedioAdapter类比较,除增加了对VedioMedia的派生外,还减少了Play(),因为该方法已经从VedioMedia类中派生获得。这样的话,RMDecorator和MPEGDecorator,也需要做相应的改变:
public class RMDecorator:VedioDecorator
{
 public RMDecorator (VedioMedia vedio):base(vedio)
{
  if (!(vedio is RM))
   throw new Exception("VedioMedia object is not correct!");
}
 
 public override void Play()
 {
  Vedio.Play();
 }
 public override void Resize()
 {
  MessageBox.Show("Change the RM screen's size.");
 }
}

到这个时候,我忽然觉得引入Decorator模式,已经有些力不从心了。为什么呢?最大的障碍就是我们的需求不能更改VedioMedia类型 Play()方法的既有行为。这个时候,所谓的Decorator已经失去了原来的意义。其实我觉得,此时的设计,应该是结合了Adapter模式与 Decorator模式而衍生出的新的结构。

那么,我为什么还要在本文提出引入Decorator模式呢。这来源我对于设计模式一向的观点:不要为了模式而模式!GOF的23种模式,并非茴香豆的“茴”字,我也并非孔乙己,要你回答“茴”字的写法,却忽略了使用设计模式的真正精神。设计模式归根结底是拿来用的。只要符合你的要求,各种模式随你怎么变都可以。因此,不管是前文所述的Adapter模式,还是改进后的Adapter模式,或者引入的Decorator模式,其中的变化是灵活的,选择权最终还是你。

三、 正宗的Decorator模式

不过,我还是很有兴趣继续探讨下去,仍然借助媒体播放这个例子,来谈一谈Decorator模式的一般应用。现在我们要求RM和MPEG媒体在播放前,首先要显示媒体文件的版权信息。请注意,这个需求,并非是为RM等媒体增加ShowCopyright()方法,而Play()方法保持不变。恰恰相反,新的需求装饰了Play()的行为,它要求Play()的同时能够支持ShowCopyright的功能。类图如下:

在这里,VedioDecorator是装饰类的抽象类,而CopyRightVedioDecorator类则具体装饰了Play()的功能。
public abstract class VedioDecorator:VedioMedia
{
 private VedioMedia _vedio;
 
 public VedioAdapter(vedioMedia vedio)
 {
  _vedio = vedio;
 }

 public VedioMedia Vedio
 {
  get {return _vedio;}
 }
}
然后实现CopyRightVedioDecorator类,为Play()方法装饰显示版权信息的功能:
public class CopyRightVedioDecorator:VedioDecorator
{
 private CopyRight _copyRightMark;
 
 public CopyRight CopyRightMark
 {
  get {return _copyRightMark;}
  set {_copyRightMark = value;}
 }
 public override void Play()
 {
  _copyRightMark.ShowCopyRight();
  Vedio.Play();
 }
}

我们还可以继续装饰VedioMedia的Play行为,例如,要求在播放媒体文件之前,必须放一段广告,那么我们可以继续提供一个AdvertisementVedioDecorator装饰类。道理与上一样,不再赘述。

通过本例,我们可以看到Decorator模式与对象的Adapter模式的区别。
实现的区别:
1、 Decorator抽象类应继承要装饰的类,同时又聚合该类的实例对象;而对象的Adapter模式则只聚合,不继承;
2、 Decor模式并没有引入新的接口,除非要装饰的行为需要使用该接口;而对象的Adapter模式则引入了新的接口,以此来装配原有的对象,使其具有了新接口的方法;

因此,适用的场景也就有所不同:
1、 Decorator模式如其名,一般并不提供新的行为,而是在原有的行为上进行补充,即装饰的含义。
2、 Adapter模式则是为对象引入新的行为,使其匹配新的接口,即为适配的意义所在。

分享到:
评论

相关推荐

    《让僵冷的翅膀飞起来》系列之三

    《让僵冷的翅膀飞起来》系列之三——从Adapter模式到Decorator模式 - Wayfarer's Prattle - 博客园

    嵌入式八股文面试题库资料知识宝典-深圳禾苗通信科技有限公司.zip

    嵌入式八股文面试题库资料知识宝典-深圳禾苗通信科技有限公司.zip

    Arduino UART实验例程【正点原子EPS32S3】

    Arduino UART实验例程,开发板:正点原子EPS32S3,本人主页有详细实验说明可供参考。

    电力弹簧技术在主动配电网规划与运行优化调度中的应用研究

    内容概要:本文详细探讨了电力弹簧技术在主动配电网规划及运行优化调度中的应用。首先介绍了电力弹簧技术作为智能电网调控手段的优势,如自适应性强、响应速度快、节能环保等。接着阐述了主动配电网规划的目标和策略,包括优化电网结构、提高能源利用效率和降低故障风险。随后讨论了运行优化调度的原则和方法,强调了实时监测、智能调度策略以及优化调度模型的重要性。最后通过实际案例分析展示了电力弹簧技术在提升电网稳定性、可靠性和能效方面的显著效果,展望了其广阔的应用前景。 适合人群:从事电力系统规划、运行管理的研究人员和技术人员,以及对智能电网感兴趣的学者和学生。 使用场景及目标:适用于希望深入了解电力弹簧技术及其在主动配电网规划和运行优化调度中具体应用的专业人士。目标是掌握电力弹簧技术的工作原理、优势及其在实际项目中的实施方法。 其他说明:本文不仅提供了理论分析,还有具体的案例支持,有助于读者全面理解电力弹簧技术的实际应用价值。

    honor_1.145_testgray20250427.apk

    honor_1.145_testgray20250427.apk

    嵌入式八股文面试题库资料知识宝典-【开发】嵌入式开源项目&库&资料.zip

    嵌入式八股文面试题库资料知识宝典-【开发】嵌入式开源项目&库&资料.zip

    鸿蒙生态HarmonyOS:万物互联时代的操作系统革新与发展路径

    内容概要:本文详细介绍了华为推出的面向全场景的分布式操作系统HarmonyOS。HarmonyOS旨在打破设备间的壁垒,实现万物互联,通过分布式软总线和分布式任务调度等核心技术,让不同设备协同工作,如手机、平板、智能家居等设备间无缝流转任务。其应用生态涵盖教育、金融、出行等多个领域,华为通过资金、技术支持和流量扶持吸引开发者,推动生态繁荣。HarmonyOS从2019年首次发布至今,经历了多个版本迭代,性能和安全性不断提升,用户体验更加智能便捷。尽管面临应用生态丰富度不足、市场竞争压力等挑战,华为通过优化开发工具、加强市场推广等策略积极应对。未来,HarmonyOS将在分布式技术、AI融合和隐私安全等方面持续创新,并在智能家居、车联网、工业互联网等领域拓展生态。 适合人群:对操作系统技术感兴趣的专业人士、开发者、科技爱好者。 使用场景及目标:①了解HarmonyOS的技术架构和分布式技术的特点;②探讨HarmonyOS在智能家居、车联网等领域的应用前景;③评估HarmonyOS对现有操作系统市场的潜在影响。 阅读建议:HarmonyOS作为一款面向全场景的操作系统,不仅涉及技术实现,还包括生态建设和用户体验。因此,在阅读过程中,应重点关注其技术优势、应用场景及未来发展潜力,结合自身需求思考其在实际生活和工作中的应用价值。

    少儿编程scratch项目源代码文件案例素材-简单杀戮.zip

    少儿编程scratch项目源代码文件案例素材-简单杀戮.zip

    基于阻抗控制和工艺优化的机器人磨抛技术研究.pdf

    基于阻抗控制和工艺优化的机器人磨抛技术研究.pdf

    少儿编程scratch项目源代码文件案例素材-扛住别被压.zip

    少儿编程scratch项目源代码文件案例素材-扛住别被压.zip

    【操作系统领域】HarmonyOS架构解析:分布式设计与全场景智能应用的创新实践

    内容概要:本文详细介绍了华为自主研发的面向全场景的分布式操作系统——HarmonyOS的架构设计及其在智能家居、智能穿戴、智慧出行等领域的应用。HarmonyOS采用分层架构,包括内核层、系统服务层、框架层和应用层,各层分工明确,协同工作,为用户提供稳定、高效、智能的操作系统。其核心特性包括分布式架构、微内核设计、组件化开发和一次开发多端部署,这些特性使得不同设备能够实现互联互通和资源共享,为用户带来无缝的全场景智能体验。此外,文章还探讨了HarmonyOS面临的生态建设和兼容性挑战,以及未来的发展前景和技术创新方向。 适合人群:对操作系统架构感兴趣的科技爱好者、智能设备开发者及相关行业从业者。 使用场景及目标:①了解HarmonyOS架构设计及其在智能家居、智能穿戴、智慧出行等领域的具体应用;②掌握HarmonyOS的核心特性,如分布式架构、微内核设计、组件化开发和一次开发多端部署;③探讨HarmonyOS面临的挑战及其未来发展方向。 其他说明:HarmonyOS的出现不仅为华为在智能设备领域的发展提供了有力支撑,也为整个行业的创新发展注入了新的活力。作为科技爱好者和关注者,我们应持续关注HarmonyOS的发展,共同见证它在智能设备领域创造更多的辉煌。

    嵌入式八股文面试题库资料知识宝典-linux驱动开发.zip

    嵌入式八股文面试题库资料知识宝典-linux驱动开发.zip

    开关磁阻电机技术参数与建模技术深度解析:4kW电机性能详述

    内容概要:本文深入探讨了一款额定功率为4kW的开关磁阻电机,详细介绍了其性能参数如额定功率、转速、效率、输出转矩和脉动率等。同时,文章还展示了利用RMxprt、Maxwell 2D和3D模型对该电机进行仿真的方法和技术,通过外电路分析进一步研究其电气性能和动态响应特性。最后,文章提供了基于RMxprt模型的MATLAB仿真代码示例,帮助读者理解电机的工作原理及其性能特点。 适合人群:从事电机设计、工业自动化领域的工程师和技术人员,尤其是对开关磁阻电机感兴趣的科研工作者。 使用场景及目标:适用于希望深入了解开关磁阻电机特性和建模技术的研究人员,在新产品开发或现有产品改进时作为参考资料。 其他说明:文中提供的代码示例仅用于演示目的,实际操作时需根据所用软件的具体情况进行适当修改。

    嵌入式八股文面试题库资料知识宝典-新岸线.zip

    嵌入式八股文面试题库资料知识宝典-新岸线.zip

    基于支持向 量机和余弦相似度的故障诊断方法.pdf

    基于支持向 量机和余弦相似度的故障诊断方法.pdf

    Objective-C+ARKit实现图片识别、平面捕捉、人脸识别+源码(毕业设计&课程设计&项目开发)

    Objective-C+ARKit实现图片识别、平面捕捉、人脸识别+源码,适合毕业设计、课程设计、项目开发。项目源码已经过严格测试,可以放心参考并在此基础上延申使用 ARKit实现图片识别、平面捕捉、人脸识别 ARKit需要ios11 以及 A11处理器或更高版本设备支持 Objective-C+ARKit实现图片识别、平面捕捉、人脸识别+源码,适合毕业设计、课程设计、项目开发。项目源码已经过严格测试,可以放心参考并在此基础上延申使用 ARKit实现图片识别、平面捕捉、人脸识别 ARKit需要ios11 以及 A11处理器或更高版本设备支持~ Objective-C+ARKit实现图片识别、平面捕捉、人脸识别+源码,适合毕业设计、课程设计、项目开发。项目源码已经过严格测试,可以放心参考并在此基础上延申使用 ARKit实现图片识别、平面捕捉、人脸识别 ARKit需要ios11 以及 A11处理器或更高版本设备支持

    少儿编程scratch项目源代码文件案例素材-火柴人大战 中世纪战争.zip

    少儿编程scratch项目源代码文件案例素材-火柴人大战 中世纪战争.zip

    嵌入式八股文面试题库资料知识宝典-并行科技笔试题.zip

    嵌入式八股文面试题库资料知识宝典-并行科技笔试题.zip

    嵌入式八股文面试题库资料知识宝典-进程线程.zip

    嵌入式八股文面试题库资料知识宝典-进程线程.zip

    嵌入式八股文面试题库资料知识宝典-金山问题.zip

    嵌入式八股文面试题库资料知识宝典-金山问题.zip

Global site tag (gtag.js) - Google Analytics