Context以及装饰者模式

Context参考资料
装饰者模式参考资料:研磨设计模式，Android源码设计模式解析与实战。

Android和Java的区别，划分的界限：Android不像Java写一个类和main就可以运行，而是有一个完整的Android工程环境，在这个环境下，要有像Activity、Service、BroadcastReceiver等系统组件，而这些组件并不是像一个普通的Java对象new一下就能创建实例的了，而是要有它们各自的上下文环境，如果强行去new的话，该组件则只是一个普通类，不具备任何属性

1.1 Context的继承关系

从这里看出来，context只有三种，service，application和activity。
Context数量 = Activity数量 + Service数量 + Application(1)
当然，这里指的是单进程的情况下。

1.2 Context的应用场景

注意事项 1.与UI相关的context，则要用activity的context
        2.因为activity的context生命周期和application的生命周期不一样，
          Context引用的持有可能造成OOM的问题
        3.startActivity时，不要用application的context来进行，因为如果用
          application去开启activity，会产生一个新的task，不建议
        4.如果某个类中获取的context基本都是属于application，那么建议
          统一在单独的类中进行获取，方便开源自己的util库。
          无需在application中写newInstance，因为application本身就是单例
          单例的控制是在系统层。所以我们看不到
        5.如果utils类需要传activity的context的话，就必须通过传参的形式处理。

1.3 使用Application时的注意事项

Application是单例,全局只有一个(多进程除外)，无需new,系统组件的实例是要由系统来去创建的
如果new Application的话，它就只是一个普通的Java对象，不具备任何Context的能力。

2.装饰者模式

1.作用:首先知道某个设计模式的作用，以及结合生活应用场景
何为装饰者，简而言之，就好比人，穿不同的衣服，虽然有不同的装饰，但是本质还是人。
其职责就是给对象添加一些额外的职责，通常用于继承关系的一种替代方案之一。

扯特么半天，总感觉接口也可以达到这样的效果。

2.基本功:(查缺补漏)

3.优缺点

4.画出对应的UML，记住关键性代码(uml相当于骨架或者大纲，代码相当于血肉)

5.通过1-2个源码分析来巩固自己对该模式的理解(进阶)

6.相关设计模式的配套使用(每个设计模式，并不是单一的去体现某一个设计原则，设计模式之间可以相互配合使用)
7.与人交流(不能活在自己的世界里闭门造车，强行去理解)

如果不需要某个奖金计算方式了，直接不写就行了，原有的可以保留。
如果是新增计算方法，那么新建一个类就好了。
但是如果修改，那就恶心。