C#设计模式之装饰者
IronMan之装饰者
前言
上一篇的文章我们讲到要给"IronMan"配备"武器",并且还使用了"武器",效果还是不错的,对于多种环境、多种***方式的"武器"使用,我们已经掌握了。 有的朋友没有看过上一篇文章,那也没关系,此篇的重点不会涉及到上一篇的内容。
好吧,废话不多说,直接进入正题, 这里简要的介绍下,本人一直在为一家"玩具厂"服务,致力于"IronMan"(钢铁侠)的研究,前面的几个篇幅都是在介绍怎么去合理的生产组成"IronMan"的"部件",以及最近需求的变更,需要"部件"可携带武器,并且能***,于是在上一篇中讲到了"武器"的使用,感兴趣的朋友可以去看看。 那我们要如何的去把"武器"和"部件"整合在一起呢?
问题的发现
先来看一下本篇篇幅要用到的一些"部件"和"武器"的结构, 部件的:
1 public abstract class Component 2 { 3 ///之间的代码于本篇幅无关 4 private string strName = string.Empty; 5 /// <summary> 6 /// 名称 7 /// </summary> 8 public string Name 9 { 10 get { return strName; } 11 set { strName = value; } 12 } 13 /// <summary> 14 /// 自我描述 15 /// </summary> 16 public abstract void Self_Described(); 17 } 18 public class RightHandComponent : Component 19 { 20 public RightHandComponent() : this("毅代先锋号一代右部件") { } 21 public RightHandComponent(string strname) 22 { 23 base.Name = strname; 24 } 25 public override void Self_Described() 26 { 27 Console.WriteLine("自描述:我是->" + base.Name); 28 } 29 } 30 public class LeftHandComponent : Component 31 { 32 public LeftHandComponent() : this("毅代先锋号一代左部件") { } 33 public LeftHandComponent(string strname) 34 { 35 base.Name = strname; 36 } 37 public override void Self_Described() 38 { 39 Console.WriteLine("自描述:我是->" + base.Name); 40 } 41 }
武器的:
(这里的结构经过简化,跟上个篇幅没有联系,感兴趣的朋友可以按照上个篇幅的"武器"结构来设计)
1 /// <summary> 2 /// 武器 3 /// </summary> 4 public abstract class Weapon 5 { 6 /// <summary> 7 /// *** 8 /// </summary> 9 public abstract void Attack(); 10 } 11 /// <summary> 12 /// 激光武器 13 /// </summary> 14 public class LaserWeapon : Weapon 15 { 16 public override void Attack() 17 { 18 //LaserAttack 19 Console.WriteLine("激光武器"); 20 } 21 } 22 /// <summary> 23 /// ×××武器 24 /// </summary> 25 public class MissileWeapon : Weapon 26 { 27 public override void Attack() 28 { 29 //MissileAttack 30 Console.WriteLine("×××武器"); 31 } 32 }
看到这样的结构,会想说怎么去为"部件"提供额外的功能呢?让各种武器继承自"部件"?N种武器怎么办?那"部件"的结构是多么大啊!!!想一下都觉得可怕。
问题的解决
不过还好,有设计模式的存在,在这种特定的情况下首先想到的就是"装饰者"模式。 旧版的"部件"和"武器"已经满足不了现在的需求了(可以满足,但是这样整合起来显得过于复杂和庞大,对于初学者可能不太容易学习,所以这里这样说)。 我们重新来升级"部件"和"武器"的结构:
1 /// <summary> 2 /// 新升级的武器规范 3 /// </summary> 4 public interface IWeaponUpgrade 5 { 6 /// <summary> 7 /// 是武器了,当然要具备***性了,不然也不叫武器 8 /// </summary> 9 void Attack(); 10 } 11 /// <summary> 12 /// 新升级的部件 支持携带武器(因为已经支持携带了武器,它自然而然的也归纳与武器一类) 13 /// 此部件为简化版(便于学习)——。 14 /// </summary> 15 public class ComUpgrade:IWeaponUpgrade 16 { 17 public void Attack() 18 { 19 Console.WriteLine("IronMan的某部件开始输出***:"); 20 } 21 }
所以这里的"部件"也就是"武器"了,因为"部件"是被动武器,它自身并没有***能力,它需要安装主动性的武器(也就是需要给它装饰上真正具有***性的武器), 那我们再来看一下主动性***武器的结构:
1 /// <summary> 2 /// 武器包装器,主动性***武器要实现。功能:可以塞入任何武器类型,并且使得塞入的武器获得此武器(可是实现了此类的子类)的功能 3 /// </summary> 4 public class WeaponDecorator : IWeaponUpgrade 5 { 6 protected IWeaponUpgrade weaponUpgrade; 7 public WeaponDecorator(IWeaponUpgrade weapon) 8 { 9 this.weaponUpgrade = weapon; 10 } 11 public virtual void Attack() 12 { 13 this.weaponUpgrade.Attack(); 14 } 15 } 16 /// <summary> 17 /// *** 18 /// </summary> 19 public class Knife : WeaponDecorator 20 { 21 public Knife(IWeaponUpgrade weapon) 22 : base(weapon) 23 { } 24 public override void Attack() 25 { 26 base.Attack(); 27 Console.WriteLine("******"); 28 } 29 } 30 /// <summary> 31 /// 锤子 32 /// </summary> 33 public class Hammer : WeaponDecorator 34 { 35 public Hammer(IWeaponUpgrade weapon) 36 : base(weapon) 37 { } 38 public override void Attack() 39 { 40 base.Attack(); 41 Console.WriteLine("锤子***"); 42 } 43 }
要使用的结构都定义好了,现在来看一下使用的情况:
1 ComUpgrade comupgrade = new ComUpgrade(); 2 Knife knife = new Knife(comupgrade); 3 Hammer hammer = new Hammer(knife); 4 hammer.Attack();
看一下结果 图1
这样的结构就是比较完美的了,"部件"(也就是被动武器)的变化或者是装饰武器(主动性武器)的变化两者间是不会受影响的,可以随便新增新的"武器"到"部件"上,而且装饰武器之间也是可以相互装饰的,对于扩展"部件"的功能,这种方式比继承漂亮多了。细心的人会发现,还有跟装饰的顺序有关系,是这样的。 对于功能的扩展或许体现不出来装饰顺序的优美,但是在业务流程的需求里就能体现了,这一点就好比是那种业务链,比如是:网上商场的业务,选择商品->加入购物车->付款(这里只是举例),这样的一条业务,也可以是 选择商品->付款,是的,都是可以直接付款的,这里就可以把“加入购物车”、“付款”定义为装饰者对象,可以把用户信息定义为被装饰者,可以是“加入购物车”然后再“付款”,也可是直接“付款”,想想看这样用装饰者模式是不是很简单的就实现了。
END
转载于:https://blog.51cto.com/jinyuan/1412747
C#设计模式之装饰者相关推荐
- Java设计模式(装饰者模式-组合模式-外观模式-享元模式)
Java设计模式Ⅳ 1.装饰者模式 1.1 装饰者模式概述 1.2 代码理解 2.组合模式 2.1 组合模式概述 2.2 代码理解 3.外观模式 3.1 外观模式概述 3.2 代码理解 4.享元模式 ...
- 前端也要学系列:设计模式之装饰者模式
什么是装饰者模式 今天我们来讲另外一个非常实用的设计模式:装饰者模式.这个名字听上去有些莫名其妙,不着急,我们先来记住它的一个别名:包装器模式. 我们记着这两个名字来开始今天的文章. 首先还是上< ...
- 设计模式 之 装饰者模式
2019独角兽企业重金招聘Python工程师标准>>> 设计模式 之 装饰者模式 装饰模式指的是在不必改变原类文件和使用继承的情况下,动态地扩展一个对象的功能.它是通过创建一个包装对 ...
- 【设计模式】装饰者模式 ( 概念 | 适用场景 | 优缺点 | 与继承对比 | 定义流程 | 运行机制 | 案例分析 )
文章目录 I . 装饰者模式概念 II . 装饰者模式适用场景 III . 装饰者模式优缺点 IV . 装饰者模式与继承对比 V . 装饰者模式相关设计模式 VI . 装饰者模式四个相关类 VII . ...
- 设计模式学习----装饰器模式
这两天本来是自在学习java collection Framework的Fail Fast底层机制,看到核心的部分时,突然意识到设计模式的问题,上大学到现在我还没有真正理解过设计模式的概念,于是用了大 ...
- 【设计模式】装饰器模式的使用
问题来源 我们在进行软件系统设计的时候,有一些业务(如下图,一些通用的非功能性需求)是多个模块都需要的,是跨越模块的.把它们放到什么地方呢? 最简单的办法就是把这些通用模块的接口写好,让程序员在实现业 ...
- C#设计模式(9)——装饰者模式(Decorator Pattern)
一.引言 在软件开发中,我们经常想要对一类对象添加不同的功能,例如要给手机添加贴膜,手机挂件,手机外壳等,如果此时利用继承来实现的话,就需要定义无数的类,如StickerPhone(贴膜是手机类).A ...
- go设计模式之装饰器模式
go设计模式之装饰器模式 再写这篇文章时,我已经看了很多其他人发表的类似文章,大概看了这么多吧. 亓斌的设计模式-装饰者模式(Go语言描述) jeanphorn的Golang设计模式之装饰模式 七八月 ...
- python中的装饰器、装饰器模式_python 设计模式之装饰器模式 Decorator Pattern
#写在前面 已经有一个礼拜多没写博客了,因为沉醉在了<妙味>这部小说里,里面讲的是一个厨师苏秒的故事.现实中大部分人不会有她的天分.我喜欢她的性格:总是想着去解决问题,好像从来没有怨天尤人 ...
- python 设计模式之装饰器模式 Decorator Pattern
#写在前面 已经有一个礼拜多没写博客了,因为沉醉在了<妙味>这部小说里,里面讲的是一个厨师苏秒的故事.现实中大部分人不会有她的天分.我喜欢她的性格:总是想着去解决问题,好像从来没有怨天尤人 ...
最新文章
- PMcaff茶话会 · 杭州 | 玩转社交产品的那些事儿
- 7-二路归并排序C实现(递增递减的简单转换)
- 微软2013年校园实习生招聘笔试题及答案
- AndroidManifest.xml清单文件要点
- fullpage常用配置
- Cli4.5.x 中使用axios请求数据
- Android之WindowManager+OpenGL+EGL绘制(十七)
- 【洛谷P3366】最小生成树(kruskal模版题+prim链式加边)
- esri开发大赛项目总结
- WPF界面设计的方法
- python使用大数据分析师工资待遇_2020年大数据分析师工资多少
- 搞定互联网安全的四大计划
- CAShapeLayer把图片做成圆形效果
- 思科本周发布一季财报:利润或继续下滑
- 远程计算机或许不支持所需的,WIN10远程计算机不支持所需的FIPS安全级别解决
- Java设计一个测桃花模块_20145209刘一阳《JAVA程序设计》第十五周补充测试
- 与技术无关,但却值得码农们好好读一读的怪书:禅与摩托车维修艺术
- 从零开始搭建服务器之登录和登出远程服务器
- NAND FLASH MT29F4G08
- (附源码)springboot停车场车辆定位管理可视化分析系统的设计与实现 毕业设计101702
热门文章
- 英特尔人工智能副总裁:AI不是一种技能,而是一种对于工作的描述
- 揭秘:机器究竟是怎么学习的?
- 德国人工智能研究中心波尔特:人工智能与工业4.0并驾齐驱
- IBM发布未来五年五大科技预测
- 假如鲁迅是程序员......
- “误用姓名”,前哈佛教授炮轰中国学者“碰瓷”:“整件事都让人讨厌!
- 头秃,在线求名字:网易使用昵称交流,再也没有“哥,姐,总”
- 阿里宣布开源Flutter应用框架Fish Redux!
- 软件接口数据一致性机制
- init 0-6 (启动级别:init 0,1,2,3,4,5,6)