50 | 装饰器模式：通过剖析Java IO类库源码学习装饰器模式

代理模式体现封装性，非业务功能与业务功能分开，而且使用是透明的，使用者只需要关注于自身的业务，在业务场景上适用于对某一类功能进行加强，比如日志，事务，权限。 装饰器模式体现多态性，优点在于避免了继承爆炸，适用于扩展多个平行功能。在场景上，这些扩展的功能可以像火车厢一样串起来，使原有的业务功能不断增强。 具体到“缓存”这个单个问题，两种模式都可以，主要还是看设计者的目的，如果是为了新增功能的隐藏性，就使用代理模式；如果设计者不仅要增加“缓存”功能，还要增加“过滤”等功能，就更适于装饰器模式。

有个疑问 既然代码结构是一样的 那在于怎么叫了 我可以叫做代理模式 也可以叫做装饰器模式？

能不能把BufferedInputStream这些可以叠加的功能做成interface，然后定义一些内部的类

按照本节讲的内容, java io例子里 原始类: InputStream 共同父类: FileInputStream 装饰器类: BufferedInputStream , DataInputStream 是这关系吗 ? 因为InputStream本身是FileInputStream的父类 有点绕来着 .

你是一个优秀的歌手，只会唱歌这一件事，不擅长找演唱机会，谈价钱，搭台，这些事情你可以找一个经纪人帮你搞定，经纪人帮你做好这些事情你就可以安稳的唱歌了，让经纪人做你不关心的事情这叫代理模式。 你老爱记错歌词，歌迷和媒体经常吐槽你没有认真对待演唱会，于是你想了一个办法，买个高端耳机，边唱边提醒你歌词，让你摆脱了忘歌词的诟病，高端耳机让你唱歌能力增强，提高了基础能力这叫装饰者模式。

对于添加缓存这个应用场景使用哪种模式，要看设计者的意图，如果设计者不需要用户关注是否使用缓存功能，要隐藏实现细节，也就是说用户只能看到和使用代理类，那么就使用proxy模式；反之，如果设计者需要用户自己决定是否使用缓存的功能，需要用户自己新建原始对象并动态添加缓存功能，那么就使用decorator模式。

今天的课后题： 1.有意思，关于代理模式和装饰者模式，各自应用场景和区别刚好也想过。 1.代理模式和装饰者模式都是 代码增强这一件事的落地方案。前者个人认为偏重业务无关，高度抽象，和稳定性较高的场景（性能其实可以抛开不谈）。后者偏重业务相关，定制化诉求高，改动较频繁的场景。 2.缓存这件事一般都是高度抽象，全业务通用，基本不会改动的东西，所以一般也是采用代理模式，让业务开发从缓存代码的重复劳动中解放出来。但如果当前业务的缓存实现需要特殊化定制，需要揉入业务属性，那么就该采用装饰者模式。因为其定制性强，其他业务也用不着，而且业务是频繁变动的，所以改动的可能也大，相对于动代，装饰者在调整（修改和重组）代码这件事上显得更灵活。

补充关于Proxy Pattern 和Decorator Pattern的一点区别: Decorator关注为对象动态的添加功能, Proxy关注对象的信息隐藏及访问控制. Decorator体现多态性, Proxy体现封装性. reference: https://stackoverflow.com/questions/18618779/differences-between-proxy-and-decorator-pattern

对于为什么必须继承装饰器父类 FilterInputStream的思考： 装饰器如BufferedInputStream等，本身并不真正处理read()等方法，而是由构造函数传入的被装饰对象：InputStream（实际上是FileInputStream或者ByteArrayInputStream等对象）来完成的。 如果不重写默认的read()等方法，则无法完成如FileInputStream或者ByteArrayInputStream等对象所真正实现的read功能。 所以必须重写对应的方法，代理给这些被装饰对象进行处理（这也是类似于代理模式的地方）。 如果像DataInputStream和BufferedInputStream等每个装饰器都重写的这些方法话，会存在大量重复的代码。 所以让它们都继承FilterInputStream提供的默认实现，可以减少代码重复，让装饰器只聚焦在它自己的装饰功能上即可。

对于无需Override的方法也要重写的理解： 虽然本身BufferedInputStream也是一个InputStream，但是实际上它本身不作为任何io通道的输入流，而传递进来的委托对象InputStream才能真正从某个“文件”（广义的文件，磁盘、网络等）读取数据的输入流。因此必须默认进行委托。