蚌埠高端网站建设,页面推广策略有哪些,wordpress更改语言,深圳做网站信科为什么80%的码农都做不了架构师#xff1f; 前言 装饰者设计模式本来是很常用的模式#xff0c;常用到随处可见#xff0c;jdk的bio设计都是遵循这个模式的#xff0c;偶然的机会发现#xff0c;貌似jdk中bio的装饰者模式和设计模式中的装饰者设计模式却有… 为什么80%的码农都做不了架构师 前言 装饰者设计模式本来是很常用的模式常用到随处可见jdk的bio设计都是遵循这个模式的偶然的机会发现貌似jdk中bio的装饰者模式和设计模式中的装饰者设计模式却有点本质上的不同但是仔细想想貌似bio的设计貌似还有点违背设计模式的本意此文中把装饰者模式说成无用是因为他定义的这种规范的玩法大家貌似并不遵从反而更喜欢jdk中的用法。 类图 这个类图大家也并不陌生具体的被装饰的类和装饰者都是遵循同一个规范component此处如果component没有公共的定义方法那就是妥妥的面向接口编程。看这个用法我们也能猜到怎么用先创建被装饰的类然后用装饰类去修饰被装饰的类然后把引用给component调用operation的时候就把装饰的效果显示出来如果需求变更那么直接把装饰组合出来的过程改改其他代码不需要改变。 jdk bio的用法 作为装饰者模式的典型他的类图完全和上面的类图吻合但是我们的用法却大大不同我们包装后的IO类我们很少直接让接口来作为引用每一个装饰类都带了自己的新特性API都不一样了。我们想要用包装类的功能就必须使用包装类的引用否则就切面了我们能用到的只有接口的方法。他的侧重是不同的包装是不同的功能类似readline,只有bufferedreader有我们想用只能依靠这个包装类但是类本身也遵循接口所以也能传递给接口但是要损失包装的特性。 两种用法的对比 单纯从软件设计讲jdk io的设计扩展性不好因为你选择包装本来就是希望调用统一的方法这样对代码的修改最小。但现实是我们如果不用具体的类无法增加新的功能。也就是说你想体现新的功能的话后面的代码基本要重写。大家公有的那部分方法压根没有增强到这样写肯定会带来不小的隐患但很特殊的是他设计的是IO一般读取完就over,有传递的可能性但是用接口传过去后重新包装一下又可以使用了反正是各自包装各自的公有的方法都不用这样下来反而也没什么影响。要选择这么使用的话一定得慎重用不好就带来很多麻烦。 适合场景 一看类图大家基本就能感觉这个更像补救型的模式就是原来的类都实现好了现在突然要改需求给里面的部分类的方法都增加一种或者多种功能这样装饰者模式就派上用场了直接在建造对象的地方加一段装饰当然这个前提都是被装饰的类和装饰的类都是可以估计的遇到不可估计的情况还是直接用aop动态代理吧不要再考虑装饰模式。既然是补救行的那么也是有一定要求的。 起码最初的类图是这样的要不然还要添加接口等等这个肯定是不可取的POJO的话还是用动态代理的好。 另外一种适合情况就是多继承要对中间继承类需要增加这种情况用装饰者模式不会影响子类的功能。 和静态代理的区别 其实文中多次提到代理其实在功能单一的情况下代理和装饰都可以我最后想想还是从功能上做点区别装饰者适合新增的功能可以互相组合的情况及装饰类和装饰类是可以叠加操作的并且被装饰的方法还是较少的装饰的类的个数也是较少的。静态代理更适合类中方法很多但是只会代理一层出现多层代理基本就是不合理的典型的就是datasource中用自己的connection类代理jdbc中的connection类。 最后说几句 其实用装饰者模式带来种种功能上的好处但是一旦出现问题你自己写的代码还好要是让纯粹不知道的人走断点找问题那跟断点可就费事了所以一定留好设计文档和把类的名字起的见字生义。 转载于:https://my.oschina.net/xpbob/blog/662292
