原以为自己已经比较了解设计模式了，谁知面试官一问，我竟然紧张到只记得单例模式。。。囧，So 有了这篇文章

1. 策略模式( Strategy )

定义个策略接口，不同的实现类提供不同的具体策略算法, 同时它们之间可以互相替换.

IStrategy 接口定义了策略方法，Strategy1 和 Strategy2 通过实现 IStrategy 提供不同的策略，而 User 组合了 IStrategy ，可以通过给 User 对象设置不同具体实现类来让其获得不同的策略

策略模式.PNG

2. 简单工厂模式( Simple Factory )

定义一个用以创建对象的工厂, 根据不同的条件生成不同的对象

注意简单工厂模式与策略模式是不同的，工厂模式是根据给定的条件返回相应的对象，而策略模式是将不同的策略对象传递给使用者以实现不同策略,（好吧，我差点分不清了）详细不同点分析可转这里

简单工厂模式.PNG

3. 工厂模式( Factory )

针对每一种产品提供一个工厂类，通过不同的工厂实例来创建不同的产品实例

与简单工厂模式不同点是它要为每一种产品提供一个工厂类，不同工厂类实现同一个工厂接口，返回不同产品，详细分析可转这里

工厂模式.PNG

4. 抽象工厂模式( Abstract Factory )

应对产品族概念而生

与工厂模式相比，抽象工厂模式是为了应对产品族

抽象工厂模式.PNG

5. 装饰者模式( Decorator )

动态的给一个对象添加一些额外的功能

ComponentImpl 和 Decorator 类都实现了 IComponent 接口，不同的是 ComponentImpl 提供了具体实现，而 Decorator 是先聚合 ComponentImpl 接着在自己的实现方法即 operation() 方法中做些处理（即装饰）后再调用 ComponentImpl 对象的具体实现

装饰者模式.PNG

6. 代理模式( Proxy )

封装被代理对象并限制外界对被代理对象的访问

注意区分装饰者模式和代理模式的区别。在代理模式中，ComponentImpl 和 Proxy 类都实现了 IComponent 接口，Proxy 对象中虽然也维护着一个 ComponentImpl 对象，但一般情况下它是代理类自己初始化的，不像装饰者模式是通过 set 进去的，同时在接口方法即 operation() 中代理对象会限制外界对被代理对象的访问，而装饰者模式是装饰者给被装饰者添加额外的行为，详细不同点分析可转这里

代理模式.PNG

7. 模板方法模式( Template )

定义一个操作的算法骨架, 并将一些步骤延迟到子类中

AbsTemplate 抽象类中定义了一系列的方法，其中外界唯一能调用的 operation() 方法是 final 的（即不可重写），在该方法中分别调用了 first() 、second() 、third() 方法（即搭好算法框架），子类通过继承抽象类重写不同的方法来添加各自的行为

模板方法模式.PNG

8. 外观模式( Facade )

为系统向外界提供一个统一的接口

Fracade 为 ComponentA 、ComponentB 、ComponentC 向外即 ClientA 、ClientB 提供统一的接口

外观模式.PNG

9. 适配器模式( Adapter )

将一个类的接口转换成客户希望的另一个接口

比如项目引入第三方类库后应该先封装起来转换成自己需要的接口再使用，防止以后类库出现变更。AdapterA 先将 LibraryClass 封装起来，其对外提供的 operation() 方法中调用 LibraryClass 对象的方法，若以后换类库，只需改 AdapterA 类或者创建新的 Adapter 实现类即可

适配器模式.PNG

10. 桥接模式( Bridge )

将抽象部分与实现部分分离，使它们都可以独立的变化

将原本要耦合的上下层抽象出来，上层和下层以组合的方式连接，然后上下层抽象可派生出许多不同方向的子类。AbsShape 封装了 IDrawProgram 接口，这样它的子类想从 DPA 切换到 DPB 或者别的，只需 set 进去就行啦（你看，这 UML 图多像座桥）

桥接模式.PNG

注： 适配器、桥接与外观三模式之间关系

11. 建造者模式( Builder )

将一个复杂对象的构建与它的表示分离.

作为 Product 的内部类，Builder 统一了 Product 的整个构建过程，同时在 build 过程中，可以由于 set 值顺序不同等原因产生不同的效果

建造者模式.PNG

12. 观察者模式( Observer )

定义了一种一对多的依赖关系,让多个观察者对象同时监听某一主题对象,在它的状态发生变化时,会通知所有的观察者.

先将 Observer 注册到 Observable ，那么当 Observable 状态改变时会通知它持有的所有 Observer ,对了，最好 Observable 中的 mList 的泛型是 WeakReference<Observer> ,防止内存泄漏

观察者模式.PNG

13. 单例模式( Singleton )

保证一个类仅有一个实例,并提供一个访问它的全局控制点.

下图是利用 Java 的语言特性实现的线程安全且能延迟初始化的单例模式，Singleton 中维护着静态私有的 SingleHolder 类， SingleHolder 类中持有个静态常量 sHolder ，Client 若通过 getSingleInstance 方法获取 Singleton 对象则直接返回 SingleHolder 类的 sHolder ，详细分析可转这里

单例模式.PNG

14. 命令模式( Command )

将一个请求封装成为一个对象, 使可以用不同的请求对客户进行参数化

Action 封装了具体行为，Command 封装了 Action 并提供空方法 execute() ，它的子类通过重写该方法可在方法里调用 mAction 不同行为达到封装命令的目的，最后 Client 封装了一系列的 Command 对象，并可以通过 notify() 方法一个接着一个调用所持有 Command 对象们的 execute() 方法达到给 Action 传达命令的目的

命令模式.PNG

最后

第一次分享文章，难免有点小激动，出现小纰漏，请帮忙指出，先多谢了哈。同时若还有其他常用的设计模式我没涉及，希望能告知哈，一定补上！！！
对了，感谢 ProcessOn 大法！！感觉比StarUML好用

参考文章：
Android 源码设计模式分析开源项目
最常用的12种设计模式