每日设计模式——适配器模式

      适配器模式,将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。在C++中,因为支持多重继承,要注意客户希望的那个接口使用公共继承,原来的接口使用私有继承。但是,多重继承这档子事容易出现各种错误,还是单一继承比较好。所以,原来的类可以实例化其一个对象,然后对其对象进行操作,这样出错的几率就比较低了。不过这只是个人看法啊,也没有从效率角度考虑这个问题,不过估计这样做效率会比较低,但是从整体产品的角度来说,安全还是第一位的。再强调一下,个人看法,各位请保留自己的意见。

      Gof的设计模式里面举得那个绘图编辑器的例子没看懂。不过适配器模式的适用性还是要强调一下的。当某个已经存在的类的接口不符合当前要求,我们又要用它时可以考虑适配器模式;当我们像创建一个可以复用的类,而且这个类可以与其他不相关的类或者不可预见的类协同工作;想使用一些已经存在的子类,但是不可能对每一个都进行子类化以匹配其接口,可以用对象适配器适配其父类接口。

      《大话设计模式》里举得例子是姚明上NBA打球,但是刚去了不会说英语,听不懂教练和队友在说什么,也不能要求姚明一下子就把口语和听力搞定,也不能要求那些教练和队员听得懂讲的了中文,所以要引入一个翻译,这个翻译负责把教练和队友的意思解释给姚明听。那么这个翻译就是传说中的适配器。这里有个前提,姚明去NBA打球而不是去华尔街投资,他的问题是他可以和教练及队员协作,但是没法交流,只要有个翻译,训练方式、配合方式这些专业方面的东西其实都差不多。如果姚明是去华尔街投资就麻烦了,因为他不是搞投资的,而且他英语当时很烂,而且那时候他也没啥钱,这个问题就需要昨天我们学习的代理模式和今天这个适配器模式共同解决了,姚明同志只要提供money就可以解决这个问题。

      不过,不管怎么说,其实适配器模式是一个亡羊补牢的模式,在设计中是迫不得已才用。如果能在设计之初就统一好接口和各个标准的话,怎么会有接口不同没法协作的问题。因此,在古剑里,还真是很难找到这样的例子啊……这个容我想想,其实我还是希望古剑里面用不到这个模式,因为我觉得这个模式肯定会降低性能……个人感觉啊……

      以下是实现过程。

 

target.h 文件

 

target.cpp 文件

 

adaptee.h 文件

 

adaptee.cpp 文件

 

adapter.h 文件

 

adapter.cpp 文件

 

main.cpp 文件

 

运行结果

 

 

      话说离6月20号越来越近了,真是越来越没底……能看游戏开发的时间也就每天晚上这么一会……属实还是看不了多少……要是还有个一年半载的,每天能坚持这么长时间的话,估计还真能小有所成。可是现在看起来,还真是悬……一个礼拜就累得没样子了,而且还搞得内分泌系统紊乱……看来我的抗压指数有待提升啊……嗯,不管怎么说,都要拼一把,如果不去拼一把,怎么知道有没有希望,不怕失败,怕的是试都不敢去尝试。不管怎么说,努力吧!高考都熬过来了,还有什么熬不过来的!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值