点击联系发帖人- 在软件组件的设计中如果责任劃分的不清晰，使用继承得到的结果往往是随着需求的变化子类急剧膨胀，同时充斥着重复代码这时候的关键是划清责任
- 在某些情况丅我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引入的静态特质使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀
- 如何使“对象功能的扩展”能够根据需要来动态哋实现？同时避免“扩展功能的增多”带来的子类膨胀问题从而使得任何“功能扩展变化”所导致的影响将为最低？
//业务操作,数据流的讀写定位操作
//对文件流的加密操作
//额外的加密操作...
//额外的加密操作...
//额外的加密操作...
//额外的加密操作...
//额外的加密操作...
//对文件流既加密又缓存
//額外的加密操作...
//额外的缓冲操作...
//额外的加密操作...
//额外的缓冲操作...
//额外的加密操作...
//额外的缓冲操作...
//额外的加密操作...
//额外的缓冲操作...
//额外的加密操作...
//额外的缓冲操作...
//对网络流既加密又缓冲
//对内存流既加密又缓冲
可以看到因为主体类在多个方向的扩展(数据流的读写定位，以及加密缓存是为多个方向)当对数据流(文件流，网络流内存流)进行操作(加密，缓存)时此时会派生出大量的类。而在这个过程中的操作有相哃
- has a Stream 是为了充分利用多态性，来消除没必要的派生类
既继承又组合是装饰模式强大，巧妙的地方
//构造函数时，stream需要赋值 // (可能是，文件流内存流，网络流加密文件流，加密内存流加密网络流，缓存内存流缓存文件流，缓存网络流) //额外的加密操作... //额外的加密操作... //額外的加密操作... //额外的加密操作... //额外的加密操作... //额外的缓存操作... / /额外的缓存操作.
-
Comonent 就是例子中的Stream类有读写定位行为。
- 通过采用组合而非继承的手法 Decorator模式实现了在运行时动态扩展对象功能的能力，而且可以根据需要扩展多个功能避免了使用继承带来的“灵活性差”和“多孓类衍生问题
- Decorator模式的目的并非解决“多子类衍生的多继承”问题，Decorator模式应用的要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义
发布了31 篇原创文章 · 获赞 3 · 访问量 1万+
