设计模式分成三类:
1.创建型模式
1.工厂方法：通过抽象工厂接口让创建对象和使用对象是分离的，使用类避免持有具体创建工作的类，可以让工厂方法能随时切换不同的子类进行返回
2.抽象工厂：通过抽象产品接口和抽象工厂接口来控制多个实际工厂和生产多个实际产品，使用类可以通过抽象工厂接口和抽象产品接口选择使用哪个实际工厂生产的哪个实际产品
3.建造者：通过Builder将创建对象的步骤进行分拆成很多个部分，最终再组成一个完成的对象
4.单例：为了保证在一个进程中，有且只有一个单例类实例，两个关键点：延迟加载和线程安全
2.结构性模式
1.适配器：类似于充电器转接头，经过适配器，输入一个A类输出一个B类，B类满足使用条件
2.装饰器：将具体类的核心功能和附加功能进行分割了，如果需要增加附加功能，就继承于附加功能的抽象类，可以在运行期动态给核心功能增加附加功能
3.外观：给使用者提供的中介服务，使用者不需要了解内部实现，只需要和中介打交道，中介再去跟各个人打交道
4.享元：如果一个对象实例一经创建就不可变，那么反复创建相同的实例就没有必要，直接向调用方返回一个共享的实例就行
5.代理：静态代理和动态代理，通过代理接口给核心功能接口新增一些代理功能
3.行为型模式
1.责任链：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系，将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止
2.中介：通过引入中介对象，把多边关系变成多个双边关系，从而简化系统组件的交互耦合度
3.观察者：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新
4.状态：把不同状态的逻辑分离到不同的状态类中，从而使得增加新状态更容易
工厂方法：平时封装的aar库需要向外暴露功能时，会使用工厂类包装一下再向外暴露
抽象工厂：在项目中一部分人使用了fresco，一部分人使用了Glide，大家都觉得自己的好用，换起来太麻烦，就弄了抽象工厂模式来满足两种图片加载的方式，供各自选使用，最后拍板就选择glide的时候，换起来也很轻松，只需要将fresco的实现工厂换成glide的实现工厂就行
建造者：业务部门访问封装aar功能时，如果参数比较多的情况，就会写建造者Builder向外暴露
单例：一般都是用枚举单例，或者双重锁检查单例 ，静态内部类的单例会因为反射和序列化而失效， 跨进程单例可以通过单例类继承aidl.Stub类来实现，onBind()直接传输继承了Stub的单例类，再通过ServiceConnection使用Stub.asInterface()获取到单例类
代理模式：会动态给一些系统接口方法增加一些自己检查方法
责任链
观察者：
