定义

工厂方法模式(Factory Method Pattern)又称为工厂模式，也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(Polymorphic Factory)模式，它属于类创建型模式。在工厂方法模式中，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类（并不是指子类本身在运行时做决定，而是编写者在创建类时，不需要知道实际的创建产品的类型，选择了使用哪个子类自然决定了实际的创建产品类型）。

使用场景

• 一个类不知道它所需要的对象的类：在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可，具体的产品对象由具体工厂类创建；客户端需要知道创建具体产品的工厂类。
• 一个类通过其子类来指定创建哪个对象：在工厂方法模式中，对于抽象工厂类只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象，利用面向对象的多态性和里氏代换原则，在程序运行时，子类对象将覆盖父类对象，从而使得系统更容易扩展。
• 将创建对象的任务 给多个工厂子类中的某一个，客户端在使用时可以无须关心是哪一个工厂子类创建产品子类，需要时再动态指定，可将具体工厂类的类名存储在配置文件或数据库中。

UML 图

Product：抽象产品
ConcreteProduct：具体产品
Factory：抽象工厂
ConcreteFactory：具体工厂，实现了实际造出产品的方法

定义

装饰者模式动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更具有弹性的替代方案，其别名也可以称为包装器(Wrapper）

使用场景

• 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
• 需要动态地给一个对象增加功能，这些功能也可以动态地被撤销。
• 当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时。不能采用继承的情况主要有两类：第一类是系统中存在大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长；第二类是因为类定义不能继承（如final类）.

UML 图

Component: 抽象构件
ConcreteComponent: 具体构件
Decorator: 抽象装饰类
ConcreteDecorator: 具体装饰类

定义

观察者模式定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖都会受到通知并自动更新

使用场景

1. 对象之间的一对多依赖。一个对象状态的更新时，其他对象需要自动更新，而且其他对象的数量动态可变。（注册、反注册）
2. 对象仅需要将自己的更新通知给其他对象而不需要知道其他对象的细节。 (解耦)
3. MVC 中的 View 层实现

UML 图

定义

策略模式定义了算法簇，分别封装起来，让它们之间可以互相替代，此模式让算法的变化独立于使用算法的客户

使用场景

• 针对同一类型问题的多种处理方式，仅仅是具体行为有差别时。
• 需要安全的封装多种同一类型的操作时。
• 出现同一抽象多个子类，而又需要使用if-else 或者 switch-case来选择时。

UML 图

• Context：用来操作策略的上下文环境。
• Strategy : 策略的抽象
• ImplementationOne、ImplementationTwo：具体策略的实现

I

2015小结

　　2015算是自己人生中又一个分水岭，过了除夕才是过完中国的一年，赶在除夕之前整理下自己的2015。

工作

　　在学校做硬件 -> 实习做驱动 -> 离开了校园 -> 迈入职场-> Android APP 开发
　　
　　这一年在技术上的成长自己还是很满意的

流水账

　　2015年初，从美团实习完回学校之后就发觉对 Android 有浓厚的兴趣，考虑到后续工作可能接触到 Android 相关的工作，2015年出开始自学 Java 和 Android，抱着『第一行代码』走了一遍，对 Android 有了初步的认识。之后忙毕业一直到了6月。

　　6月正式入职之后，最初是被分配在了 MTK 平台那边，并不和 Android 相关，主动找了桥哥和栋哥商量，调到了 Android 开发，美团这一点还是挺人性的，尊重员工的意愿。还好有申燊同学带着，一步一步开始了 Android 之旅。

　　第一个项目是做的小美接单，当样机拼装完成，成功打印的那一刻还是挺有成就感的。
　　
　　　

定义

模板方法模式定义了一个算法的步骤，并允许次类别为一个或多个步骤提供其实践方式。让次类别在不改变算法架构的情况下，重新定义算法中的某些步骤。

使用场景

• 一次性实现一个算法的不变部分，把变化部分留给子类去实现。
• 各子类间的共同行为需要被提取并集中到一个共同的类中来避免代码的重复。你首先识别出这些现有代码的不同之处，然后把这些不同之处分离到新的操作中。最后，你用一个模板方法调用这些新操作之一来替代原有那些不同的代码。
• 控制子类扩展。你能定义一个只在特定点调用 hook 操作的模板方法，以此只允许子类在这些点扩展。

UML 图

AbstractTemplate：抽象模板

• 定义了一个或多个抽象操作，以便让子类实现。这些抽象操作叫做基本操作，它们是一个顶级逻辑的组成步骤。
• 定义并实现了一个模板方法。这个模板方法一般是一个具体方法，它给出了一个顶级逻辑的骨架，而逻辑的组成步骤在相应的抽象操作中，推迟到子类实现。顶级逻辑也有可能调用一些具体方法。

ConcreteTemplate：具体实现

• 实现父类所定义的一个或多个抽象方法，它们是一个顶级逻辑的组成步骤。
• 每一个抽象模板角色都可以有任意多个具体模板角色与之对应，而每一个具体模板角色都可以给出这些抽象方法（也就是顶级逻辑的组成步骤）的不同实现，从而使得顶级逻辑的实现各不相同。

定义

目的

• 根据不同的状态，采取不同的行为
• 允许一个对象在其内部状态改变的时候改变其行为。这个对象看上去就像是改变了它的类一样

优点

• 减少了 if else，switch 语句的复杂程度
• 增加新的状态和逻辑时，便于修改

缺点

• 类的种类增加
  *

步骤

1. 定义一个 context 类，来给外接提供一个接口
2. 定义一个 state 基类
3. 根据state 状态，派生定义其他的不同状态类
4. 在派生state 中，定义不同的行为
5. 在context中持有一个当前 state的变量
6. 改变context中的state状态

注解

注解目的

1. 生成文档 ，如 @see @param @return 等
2. 跟踪代码依赖性，实现替代配置文件功能
3. 在编译时进行格式检查。如@override

注解基础

最基础的注解如下

@Entity

@ 表示这是一个注解，之后的字母表示这个注解的名字，以上例子的注解名字为 Entity

定义

抽象工厂模式 Abstract Factory Pattern：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。

使用场景

• 一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有类型的工厂模式都是重要的。
• 系统中有多于一个的产品族，而每次只使用其中某一产品族。
• 属于同一个产品族的产品将在一起使用，这一约束必须在系统的设计中体现出来。
• 系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于具体实现。

UML 图

AbstractFactory：抽象工厂
ConcreteFactory：具体工厂
AbstractProduct：抽象产品
Product：具体产品

强引用 StrongReference

只要某个对象有强引用与之关联，JVM必定不会回收这个对象，即使在内存不足的情况下，JVM宁愿抛出OutOfMemory错误也不会回收这种对象

若需要 jvm 回收此对象，可以将对象复制为 null

Object o = new Object();   //  强引用  
o = null;     // 帮助垃圾收集器回收此对象  

但是如果这个o是全局的变量时，就需要在不用这个对象时赋值为null，因为强引用不会被垃圾回收。