发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA
1 2 下一页 Go 2

THIS MESSAGE HAS BEEN MASKED

    
2003-08-28 15:06
赞助商链接

THIS MESSAGE HAS BEEN MASKED

2003-08-28 16:32

不错, Decorator模式重要一点是接口没有变。

2003-08-28 18:30

接口没有变是根本,有另外一点也很重要,就是抽象Decorator要有一个被装饰类(具体类或者抽象类)的实例,通过这个实例来调用抽象接口的功能,而不是简单的在Decorator(抽象的或者具体的)的子类中直接通过super来调用.

2003-08-29 10:50

后者和Adapter模式就类似了。

2003-09-10 17:36

"Decorator模式的真正的威力在于对于一个被装饰(被油漆)的Decoratee提供多个Decorator的时候,也就是说,有多个额外的功能要被动态的刷到Decoratee中去,而这些功能在编译阶段并不能确定要具体增加那一些,而且增加的这些功能还有可能通过不同的组合完成不同的功能,这个时候使用Decorator模式的优势就很大了."

被装卸的功能多了,很可能就变成灾难了。如果A a = new Decorator1 ( new Decorator2() );是可以接受的话,那么A a = new Decorator1 ( new Decorator2(new Decorator3(new Decorator4(new Decorator5(new Decorator6(new Decorator7()))))) );的感觉如何。
并且,实际使用中,并不是new Decorator1,2,3这种规则排列,而是一堆名字相似的CLASS互为构造器的入参。想体念这种感觉,写一个特别复杂的JAVA IO就可以体念到了。个人认为,这种代码难写难读,也就谈不上好维护了。

本质上,Decorator通过继承增加功能,当功能组合特别复杂时,n层的继承就不可避免了。这种情况下,倒不如增加一个组合上述功能的代理类,感觉更好一些。这样,就用n个类的组合代替了n层的继承。接口也不会发生变化。

纯Decorator模式,只合适用在增加2-4个功能的情况吧.



2Go 1 2 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系反馈 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com