装饰者模式
UML类图
模式说明
装饰者模式，在不改变原类文件和使用继承的情况下，动态扩展一个对象的功能。它是通过创建一个包装对象，也就是装饰来包裹真实的对象。
装饰者模式具备以下特点：
- 装饰对象和真实对象具有相同的接口。这样客户端对象就能以和真实对象相同的方式和装饰对象交互
- 装饰对象包含一个真实对象的引用（reference）
- 装饰对象接受所有来自客户端的请求。它把这些请求转发给真实的对象
设计原则
- 多用组合，少用继承
- 类应该设计的对扩展开放，对修改关闭
Java IO流是最有名的装饰者模式案例
假装还原一下InputStream设计过程
基本功能实现：FileInputStream
如何实现read()方法？
如何实现read(byte b[], int off, int len)方法？
基本功能就算是实现了
扩展需求
找个最简单的
需求
复制一个100M以上的文件，为了减少内存占用节约内存控空间，只能用很小的缓存来中转数据
丧心病狂复制粘贴了100多M的hello.txt
缓存空间用了100字节，用FileInputStream和FileOutputStream：
不是很理想啊，加大缓存空间，用1024大小的缓存作为中转呢
用1024*4大小的缓存作为中转呢
封装
缓存思想：字节流一次读一个数组的速度比一次读一个字节要快，且读一个大字节数组比分成多个小字节数组要快
缓存功能很好，在每次使用比较小段的数据的时候，可以先从缓存里面读，缓存读完了再去读文件来填充缓存，这样能节省内存的同时提升性能
没准以后还会用到这样的功能，怎么集成这个功能呢？假如在这个功能的基础上，还想添加更多的功能呢？
- 读出来就是基本类型数据，而不是字节或字节数组
假装我来考虑如何扩展输入流
- 在FileInputStream类里面加代码？
违反了开闭原则：对扩展开放，对修改关闭
- 继承FileInputStream写子类？
以后还需要其他功能时，继续继承，就会出现很多子类。
违反了依赖倒置原则：要依赖于抽象，不要依赖于具体
最终方案：
合成复用原则：如果新对象的某些功能在别的已经创建好的对象里面已经实现，那么尽量使用别的对象提供的功能，使之成为新对象的一部分，而不要自己再重新创建。新对象通过向这些对象的委派达到复用已有功能的
- 新建一个类，来封装这个缓存的功能
- 这个类持有一个InputStream的实现对象，用以利用已经被FileInputStream实现的基本功能
- 新类的方法最好也和InputStream里面的方法同名，便于使用。那就直接继承InputStream抽象类呗
诶？这两个很像嘛
刚刚用FileInputStream写的代码，换成BufferedInputStream来写：
Java InputStream装饰类FilterInputStream的子类：
多个装饰类的嵌套使用：
《大话设计模式》中的例子
- 穿西装（穿皮鞋（打领带（的小菜）））
- 穿西装（打领带（穿皮鞋（的小菜）））
适用范围
系统需要新功能时，且这些新东西只为了满足一些在某种特定情况下才会执行的特殊行为的需要
使用技巧
- 只有一个ConcreteComponent，Decorator可以是其子类
- 只有一个ConcreteDecorator，就不需要Decorator
注意事项
多个装饰者之间的装饰顺序需要按照实际的逻辑进行。
多个装饰者尽量互相独立，可以随意顺序嵌套
装饰者模式和代理模式的区别
装饰者模式：以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，为所装饰的对象增强功能；
代理模式：给一个对象提供一个代理对象，并有代理对象来控制对原有对象的引用，对代理的对象施加控制，并不提供对象本身的增强功能。
模板方法模式
UML类图
模式说明
抽象类（AbstractClass）:
——定义抽象的 原语操作（primitive operation） ，具体的子类将重定义它们以实现一个算法的各个步骤。
——实现一个模板方法,定义一个算法的骨架。该模板方法不仅调用原语操作，也调用定义在 AbstractClass 或其他对象中的操作
具体子类 （ConcreteClass）:
——实现原语操作以完成算法中与特定子类相关的步骤。
意图
定义一个操作中的算法骨架，而将一些步骤延迟到子类中， 使得子类可以不改变一个算法的结构即可重新定义该算法的某些特定步骤。
很久以前，onCreate()需要做很多工作
onCreate()里面就有很多代码，以后看代码非常吃力。设置一个父类来规范代码：
实际的Activity再继承BaseActivity：
沉浸式状态栏
项目中的Component、ComponentContainer
适用性
模板方法应用于下列情况：
- 一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现。
- 各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。首先识别现有代码中的不同之处，并且将不同之处分离为新的操作。最后，用一个调用这些新的操作的模板方法来替换这些不同的代码。
- 控制子类扩展。模板方法只在特定点调用“ hook”操作 ，这样就只允许在这些点进行扩展。
