- 浏览: 464699 次
- 性别:
- 来自: 北京
最新评论
-
lm818:
最近一直在看设计模式,发现写的那本研磨真的不错,容易理解,能看 ...
大讨论:学习和应用设计模式的经验、教训、疑问等 -
yjfnwxf:
看了楼主博文,真为自己汗颜呀。。。。努力,再努力
研磨设计模式之命令模式-5 -
fengdandanweikang:
...
研磨设计模式 之 观察者模式(Observer) 1——跟着cc学设计系列 -
tiansong163:
你好,对《研磨设计模式》中UML有一个图标不知道是什么意思?希 ...
跟着cc学设计 之 研磨设计模式 目录汇总贴 -
soualliron:
国人就会溜须拍马,文章冠题“大讨论”,下面全是附会之音,无切实 ...
大讨论:学习和应用设计模式的经验、教训、疑问等
3.3 装饰模式和AOP
装饰模式和AOP在思想上有共同之处。可能有些朋友还不太了解AOP,下面先简单介绍一下AOP的基础知识。
1:什么是AOP——面向方面编程
AOP是一种编程范式,提供从另一个角度来考虑程序结构以完善面向对象编程(OOP)。
在面向对象开发中,考虑系统的角度通常是纵向的,比如我们经常画出的如下的系统架构图,默认都是从上到下,上层依赖于下层,如图5所示:
图5 系统架构图示例图
而在每个模块内部呢?就拿大家都熟悉的三层架构来说,也是从上到下来考虑的,通常是表现层调用逻辑层,逻辑层调用数据层,如图6所示:
图6 三层架构示意图
慢慢的,越来越多的人发现,在各个模块之中,存在一些共性的功能,比如日志管理、事务管理等等,如图7所示:
图7 共性功能示意图
这个时候,在思考这些共性功能的时候,是从横向在思考问题,与通常面向对象的纵向思考角度不同,很明显,需要有新的解决方案,这个时候AOP站出来了。
AOP为开发者提供了一种描述横切关注点的机制,并能够自动将横切关注点织入到面向对象的软件系统中,从而实现了横切关注点的模块化。
AOP能够将那些与业务无关,却为业务模块所共同调用的逻辑或责任,例如事务处理、日志管理、权限控制等,封装起来,便于减少系统的重复代码,降低模块间的耦合度,并有利于未来的可操作性和可维护性。
AOP之所以强大,就是因为它能够自动把横切关注点的功能模块,自动织入回到软件系统中,这是什么意思呢?
先看看没有AOP,在常规的面向对象系统中,对这种共性的功能如何处理,大都是把这些功能提炼出来,然后在需要用到的地方进行调用,只画调用通用日志的公共模块,其它的类似,就不去画了,如图8所示:
图8 调用公共功能示意图
看清楚,是从应用模块中主动去调用公共模块,也就是应用模块要很清楚公共模块的功能,还有具体的调用方法才行,应用模块是依赖于公共模块的,是耦合的,这样一来,要想修改公共模块就会很困难了,牵一而发百。
看看有了AOP会怎样,还是画个图来说明,如图9所示:
图9 AOP的调用示意图
乍一看,跟上面不用AOP没有什么区别嘛,真的吗?看得仔细点,有一个非常非常大的改变,就是所有的箭头方向反过来了,原来是应用系统主动去调用各个公共模块的,现在变成了各个公共模块主动织入回到应用系统。
不要小看这一点变化,这样一来应用系统就不需要知道公共功能模块,也就是应用系统和公共功能解耦了。公共功能会在合适的时候,由外部织入回到应用系统中,至于谁来实现这样的功能,以及如何实现不再我们的讨论之列,我们更关注这个思想。
如果按照装饰模式来对比上述过程,业务功能对象就可以被看作是被装饰的对象,而各个公共的模块就好比是装饰器,可以透明的来给业务功能对象增加功能。
所以从某个侧面来说,装饰模式和AOP要实现的功能是类似的,只不过AOP的实现方法不同,会更加灵活,更加可配置;另外AOP一个更重要的变化是思想上的变化——“主从换位”,让原本主动调用的功能模块变成了被动等待,甚至毫不知情的情况下被织入了很多新的功能。
2:使用装饰模式做出类似AOP的效果
下面来演示一下使用装饰模式,把一些公共的功能,比如权限控制,日志记录,透明的添加回到业务功能模块中去,做出类似AOP的效果。
(1)首先定义业务接口
这个接口相当于装饰模式的Component。注意这里使用的是接口,而不像前面一样使用的是抽象类,虽然使用抽象类的方式来定义组件是装饰模式的标准实现方式,但是如果不需要为子类提供公共的功能的话,也是可以实现成接口的,这点要先说明一下,免得有些朋友会认为这就不是装饰模式了,示例代码如下:
/** * 商品销售管理的业务接口 */ public interface GoodsSaleEbi { /** * 保存销售信息,本来销售数据应该是多条,太麻烦了,为了演示,简单点 * @param user 操作人员 * @param customer 客户 * @param saleModel 销售数据 * @return 是否保存成功 */ public boolean sale(String user,String customer, SaleModel saleModel); }
顺便把封装业务数据的对象也定义出来,很简单,示例代码如下:
/** * 封装销售单的数据,简单的示意一些 */ public class SaleModel { /** * 销售的商品 */ private String goods; /** * 销售的数量 */ private int saleNum; public String getGoods() { return goods; } public void setGoods(String goods) { this.goods = goods; } public int getSaleNum() { return saleNum; } public void setSaleNum(int saleNum) { this.saleNum = saleNum; } public String toString(){ return "商品名称="+goods+",购买数量="+saleNum; } }
(2)定义基本的业务实现对象,示例代码如下:
public class GoodsSaleEbo implements GoodsSaleEbi{ public boolean sale(String user,String customer, SaleModel saleModel) { System.out.println(user+"保存了" +customer+"购买 "+saleModel+" 的销售数据"); return true; } }
(3)接下来该来实现公共功能了,把这些公共功能实现成为装饰器,那么需要给它们定义一个抽象的父类,示例如下:
/** * 装饰器的接口,需要跟被装饰的对象实现同样的接口 */ public abstract class Decorator implements GoodsSaleEbi{ /** * 持有被装饰的组件对象 */ protected GoodsSaleEbi ebi; /** * 通过构造方法传入被装饰的对象 * @param ebi被装饰的对象 */ public Decorator(GoodsSaleEbi ebi){ this.ebi = ebi; } }
(4)实现权限控制的装饰器
先检查是否有运行的权限,如果有就继续调用,如果没有,就不递归调用了,而是输出没有权限的提示,示例代码如下:
/** * 实现权限控制 */ public class CheckDecorator extends Decorator{ public CheckDecorator(GoodsSaleEbi ebi){ super(ebi); } public boolean sale(String user,String customer , SaleModel saleModel) { //简单点,只让张三执行这个功能 if(!"张三".equals(user)){ System.out.println("对不起"+user +",你没有保存销售单的权限"); //就不再调用被装饰对象的功能了 return false; }else{ return this.ebi.sale(user,customer,saleModel); } } }
(5)实现日志记录的装饰器,就是在功能执行完成后记录日志即可,示例代码如下:
/** * 实现日志记录 */ public class LogDecorator extends Decorator{ public LogDecorator(GoodsSaleEbi ebi){ super(ebi); } public boolean sale(String user,String customer, SaleModel saleModel) { //执行业务功能 boolean f = this.ebi.sale(user, customer, saleModel); //在执行业务功能过后,记录日志 DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss SSS"); System.out.println("日志记录:"+user+"于"+ df.format(new Date())+"时保存了一条销售记录,客户是" +customer+",购买记录是"+saleModel); return f; } }
(6)组合使用这些装饰器
在组合的时候,权限控制应该是最先被执行的,所以把它组合在最外面,日志记录的装饰器会先调用原始的业务对象,所以把日志记录的装饰器组合在中间。
前面讲过,装饰器之间最好不要有顺序限制,但是在实际应用中,要根据具体的功能要求来,有需要的时候,也可以有顺序的限制,但应该尽量避免这种情况。
此时客户端测试代码示例如下:
public class Client { public static void main(String[] args) { //得到业务接口,组合装饰器 GoodsSaleEbi ebi = new CheckDecorator( new LogDecorator( new GoodsSaleEbo())); //准备测试数据 SaleModel saleModel = new SaleModel(); saleModel.setGoods("Moto手机"); saleModel.setSaleNum(2); //调用业务功能 ebi.sale("张三","张三丰", saleModel); ebi.sale("李四","张三丰", saleModel); } }
运行结果如下:
好好体会一下,是不是也在没有惊动原始业务对象的情况下,给它织入了新的功能呢?也就是说是在原始业务不知情的情况下,给原始业务对象透明的增加了新功能,从而模拟实现了AOP的功能。
事实上,这种做法,完全可以应用在项目开发上,在后期为项目的业务对象添加数据检查、权限控制、日志记录等功能,就不需要在业务对象上去处理这些功能了,业务对象可以更专注于具体业务的处理。
3.4 装饰模式的优缺点
- 比继承更灵活
从为对象添加功能的角度来看,装饰模式比继承来得更灵活。继承是静态的,而且一旦继承是所有子类都有一样的功能。而装饰模式采用把功能分离到每个装饰器当中,然后通过对象组合的方式,在运行时动态的组合功能,每个被装饰的对象,最终有哪些功能,是由运行期动态组合的功能来决定的。 - 更容易复用功能
装饰模式把一系列复杂的功能,分散到每个装饰器当中,一般一个装饰器只实现一个功能,这样实现装饰器变得简单,更重要的是这样有利于装饰器功能的复用,可以给一个对象增加多个同样的装饰器,也可以把一个装饰器用来装饰不同的对象,从而复用装饰器的功能。 - 简化高层定义
装饰模式可以通过组合装饰器的方式,给对象增添任意多的功能,因此在进行高层定义的时候,不用把所有的功能都定义出来,而是定义最基本的就可以了,可以在使用需要的时候,组合相应的装饰器来完成需要的功能。 - 会产生很多细粒度对象
前面说了,装饰模式是把一系列复杂的功能,分散到每个装饰器当中,一般一个装饰器只实现一个功能,这样会产生很多细粒度的对象,而且功能越复杂,需要的细粒度对象越多。
3.5 思考装饰模式
1:装饰模式的本质
装饰模式的本质:动态组合。
动态是手段,组合才是目的。这里的组合有两个意思,一个是动态功能的组合,也就是动态进行装饰器的组合;另外一个是指对象组合,通过对象组合来实现为被装饰对象透明的增加功能。
但是要注意,装饰模式不仅仅可以增加功能,也可以控制功能的访问,可以完全实现新的功能,还可以控制装饰的功能是在被装饰功能之前还是之后来运行等。
总之,装饰模式是通过把复杂功能简单化,分散化,然后在运行期间,根据需要来动态组合的这么一个模式。
2:何时选用装饰模式
建议在如下情况中,选用装饰模式:
- 如果需要在不影响其它对象的情况下,以动态、透明的方式给对象添加职责,可以使用装饰模式,这几乎就是装饰模式的主要功能
- 如果不合适使用子类来进行扩展的时候,可以考虑使用装饰模式,因为装饰模式是使用的“对象组合”的方式。所谓不适合用子类扩展的方式,比如:扩展功能需要的子类太多,造成子类数目呈爆炸性增长。
3.6 相关模式
- 装饰模式与适配器模式
这是两个没有什么关联的模式,放到一起来说,是因为它们有一个共同的别名:Wrapper。
这两个模式功能上是不一样的,适配器模式是用来改变接口的,而装饰模式是用来改变对象功能的。 - 装饰模式与组合模式
这两个模式有相似之处,都涉及到对象的递归调用,从某个角度来说,可以把装饰看成是只有一个组件的组合。
但是它们的目的完全不一样,装饰模式是要动态的给对象增加功能;而组合模式是想要管理组合对象和叶子对象,为它们提供一个一致的操作接口给客户端,方便客户端的使用。 - 装饰模式与策略模式
这两个模式可以组合使用。
策略模式也可以实现动态的改变对象的功能,但是策略模式只是一层选择,也就是根据策略选择一下具体的实现类而已。而装饰模式不是一层,而是递归调用,无数层都可以,只要组合好装饰器的对象组合,那就可以依次调用下去,所以装饰模式会更灵活。
而且策略模式改变的是原始对象的功能,不像装饰模式,后面一个装饰器,改变的是经过前一个装饰器装饰过后的对象,也就是策略模式改变的是对象的内核,而装饰模式改变的是对象的外壳。
这两个模式可以组合使用,可以在一个具体的装饰器里面使用策略模式,来选择更具体的实现方式。比如前面计算奖金的另外一个问题就是参与计算的基数不同,奖金的计算方式也是不同的。举例来说:假设张三和李四参与同一个奖金的计算,张三的销售总额是2万元,而李四的销售额是8万元,它们的计算公式是不一样的,假设奖金的计算规则是,销售额在5万以下,统一3%,而5万以上,5万内是4%,超过部分是6%。
参与同一个奖金的计算,这就意味着可以使用同一个装饰器,但是在装饰器的内部,不同条件下计算公式不一样,那么怎么选择具体的实现策略呢?自然使用策略模式就好了,也就是装饰模式和策略模式组合来使用。 - 装饰模式与模板方法模式
这是两个功能上有相似点的模式。
模板方法模式主要应用在算法骨架固定的情况,那么要是算法步骤不固定呢,也就是一个相对动态的算法步骤,就可以使用装饰模式了,因为在使用装饰模式的时候,进行装饰器的组装,其实也相当于是一个调用算法步骤的组装,相当于是一个动态的算法骨架。
既然装饰模式可以实现动态的算法步骤的组装和调用,那么把这些算法步骤固定下来,那就是模板方法模式实现的功能了,因此装饰模式可以模拟实现模板方法模式的功能。
但是请注意,仅仅只是可以模拟功能而已,两个模式的设计目的、原本的功能、本质思想等都是不一样的。
装饰模式结束,谢谢观赏
评论
public class Client { public static void main(String[] args) { //得到业务接口,组合装饰器 GoodsSaleEbi ebi = new CheckDecorator( new LogDecorator( new GoodsSaleEbo())); //准备测试数据 SaleModel saleModel = new SaleModel(); saleModel.setGoods("Moto手机"); saleModel.setSaleNum(2); //调用业务功能 ebi.sale("张三","张三丰", saleModel); ebi.sale("李四","张三丰", saleModel); } }
以下您的注释:
好好体会一下,是不是也在没有惊动原始业务对象的情况下,给它织入了新的功能呢?也就是说是在原始业务不知情的情况下,给原始业务对象透明的增加了新功能,从而模拟实现了AOP的功能。
事实上,这种做法,完全可以应用在项目开发上,在后期为项目的业务对象添加数据检查、权限控制、日志记录等功能,就不需要在业务对象上去处理这些功能了,业务对象可以更专注于具体业务的处理。
我是在想,业务对象的初始化应该也属于业务代码的编写,就是这个:
GoodsSaleEbi ebi = new CheckDecorator(
new LogDecorator(
new GoodsSaleEbo()));
按照您的意思,用装饰者模式来实现AOP是不是意味着我所有调用业务实体的地方初始话方式都需要类似上面的这种包装new的方式了??这个还是耦合进业务代码里了啊,假如我的应用已经上线了,如果有新的需要添加一个新的AOP功能,是不是需要修改所有的new方式加一层装饰类呢??
目前的许多AOP实现是在不更改原有业务代码的基础上用配置文件或是修改CLASS来实现的,这样对于开发人员来说,他才真正只需要专注业务代码了.
对于装饰者模式您感觉您讲解的很清晰,就是对于上面您的这个说法还有点疑惑???
确实如你所写的那样,客户端需要“包装new的方式”,所以是模拟AOP实现。
现在真正AOP的实现,多是采用了动态代理的方式。
其实你也可以把这个“客户端包装new的方式”做成动态的,比如通过读取配置文件来组装的方式,也可以避免在后期添加功能的时候去修改代码。
public class Client { public static void main(String[] args) { //得到业务接口,组合装饰器 GoodsSaleEbi ebi = new CheckDecorator( new LogDecorator( new GoodsSaleEbo())); //准备测试数据 SaleModel saleModel = new SaleModel(); saleModel.setGoods("Moto手机"); saleModel.setSaleNum(2); //调用业务功能 ebi.sale("张三","张三丰", saleModel); ebi.sale("李四","张三丰", saleModel); } }
以下您的注释:
好好体会一下,是不是也在没有惊动原始业务对象的情况下,给它织入了新的功能呢?也就是说是在原始业务不知情的情况下,给原始业务对象透明的增加了新功能,从而模拟实现了AOP的功能。
事实上,这种做法,完全可以应用在项目开发上,在后期为项目的业务对象添加数据检查、权限控制、日志记录等功能,就不需要在业务对象上去处理这些功能了,业务对象可以更专注于具体业务的处理。
我是在想,业务对象的初始化应该也属于业务代码的编写,就是这个:
GoodsSaleEbi ebi = new CheckDecorator(
new LogDecorator(
new GoodsSaleEbo()));
按照您的意思,用装饰者模式来实现AOP是不是意味着我所有调用业务实体的地方初始话方式都需要类似上面的这种包装new的方式了??这个还是耦合进业务代码里了啊,假如我的应用已经上线了,如果有新的需要添加一个新的AOP功能,是不是需要修改所有的new方式加一层装饰类呢??
目前的许多AOP实现是在不更改原有业务代码的基础上用配置文件或是修改CLASS来实现的,这样对于开发人员来说,他才真正只需要专注业务代码了.
对于装饰者模式您感觉您讲解的很清晰,就是对于上面您的这个说法还有点疑惑???
{
print '拍照';
}
当要装饰的行为超过一个的时候该怎么处理呢?
就是比如我有一个手机类,定义了两个接口,发信息,打电话,所有的子类都实现这两个方法,而手机装饰类来装饰手机类,比如有摄像头、耳机、数据线等外接装饰,当单独给手机装饰一个行为时候可以用装饰者实现,可是同时装饰两个行为的时候,发现是调用不到另一个行为了,这个时候该怎么处理呢?
不是很明白你的问题。
装饰器装饰的本身是组件对象,而不是行为,组件对象有多少个行为都可以,所以不会存在 “同时装饰两个行为的时候,发现是调用不到另一个行为了” 这种情况。
要不你把你的代码贴出来看看。
我用的是php,大致是如下的:
// 定义一个手机接口 可以发短信打电话 interface IMobile { public function sendMessage(); public function callSomeone(); } // 装饰者父类 abstract class DecoratorMobile implements IMobile { protected $_mobile; public function __construct(IMobile $mobile) { $this->_mobile = $mobile; } public function sendMessage() { return $this->_mobile->sendMessage(); } public function callSomeone() { return $this->_mobile->callSomeone(); } } // 摄像头 class CameraDecoratorMobile extends DecoratorMobile { public function takePhoto() { print '拍照'; } } // 数据线 class DatalineDecoratorMobile extends DecoratorMobile { public function connectComputer() { print '连接电脑'; } }
当我想同时将拍照和连接电脑的行为附加上去的时候,就会发现同时只能加一个组件了
觉得你这应该用继承而不是装饰,除非你在发短信或者打电话的时候会自动拍照或者连接电脑,这时才需要装饰。也就是装饰只是同接口下扩展功能,如何接口本身扩展了,那就是该是继承了。
不知我的理解是否正确,期待看到博主更精辟的见解。这是个很好的问题,搞清楚很有助理解。
A6_Acan兄的理解是对的,cl51287兄使用的装饰模式是有问题的。
装饰模式是在已有的功能上添加新的功能,装饰器和原有的组件调用的都是同一个方法,也就是A6_Acan兄说的:“除非你在发短信或者打电话的时候会自动拍照或者连接电脑”,也就是类似于在发短信的功能上增加拍照的功能,这种情况下才适用装饰模式。
对于cl51287兄的使用场景,是希望在一个已有的对象结构上增加新的功能,可以考虑使用访问者模式。
嗯,明白了,谢楼主和A6_Acan兄了,呵呵
{
print '拍照';
}
当要装饰的行为超过一个的时候该怎么处理呢?
就是比如我有一个手机类,定义了两个接口,发信息,打电话,所有的子类都实现这两个方法,而手机装饰类来装饰手机类,比如有摄像头、耳机、数据线等外接装饰,当单独给手机装饰一个行为时候可以用装饰者实现,可是同时装饰两个行为的时候,发现是调用不到另一个行为了,这个时候该怎么处理呢?
不是很明白你的问题。
装饰器装饰的本身是组件对象,而不是行为,组件对象有多少个行为都可以,所以不会存在 “同时装饰两个行为的时候,发现是调用不到另一个行为了” 这种情况。
要不你把你的代码贴出来看看。
我用的是php,大致是如下的:
// 定义一个手机接口 可以发短信打电话 interface IMobile { public function sendMessage(); public function callSomeone(); } // 装饰者父类 abstract class DecoratorMobile implements IMobile { protected $_mobile; public function __construct(IMobile $mobile) { $this->_mobile = $mobile; } public function sendMessage() { return $this->_mobile->sendMessage(); } public function callSomeone() { return $this->_mobile->callSomeone(); } } // 摄像头 class CameraDecoratorMobile extends DecoratorMobile { public function takePhoto() { print '拍照'; } } // 数据线 class DatalineDecoratorMobile extends DecoratorMobile { public function connectComputer() { print '连接电脑'; } }
当我想同时将拍照和连接电脑的行为附加上去的时候,就会发现同时只能加一个组件了
觉得你这应该用继承而不是装饰,除非你在发短信或者打电话的时候会自动拍照或者连接电脑,这时才需要装饰。也就是装饰只是同接口下扩展功能,如何接口本身扩展了,那就是该是继承了。
不知我的理解是否正确,期待看到博主更精辟的见解。这是个很好的问题,搞清楚很有助理解。
A6_Acan兄的理解是对的,cl51287兄使用的装饰模式是有问题的。
装饰模式是在已有的功能上添加新的功能,装饰器和原有的组件调用的都是同一个方法,也就是A6_Acan兄说的:“除非你在发短信或者打电话的时候会自动拍照或者连接电脑”,也就是类似于在发短信的功能上增加拍照的功能,这种情况下才适用装饰模式。
对于cl51287兄的使用场景,是希望在一个已有的对象结构上增加新的功能,可以考虑使用访问者模式。
当要装饰的行为超过一个的时候该怎么处理呢?
就是比如我有一个手机类,定义了两个接口,发信息,打电话,所有的子类都实现这两个方法,而手机装饰类来装饰手机类,比如有摄像头、耳机、数据线等外接装饰,当单独给手机装饰一个行为时候可以用装饰者实现,可是同时装饰两个行为的时候,发现是调用不到另一个行为了,这个时候该怎么处理呢?
不是很明白你的问题。
装饰器装饰的本身是组件对象,而不是行为,组件对象有多少个行为都可以,所以不会存在 “同时装饰两个行为的时候,发现是调用不到另一个行为了” 这种情况。
要不你把你的代码贴出来看看。
我用的是php,大致是如下的:
// 定义一个手机接口 可以发短信打电话 interface IMobile { public function sendMessage(); public function callSomeone(); } // 装饰者父类 abstract class DecoratorMobile implements IMobile { protected $_mobile; public function __construct(IMobile $mobile) { $this->_mobile = $mobile; } public function sendMessage() { return $this->_mobile->sendMessage(); } public function callSomeone() { return $this->_mobile->callSomeone(); } } // 摄像头 class CameraDecoratorMobile extends DecoratorMobile { public function takePhoto() { print '拍照'; } } // 数据线 class DatalineDecoratorMobile extends DecoratorMobile { public function connectComputer() { print '连接电脑'; } }
当我想同时将拍照和连接电脑的行为附加上去的时候,就会发现同时只能加一个组件了
觉得你这应该用继承而不是装饰,除非你在发短信或者打电话的时候会自动拍照或者连接电脑,这时才需要装饰。也就是装饰只是同接口下扩展功能,如何接口本身扩展了,那就是该是继承了。
不知我的理解是否正确,期待看到博主更精辟的见解。这是个很好的问题,搞清楚很有助理解。
当要装饰的行为超过一个的时候该怎么处理呢?
就是比如我有一个手机类,定义了两个接口,发信息,打电话,所有的子类都实现这两个方法,而手机装饰类来装饰手机类,比如有摄像头、耳机、数据线等外接装饰,当单独给手机装饰一个行为时候可以用装饰者实现,可是同时装饰两个行为的时候,发现是调用不到另一个行为了,这个时候该怎么处理呢?
不是很明白你的问题。
装饰器装饰的本身是组件对象,而不是行为,组件对象有多少个行为都可以,所以不会存在 “同时装饰两个行为的时候,发现是调用不到另一个行为了” 这种情况。
要不你把你的代码贴出来看看。
我用的是php,大致是如下的:
// 定义一个手机接口 可以发短信打电话 interface IMobile { public function sendMessage(); public function callSomeone(); } // 装饰者父类 abstract class DecoratorMobile implements IMobile { protected $_mobile; public function __construct(IMobile $mobile) { $this->_mobile = $mobile; } public function sendMessage() { return $this->_mobile->sendMessage(); } public function callSomeone() { return $this->_mobile->callSomeone(); } } // 摄像头 class CameraDecoratorMobile extends DecoratorMobile { public function takePhoto() { print '拍照'; } } // 数据线 class DatalineDecoratorMobile extends DecoratorMobile { public function connectComputer() { print '连接电脑'; } }
当我想同时将拍照和连接电脑的行为附加上去的时候,就会发现同时只能加一个组件了
当要装饰的行为超过一个的时候该怎么处理呢?
就是比如我有一个手机类,定义了两个接口,发信息,打电话,所有的子类都实现这两个方法,而手机装饰类来装饰手机类,比如有摄像头、耳机、数据线等外接装饰,当单独给手机装饰一个行为时候可以用装饰者实现,可是同时装饰两个行为的时候,发现是调用不到另一个行为了,这个时候该怎么处理呢?
不是很明白你的问题。
装饰器装饰的本身是组件对象,而不是行为,组件对象有多少个行为都可以,所以不会存在 “同时装饰两个行为的时候,发现是调用不到另一个行为了” 这种情况。
要不你把你的代码贴出来看看。
当要装饰的行为超过一个的时候该怎么处理呢?
就是比如我有一个手机类,定义了两个接口,发信息,打电话,所有的子类都实现这两个方法,而手机装饰类来装饰手机类,比如有摄像头、耳机、数据线等外接装饰,当单独给手机装饰一个行为时候可以用装饰者实现,可是同时装饰两个行为的时候,发现是调用不到另一个行为了,这个时候该怎么处理呢?
我们都很期待
发表评论
-
私塾在线推出《一案贯通GoF设计模式》项目实战
2012-10-19 22:12 20《研磨设计模式》出版以来,包括iteye上的朋友,很多人 ... -
研磨设计模式 之 组合模式(Composite) 3——跟着cc学设计系列
2012-08-22 08:50 419815.3 模式讲解 15.3.1 认识组合模式 ... -
研磨设计模式 之 组合模式(Composite) 2——跟着cc学设计系列
2012-08-20 13:53 335615.2 解决方案 15.2.1 组合模式来解决 ... -
研磨设计模式 之 组合模式(Composite) 1——跟着cc学设计系列
2012-08-20 12:17 306815.1 场景问题 15.1.1 商品类别树 ... -
研磨设计模式 之 迭代器模式(Iterator)3——跟着cc学设计系列
2012-08-19 07:07 380114.3 模式讲解 14.3.1 ... -
研磨设计模式 之 迭代器模式(Iterator)2——跟着cc学设计系列
2012-08-18 03:48 260114.2 解决方案 14.2.1 ... -
研磨设计模式 之 迭代器模式(Iterator)2——跟着cc学设计系列
2012-08-17 18:26 10614.2 解决方案 14.2.1 ... -
研磨设计模式 之 迭代器模式(Iterator)1——跟着cc学设计系列
2012-08-17 10:38 202114.1 场景问题 14.1.1 ... -
私塾在线《研磨设计模式》,精品课程上线特大惊喜
2012-08-17 10:03 6014《研磨设计模式》——跟着CC学设计,视频课程在 私塾在线 ... -
研磨设计模式 之 观察者模式(Observer) 3——跟着cc学设计系列
2012-08-16 08:51 296612.3 模式讲解 12.3.1 认识观察者模式 ... -
研磨设计模式 之 观察者模式(Observer) 2——跟着cc学设计系列
2012-08-15 07:03 282612.2 解决方案 12.2 ... -
研磨设计模式 之 观察者模式(Observer) 1——跟着cc学设计系列
2012-08-15 07:03 210812.1 场景问题 12.1.1 订阅报纸的过程 ... -
跟着cc学设计系列 之 研磨设计模式 目录汇总贴
2012-08-14 14:49 36研磨设计模式 的 前言 ——跟着cc学 ... -
研磨设计模式 之 代理模式(Proxy)3——跟着cc学设计系列
2012-08-14 14:36 230511.3 模式讲解 11.3.1 认识代理模式 ... -
研磨设计模式 之 代理模式(Proxy)2——跟着cc学设计系列
2012-08-13 12:36 285811.2 解决方案 11.2.1 代理模式来解 ... -
研磨设计模式 之 代理模式(Proxy)1——跟着cc学设计系列
2012-08-13 12:35 214511.1 场景问题 11.1.1 访问多条数据 ... -
研磨设计模式 之 中介者模式(Mediator)3 ——跟着cc学设计系列
2012-08-11 11:50 120510.3 模式讲解 10.3.1 认识中介者模式 ... -
研磨设计模式 之 中介者模式(Mediator)2 ——跟着cc学设计系列
2012-08-09 08:23 142610.2 解决方案 10.2.1 中介者模式来 ... -
研磨设计模式 之 中介者模式(Mediator)1 ——跟着cc学设计系列
2012-08-09 08:23 146810.1 场景问题 10.1.1 ... -
研磨设计模式 之 原型模式(Prototype)3 ——跟着cc学设计系列
2012-08-08 08:14 15449.3 模式讲解 9.3.1 ...
相关推荐
《研磨设计模式源码》是一份非常宝贵的资源,它提供了设计模式的实践代码,帮助开发者深入理解并应用这些模式。设计模式是软件工程中经过长期实践总结出来的一套通用解决方案,它们描述了在特定场景下如何解决常见...
《研磨设计模式》完整覆盖GoF讲述的23个设计模式并加以细细研磨。初级内容从基本讲起,包括每个模式的定义、功能、思路、结构、基本实现、运行调用顺序、基本应用示例等,让读者能系统、完整、准确地掌握每个模式,...
《研磨设计模式》是一本深入探讨软件设计原则与实践的经典书籍,其配套源代码提供了丰富的实例,帮助读者更好地理解和应用各种设计模式。这个UTF-8格式的压缩包包含了书中介绍的各种设计模式的实现,是学习和研究...
以上只是设计模式中的一部分,研磨设计模式的配套源代码可能涵盖了这些或更多的模式。通过学习这些源代码,你可以更深入地理解每个模式的实现细节,以及如何在实际项目中灵活应用。这将有助于提升你的编程技能,使...
《研磨设计模式》这本书是陈臣和王斌两位作者合作的成果,专注于讲解软件设计中的模式应用。设计模式是软件工程中的一种最佳实践,它总结了在特定上下文中解决问题的常见方法,使得开发者可以复用这些解决方案,提高...
《研磨设计模式》是一本深入探讨软件设计模式的书籍,其配套源代码包含了许多经典设计模式的实际应用示例。这些源代码可以帮助读者更直观地理解设计模式的原理和使用方法,进一步提升软件开发能力。 设计模式是软件...
《研磨设计模式》是由陈臣和王斌合著,由清华大学出版社出版的一本深入探讨设计模式的专业书籍。设计模式是软件工程中的一个重要概念,它代表了在特定上下文中解决问题的常见方法,经过时间和实践的验证,具有很高的...
《研磨设计模式》是一本深入探讨软件设计模式的书籍,配套源代码是作者为了帮助读者更好地理解和应用书中介绍的设计模式而提供的实践示例。设计模式是软件开发中经过实践检验的、解决常见问题的模板,它为软件设计...
《研磨设计模式》这本书是软件开发领域中的经典之作,主要关注的是面向对象设计中的设计模式。设计模式是在特定上下文中解决常见问题的最佳实践,它为开发者提供了在类似情况下重复使用解决方案的模板,有助于提高...
这个压缩包“研磨设计模式全部源代码”包含了多种设计模式的实现,这些模式可以帮助开发者写出更可维护、可扩展和可复用的代码。下面将详细讲解其中可能包含的一些重要设计模式及其应用。 1. 工厂模式:这是最简单...
这个“研磨设计模式博文集”显然是一份深入探讨设计模式的资料集合,其中可能包含了对多种设计模式的详细解析、示例代码以及实际应用中的经验分享。在软件开发中,设计模式能够帮助开发者提高代码质量、可读性和可...
研磨设计模式是一本深入探讨软件设计原则与实践的书籍,其讲课PPT为我们提供了丰富的设计模式知识。设计模式是软件工程中经过实践验证的、解决常见问题的模板,是经验丰富的开发人员智慧的结晶。这些模式可以帮助...
《研磨设计模式》是一本深入探讨软件设计模式的经典书籍,源代码包含了书中所讲解的各种设计模式的实际应用示例。设计模式是软件工程中的重要概念,它们是经过反复验证、在特定情境下解决常见问题的有效解决方案。...
《研磨设计模式》完整覆盖GoF讲述的23个设计模式并加以细细研磨。初级内容从基本讲起,包括每个模式的定义、功能、思路、结构、基本实现、运行调用顺序、基本应用示例等,让读者能系统、完整、准确地掌握每个模式,...
《研磨设计模式》完整覆盖GoF讲述的23个设计模式并加以细细研磨。初级内容从基本讲起,包括每个模式的定义、功能、思路、结构、基本实现、运行调用顺序、基本应用示例等,让读者能系统、完整、准确地掌握每个模式,...
"研磨设计模式 演示源代码"这个资源包含了对设计模式的详细解释和实例分析,旨在帮助学习者深入理解和应用这些模式。 1. **单例模式**:确保一个类只有一个实例,并提供一个全局访问点。在资源管理、缓存或者线程池...
《研磨设计模式》完整覆盖GoF讲述的23个设计模式并加以细细研磨。初级内容从基本讲起,包括每个模式的定义、功能、思路、结构、基本实现、运行调用顺序、基本应用示例等,让读者能系统、完整、准确地掌握每个模式,...
《研磨设计模式》完整覆盖GoF讲述的23个设计模式并加以细细研磨。初级内容从基本讲起,包括每个模式的定义、功能、思路、结构、基本实现、运行调用顺序、基本应用示例等,让读者能系统、完整、准确地掌握每个模式,...
这个名为“研磨设计模式视频课程PPT”的压缩包包含了一份关于23种核心设计模式的详细教学资料,旨在帮助开发者提升软件设计的效率和可维护性。下面将对这些设计模式进行深入解析。 1. **单例模式(Singleton)**:...
《研磨设计模式》实战是IT领域中关于软件设计的一份重要资料,它主要探讨了设计模式在实际项目中的应用。设计模式是软件工程中经过长期实践总结出的通用问题解决方案,是解决常见设计问题的经验总结。这份PPT可能是...