Android

Activity的onSaveInstanceState和onRestoreInstanceState就是用到了备忘录模式，分别用于保存和恢复。

重构

暂无

迭代器模式

定义

提供一种方法顺序访问一个容器对象中的各个元素，而不需要暴露该对象的内部表示。
迭代器模式是与集合共生共死的，一般来说，我们只要实现一个集合，就需要同时提供这个集合的迭代器，就像java中的Collection，List、Set、Map等，这些集合都有自己的迭代器。假如我们要实现一个这样的新的容器，当然也需要引入迭代器模式，给我们的容器实现一个迭代器。

示例

Java的Iterator就是一个抽象迭代器，通过实现这个接口各个集合可以提供自己定制的具体迭代器，感兴趣的可以直接查看源码
虽然我们使用集合的场景非常多，但是实际使用到迭代器的却比较少，对于比较简单的遍历（像数组或者有序列表），使用迭代器方式遍历较为繁琐，比如ArrayList，我们更倾向于使用for循环来遍历，但是针对hash表之类的集合来说，引入迭代器就反而简单多了。同时我们也可以通过自定义迭代器来对有序列表提供正序遍历或者倒序遍历，用户只需要得到迭代器就可以遍历了，而不需要关心具体遍历算法。

Android

Android源码中，最典型的就是Cursor用到了迭代器模式，当我们使用SQLiteDatabase的query方法时，返回的就是Cursor对象，之后再通过Cursor去遍历数据

重构

暂无

模板方法模式

定义

定义一个操作中的算法框架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重定义该算法的某些特定的步骤。

示例

public abstract class BaseAdvertManager {
    public void loadAdvert(Context context, int type) {
        if (NetUtils.checkNetConnection(context) != NetUtils.OK) {
            return;
        }
        mStateArray.put(type, AdvertConstant.AD_STATE_LOADING);
        doLoadAdvert(context, type);
    }

    protected abstract void doLoadAdvert(Context context, int type);
}

广告管理器抽象类定义了加载广告的通用模板，但是又把模板中具体加载广告的逻辑声明为抽象方法为各个子类自我实现

Android

启动一个Activity过程非常复杂，有很多地方需要开发者定制，也就是说，整体算法框架是相同的，但是将一些步骤延迟到子类中，比如Activity的onCreate、onStart等等。这样子类不用改变整体启动Activity过程即可重定义某些具体的操作了。

重构

大部分代码相同部分代码不同的方法都可以尝试使用模板方法重构，要么是在同一个类里面进行方法的重构，要么通过塑造模板函数的重构手段对子类与父类进行重构
项目中自拍确认页保存照片并分享与保存照片并后退目前是两个独立的方法，但是方法内部大多数代码都是一样的，就需要用该模式进行重构，由于代码量大而且该重构手段比较简单，就不贴出代码

访问者模式

定义

封装一些作用于某种数据结构中各元素的操作，它可以在不改变这个数据结构的前提下定义作用于这些元素的新的操作。
假如一个对象中存在着一些与本对象不相干（或者关系较弱）的操作，为了避免这些操作污染这个对象，则可以使用访问者模式来把这些操作封装到访问者中去。
假如一组对象中，存在着相似的操作，为了避免出现大量重复的代码，也可以将这些重复的操作封装到访问者中去。
访问者模式的目的是封装一些施加于某种数据结构元素之上的操作，一旦这些操作需要修改的话，接受这个操作的数据结构则可以保持不变。
访问者模式是23种设计模式中最复杂最难理解的一个，但他的使用率并不高，大部分情况下，我们不需要使用访问者模式，少数特定的场景才需要。

大多数情况下，你并需要使用访问者模式，但是当你一旦需要使用它时，那你就是真的需要它了。——GOF《设计模式：可复用面向对象软件的基础 》

示例

interface Service {

    public void accept(Visitor visitor);
}

class Draw implements Service {

    public void accept(Visitor visitor) {
        visitor.process(this);
    }
}

class Fund implements Service {

    public void accept(Visitor visitor) {
        visitor.process(this);
    }
}

class Saving implements Service {

    public void accept(Visitor visitor) {
        visitor.process(this);
    }
}

class Visitor {

    public void process(Service service) {
        // 基本业务
        System.out.println("基本业务");
    }

    public void process(Saving service) {
        // 存款
        System.out.println("存款");
    }

    public void process(Draw service) {
        // 提款
        System.out.println("提款");
    }

    public void process(Fund service) {
        System.out.println("基金");
        // 基金
    }
}

public class Client {
    public static void main(String[] args){
        Service saving = new Saving();
        Service fund = new Fund();
        Service draw = new Draw();

        Visitor visitor = new Visitor();
        saving.accept(visitor);
        fund.accept(visitor);
        draw.accept(visitor);
    }
}

采用Visitor的好处如上面所示，当需要改变其中一项业务的处理时，不需要每个地方都进行修改，而只需要改动Visitor类中相应的处理函数就可以了。也就是说它适合于业务处理时常发生变动的情况。
当然，Visitor也有它自身的限制。它不适合于业务数量的经常变化，因为一旦新增或删除一些Service时，需要对Visitor进行相应的增删。也就是说具体Service与Visitor是耦合的。

Android

Android中运用访问者模式，其实主要是在编译期注解中，编译期注解核心原理依赖APT(Annotation Processing Tools)，著名的开源库比如ButterKnife、Dagger、Retrofit都是基于APT。

重构

如果是一些经常需要变动逻辑的业务则非常适合使用访问者模式，如果是需要频繁增加新的业务的，则不适合，所以Android的UI展示部分其实理论上来说是适合使用访问者模式的，因为UI常常一个版本一个变化，如果当UI的变化不只是局限在XML中修修改改的话，而是已经体现在了代码中，那么可以考虑是否可以使用访问者模式进行修改。
目前实际项目中暂无这种情况，广告模块后续的UI渲染由于是根据不同的广告平台所下发的广告对象来进行对应的渲染，目前每个广告平台渲染视图的接口所需参数不太一样，但是可以考虑进行一下抽离封装，做成一个简单的Visitor试试看。

中介者模式

定义

中介者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显调用，从而使他们可以轻松耦合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用保证这些作用可以彼此独立的变化，中介者模式将多对多的相互作用转为一对多的相互作用。
其实，中介者对象是将系统从网状结构转为以调停者为中心的星型结构。
举个简单的例子，一台电脑包括：CPU、内存、显卡、IO设备。其实，要启动一台计算机，有了CPU和内存就够了。当然，如果你需要连接显示器显示画面，那就得加显卡，如果你需要存储数据，那就要IO设备，但是这并不是最重要的，它们只是分割开来的普通零件而已，我们需要一样东西把这些零件整合起来，变成一个完整体，这个东西就是主板。主板就是起到中介者的作用，任何两个模块之间的通信都会经过主板协调。

示例

public abstract class Person {
    protected String name;
    protected Mediator mediator;

    Person(String name,Mediator mediator){
        this.name = name;
        this.mediator = mediator;
    }

}

public class HouseOwner extends Person{

    HouseOwner(String name, Mediator mediator) {
        super(name, mediator);
    }

    /**
     * @desc 与中介者联系
     * @param message
     * @return void
     */
    public void constact(String message){
        mediator.constact(message, this);
    }

    /**
     * @desc 获取信息
     * @param message
     * @return void
     */
    public void getMessage(String message){
        System.out.println("房主:" + name +",获得信息：" + message);
    }
}

public class Tenant extends Person{

    Tenant(String name, Mediator mediator) {
        super(name, mediator);
    }

    /**
     * @desc 与中介者联系
     * @param message
     * @return void
     */
    public void constact(String message){
        mediator.constact(message, this);
    }

    /**
     * @desc 获取信息
     * @param message
     * @return void
     */
    public void getMessage(String message){
        System.out.println("租房者:" + name +",获得信息：" + message);
    }
}

public abstract class Mediator {
    //申明一个联络方法
    public abstract void constact(String message,Person person);
}

public class MediatorStructure extends Mediator{
    //首先中介结构必须知道所有房主和租房者的信息
    private HouseOwner houseOwner;
    private Tenant tenant;

    public HouseOwner getHouseOwner() {
        return houseOwner;
    }

    public void setHouseOwner(HouseOwner houseOwner) {
        this.houseOwner = houseOwner;
    }

    public Tenant getTenant() {
        return tenant;
    }

    public void setTenant(Tenant tenant) {
        this.tenant = tenant;
    }

    public void constact(String message, Person person) {
        if(person == houseOwner){          //如果是房主，则租房者获得信息
            tenant.getMessage(message);
        }
        else{       //反正则是房主获得信息
            houseOwner.getMessage(message);
        }
    }
}

public class Client {
    public static void main(String[] args) {
        //一个房主、一个租房者、一个中介机构
        MediatorStructure mediator = new MediatorStructure();

        //房主和租房者只需要知道中介机构即可
        HouseOwner houseOwner = new HouseOwner("张三", mediator);
        Tenant tenant = new Tenant("李四", mediator);

        //中介结构要知道房主和租房者
        mediator.setHouseOwner(houseOwner);
        mediator.setTenant(tenant);

        tenant.constact("听说你那里有三室的房主出租.....");
        houseOwner.constact("是的!请问你需要租吗?");
    }
}

房主:张三,获得信息：听说你那里有三室的房主出租….. 租房者:李四,获得信息：是的!请问你需要租吗?

Android

在Binder机制中，就用到了中介者模式。我们知道系统启动时，各种系统服务会向ServiceManager提交注册，即ServiceManager持有各种系统服务的引用 ，当我们需要获取系统的Service时，比如ActivityManager、WindowManager等（它们都是Binder），首先是向ServiceManager查询指定标示符对应的Binder，再由ServiceManager返回Binder的引用。并且客户端和服务端之间的通信是通过Binder驱动来实现，这里的ServiceManager和Binder驱动就是中介者。

重构

从年初开始就有在项目里面做MVP的重构，MVP架构里面P层其实就是一个中介者，负责协调V和M

外观模式/门面模式

定义

要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。
举个例子，我们在启动计算机时，只需按一下开关键，无需关系里面的磁盘、内存、cpu、电源等等这些如何工作，我们只关心他们帮我启动好了就行。实际上，由于里面的线路太复杂，我们也没办法去具体了解内部电路如何工作。主机提供唯一一个接口“开关键”给用户就好。

示例

/**
 * cpu子系统类
 */
public class CPU
{
    public static final Logger LOGGER = Logger.getLogger(CPU.class);
    public void start()
    {
        LOGGER.info("cpu is start...");
    }

    public void shutDown()
    {
        LOGGER.info("CPU is shutDown...");
    }
}

/**
 * Disk子系统类
 */
public class Disk
{
    public static final Logger LOGGER = Logger.getLogger(Disk.class);
    public void start()
    {
        LOGGER.info("Disk is start...");
    }

    public void shutDown()
    {
        LOGGER.info("Disk is shutDown...");
    }
}

/**
 * Memory子系统类
 */
public class Memory
{
    public static final Logger LOGGER = Logger.getLogger(Memory.class);
    public void start()
    {
        LOGGER.info("Memory is start...");
    }

    public void shutDown()
    {
        LOGGER.info("Memory is shutDown...");
    }
}

/**
 * 门面类（核心）
 */
public class Computer
{
    public static final Logger LOGGER = Logger.getLogger(Computer.class);

    private CPU cpu;
    private Memory memory;
    private Disk disk;
    public Computer()
    {
        cpu = new CPU();
        memory = new Memory();
        disk = new Disk();
    }
    public void start()
    {
        LOGGER.info("Computer start begin");
        cpu.start();
        disk.start();
        memory.start();
        LOGGER.info("Computer start end");
    }

    public void shutDown()
    {
        LOGGER.info("Computer shutDown begin");
        cpu.shutDown();
        disk.shutDown();
        memory.shutDown();
        LOGGER.info("Computer shutDown end...");
    }
}

/**
 * 客户端类
 */
public class Cilent {
    public static final Logger LOGGER = Logger.getLogger(Cilent.class);
    public static void main(String[] args)
    {
        Computer computer = new Computer();
        computer.start();
        LOGGER.info("=================");
        computer.shutDown();
    }
}

从上面的实例来看，有了这个Facade类，也就是Computer类，用户就不用亲自去调用子系统中的Disk,Memory、CPU类了，不需要知道系统内部的实现细节，甚至都不用知道系统内部的构成。客户端只需要跟Facade交互就可以了。

Android

那么Android哪里使用到了外观模式呢？依然回到Context，Android内部有很多复杂的功能比如startActivty、sendBroadcast、bindService等等，这些功能内部的实现非常复杂，如果你看了源码你就能感受得到，但是我们无需关心它内部实现了什么，我们只关心它帮我们启动Activity，帮我们发送了一条广播，绑定了Activity等等就够了。

重构

暂无

代理模式

定义

给某一个对象提供一个代理，并由代理对象控制对原对象的引用。
代理模式有几种，虚拟代理，计数代理，远程代理，动态代理。主要分为两类，静态代理和动态代理。

静态代理

定义

静态代理比较简单，是由程序员编写的代理类，并在程序运行前就编译好的，而不是由程序动态产生代理类，这就是所谓的静态。可以通过聚合和继承两种方式实现，继承方式不够灵活，所以只介绍聚合的方式

示例

nterface Subject {
    void request();
}

class RealSubject implements Subject {
    public void request(){
        System.out.println("RealSubject");
    }
}

class Proxy implements Subject {
    private Subject subject;

    public Proxy(Subject subject){
        this.subject = subject;
    }
    public void request(){
        System.out.println("begin");
        subject.request();
        System.out.println("end");
    }
}

public class ProxyTest {
    public static void main(String args[]) {
        RealSubject subject = new RealSubject();
        Proxy p = new Proxy(subject);
        p.request();
    }
}

重构

目前项目中有需要加载图片的业务需求，加载图片的框架可以有ImageLoader、Glide等等，可以通过适配器模式让这些第三方或者自己内部的工具类整合在一起，然后通过静态代理的方式提供给外部使用图片处理的相关功能。

动态代理

定义

动态代理中，代理类并不是在Java代码中实现，而是在运行时期生成，相比静态代理，动态代理可以很方便的对委托类的方法进行统一处理，如添加方法调用次数、添加日志功能等等，动态代理分为jdk动态代理和cglib动态代理，下面通过一个例子看看如何实现jdk动态代理。

JDK动态代理示例

//定义业务逻辑
public interface Service {  
    //目标方法 
    public abstract void add();  
} 

public class UserServiceImpl implements Service {  
    public void add() {  
        System.out.println("This is add service");  
    }  
}

//利用java.lang.reflect.Proxy类和java.lang.reflect.InvocationHandler接口定义代理类的实现。
class MyInvocatioHandler implements InvocationHandler {
    private Object target;

    public MyInvocatioHandler(Object target) {
        this.target = target;
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        System.out.println("-----before-----");
        Object result = method.invoke(target, args);
        System.out.println("-----end-----");
        return result;
    }
    // 生成代理对象
    public Object getProxy() {
        ClassLoader loader = Thread.currentThread().getContextClassLoader();
        Class

cglib动态代理示例

前面分析到，因为Java只允许单继承，而JDK生成的代理类本身就继承了Proxy类，因此，使用JDK实现的动态代理不能完成继承式的动态代理，但是我们可以使用cglib来实现继承式的动态代理。
大名鼎鼎的spring中就含有cglib动态代理，在此也以Spring中自带的cglib完成动态代理的实现：

//1.具体主题  
public class Train{  
    public void move(){  
        System.out.println("火车行驶中…");  
    }  
}  
//2.生成代理  
public class CGLibProxy implements MethodInterceptor {  
    private Enhancer enhancer = new Enhancer();  
    public Object getProxy(Class

重构

在项目中很多地方需要统计，这部分功能放在哪一层都感觉不合适，可以通过动态代理将简单的统计抽离出来，动态代理其实就是AOP编程思想的一种具体实现

小结

动态代理与静态代理相比较，最大的好处是接口中声明的所有方法都被转移到调用处理器一个集中的方法中处理。在接口方法数量比较多的时候，我们可以进行灵活处理，而不需要像静态代理那样对每一个方法或方法组合进行处理。Proxy 很美很强大，但是仅支持 interface 代理。Java 的单继承机制注定了这些动态代理类们无法实现对 class 的动态代理。好在有cglib为Proxy提供了弥补。class与interface的区别本来就模糊，在java8中更是增加了一些新特性，使得interface越来越接近class，当有一日，java突破了单继承的限制，动态代理将会更加强大。

Android

AIDL会根据当前的线程判断是否要跨进程访问，如果不需要跨进程就直接返回实例，如果需要跨进程则返回一个代理。而在跨进程通信时，需要把参数写入到Parcelable对象，然后再执行transact函数，AIDL通过生成一个代理类，这个代理类会自动帮我们写好这些操作。
而要实现Android的插件化开发，动态代理更是必不可少的。

中介者、代理、外观模式三者的区别

• 中介者模式：A，B之间的对话通过C来传达。A,B可以互相不认识（减少了A和B对象间的耦合）
• 代理模式：A要送B礼物，A,B互相不认识，那么A可以找C来帮它实现送礼物的愿望（封装了A对象）
• 外观模式：A和B都要实现送花，送巧克力的方法，那么我可以通过一个抽象类C实现送花送巧克力的方法（A和B都继承C）。（封装了A，B子类）

代理模式和外观者模式这两种模式主要不同就是代理模式针对的是单个对象，而外观模式针对的是所有子类。

装饰模式

定义

动态的给一个对象添加额外的职责，就增加功能来说，装饰模式比子类继承的方式更灵活。

我们通常可以使用继承来实现功能的拓展，如果这些需要拓展的功能的种类很繁多，那么势必生成很多子类，增加系统的复杂性，同时，使用继承实现功能拓展，我们必须可预见这些拓展功能，这些功能是编译时就确定了，是静态的。

使用Decorator的理由是：这些功能需要由用户动态决定加入的方式和时机。Decorator提供了”即插即用”的方法，在运行期间决定何时增加何种功能。

示例

public abstract class Component{
    public abstract void operate();
}

public class ConcreteComponent extends Component{
    public void operate(){
        //具体的实现
    }
}

public class Decorator extends Component {
    private Component component;
    public Decorator(Component component){
        this.component = component;
    }

    public void operate(){
        operateA();
        component.operate();
        operateB();
    }
    public void operateA(){
        //具体操作
    }
    public void operateB(){
        //具体操作
    }
}

public static void main(String[] args) { 
        // 使用普通功能类 
        Component concreteComponent = new ConcreteComponent();
        Component decorator = new Decorator(concreteComponent);
        decorator.operate();
    } 
}

如果你细心，会发现，上面调用类似我们读取文件时的调用：

FileReader fr = new FileReader(filename);
BufferedReader br = new BufferedReader(fr);

实际上Java 的I/O API就是使用Decorator实现的，I/O变种很多，如果都采取继承方法，将会产生很多子类，显然相当繁琐。

Android

那么在Android哪里出现了装饰模式呢？我们平时经常用到Context类，但是其实Context类只是个抽象类，具体实现是ContextImpl，那么谁是ContextImpl的装饰类呢？我们知道Activity是个Context,但是Activity 并不是继承于Context,而是继承于ContextThremeWrapper.而ContextThremeWrapper继承于ContextWrapper,ContextWrapper继承Context.说了这么多，跟装饰模式有啥关系？主要是引入ContextWrapper这个类。ContextWrapper内部有个Context引用mContext，并且ContextWrapper中对Context的每个方法都有实现，在实现中调用的就是mContext相同的方法。

重构

子类过多的时候可以考虑使用

装饰模式与代理模式的区别

装饰模式：以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案；
代理模式：给一个对象提供一个代理对象，并有代理对象来控制对原有对象的引用；
装饰模式应该为所装饰的对象增强功能；代理模式对代理的对象施加控制，并不提供对象本身的增强功能
你在一个地方写装饰，大家就知道这是在增加功能，你写代理，大家就知道是在限制，

组合模式

定义

将对象组成成树形结构，以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。

示例

public class Employee {
   private String name;
   private String dept;
   private int salary;
   private List subordinates;

   //构造函数
   public Employee(String name,String dept, int sal) {
      this.name = name;
      this.dept = dept;
      this.salary = sal;
      subordinates = new ArrayList();
   }

   public void add(Employee e) {
      subordinates.add(e);
   }

   public void remove(Employee e) {
      subordinates.remove(e);
   }

   public List getSubordinates(){
     return subordinates;
   }

   public String toString(){
      return ("Employee :[ Name : "+ name
      +", dept : "+ dept + ", salary :"
      + salary+" ]");
   }   
}

public class CompositePatternDemo {
   public static void main(String[] args) {
      Employee CEO = new Employee("John","CEO", 30000);

      Employee headSales = new Employee("Robert","Head Sales", 20000);

      Employee headMarketing = new Employee("Michel","Head Marketing", 20000);

      Employee clerk1 = new Employee("Laura","Marketing", 10000);
      Employee clerk2 = new Employee("Bob","Marketing", 10000);

      Employee salesExecutive1 = new Employee("Richard","Sales", 10000);
      Employee salesExecutive2 = new Employee("Rob","Sales", 10000);

      CEO.add(headSales);
      CEO.add(headMarketing);

      headSales.add(salesExecutive1);
      headSales.add(salesExecutive2);

      headMarketing.add(clerk1);
      headMarketing.add(clerk2);

      //打印该组织的所有员工
      System.out.println(CEO);
      for (Employee headEmployee : CEO.getSubordinates()) {
         System.out.println(headEmployee);
         for (Employee employee : headEmployee.getSubordinates()) {
            System.out.println(employee);
         }
      }       
   }
}

Android

Android中View的结构是树形结构，每个ViewGroup包含一系列的View，而ViewGroup本身又是View。这是Android中非常典型的组合模式。

重构

暂无

适配器模式

定义

把一个类的接口变换成客户端所期待的另一个接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。

示例

// 目标接口，或称为标准接口，即客户所期待的接口
interface Target { 
    public void request(); 
} 

// 具体目标类，只提供普通功能 
class ConcreteTarget implements Target { 
    public void request() { 
        System.out.println("普通类 具有 普通功能..."); 
    } 
} 

// 已存在的、具有特殊功能、但不符合我们既有的标准接口的类，也是需要被适配的类
class Adaptee { 
    public void specificRequest() { 
        System.out.println("被适配类具有特殊功能..."); 
    } 
}   

// 适配器类，继承了被适配类，同时实现标准接口 
class Adapter extends Adaptee implements Target{ 
    public void request() { 
        super.specificRequest(); 
    } 
} 

// 测试类public class Client { 
public static void main(String[] args) { 
        // 使用普通功能类 
        Target concreteTarget = new ConcreteTarget(); 
        concreteTarget.request(); 

        // 使用特殊功能类，即适配类 
        Target adapter = new Adapter(); 
        adapter.request(); 
    } 
} 

Android

比较典型的有ListView和RecyclerView。为什么ListView需要使用适配器呢？ListView用于显示列表数据，但列表数据形式多种多样，为了处理和显示不同的数据，我们需要对应的适配器作为桥梁。这样ListView就可以只关心它的每个ItemView，而不用关心这个ItemView具体显示的是什么。而我们的数据源存放的是要显示的内容，它保存了每一个ItemView要显示的内容。ListView和数据源之间没有任何关系，这时候，需要通过适配器，适配器提供getView方法给ListView使用，每次ListView只需提供位置信息给getView函数，然后getView函数根据位置信息向数据源获取对应的数据，根据数据返回不同的View。

重构

当想使用一个既有类的接口，但是这个既有类与目前的代码结构不相兼容的时候可以考虑使用适配器模式。

享元模式

定义

享元模式的英文是Flyweight，在拳击比赛中指最轻量级，即“蝇量级”或“雨量级”，这里选择使用“享元模式”的意译，是因为这样更能反映模式的用意。享元模式是对象的结构模式。享元模式以共享的方式高效地支持大量的细粒度对象。

享元模式还分单纯享元模式和复合享元模式

示例

在JAVA语言中，String类型就是使用了享元模式。String对象是final类型，对象一旦创建就不可改变。在JAVA中字符串常量都是存在常量池中的，JAVA会确保一个字符串常量在常量池中只有一个拷贝。String a=”abc”，其中”abc”就是一个字符串常量。

Android

享元模式我们平时接触真的很多，比如Java中的常量池，线程池等。主要是为了重用对象。

在Android哪里用到了享元模式呢？线程通信中的Message，每次我们获取Message时调用Message.obtain()其实就是从消息池中取出可重复使用的消息，避免产生大量的Message对象。

重构

暂无

桥接模式

定义

将抽象部分与实现部分分离，使他们独立地进行变化。
其实就是，一个类存在两个维度的变化，且这两个维度都需要进行扩展。

拿汽车在路上行驶的来说。既有小汽车又有公共汽车，它们都不但能在市区中的公路上行驶，也能在高速公路上行驶。这你会发现，对于交通工具（汽车）有不同的类型，它们所行驶的环境（路）也有不同类型，在软件系统中就要适应两个方面（不同车型，不同道路）的变化，怎样实现才能应对这种变化呢？

在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。Bridge模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承这两个面向对象原则。

示例

首先看一下不应用桥接模式时的上述汽车例子代码：

//基类 路 
class Road { 
    void run() { 
        System.out.println("路"); 
    } 
} 
//市区街道 
class Street extends Road { 
    void run() { 
        System.out.println("市区街道"); 
    } 
} 
//高速公路 
class SpeedWay extends Road { 
    void run() { 
        System.out.println("高速公路"); 
    } 
} 
//小汽车在市区街道行驶 
class CarOnStreet extends Street { 
    void run() { 
        System.out.println("小汽车在市区街道行驶"); 
    } 
} 
//小汽车在高速公路行驶 
class CarOnSpeedWay extends SpeedWay { 
    void run() { 
        System.out.println("小汽车在高速公路行驶"); 
    } 
} 
//公交车在市区街道行驶 
class BusOnStreet extends Street { 
    void run() { 
        System.out.println("公交车在市区街道行驶"); 
    } 
} 
//公交车在高速公路行驶 
class BusOnSpeedWay extends SpeedWay { 
    void run() { 
        System.out.println("公交车在高速公路行驶"); 
    } 
} 
//测试 
public static void main(String[] args) { 

    //小汽车在高速公路行驶 
    CarOnSpeedWay carOnSpeedWay = new CarOnSpeedWay(); 
    carOnSpeedWay.run(); 
    //公交车在市区街道行驶 
    BusOnStreet busOnStreet = new BusOnStreet(); 
    busOnStreet.run(); 

} 

但是我们说这样的设计是脆弱的，仔细分析就可以发现，它还是存在很多问题，首先它在遵循开放-封闭原则的同时，违背了类的单一职责原则，即一个类只有一个引起它变化的原因，而这里引起变化的原因却有两个，即路类型的变化和汽车类型的变化；其次是重复代码会很多，不同的汽车在不同的路上行驶也会有一部分的代码是相同的；

再次是类的结构过于复杂，继承关系太多，难于维护，最后最致命的一点是扩展性太差。如果变化沿着汽车的类型和不同的道路两个方向变化，我们会看到这个类的结构会迅速的变庞大。
接下来我们再看一下应用了桥接模式之后的代码：

abstract class AbstractRoad{ 
    AbstractCar aCar; 
    void run(){}; 
} 
abstract class AbstractCar{ 
    void run(){}; 
} 

class Street extends AbstractRoad{ 
    @Override 
    void run() { 
        // TODO Auto-generated method stub 
        super.run(); 
        aCar.run(); 
        System.out.println("在市区街道行驶"); 
    } 
} 
class SpeedWay extends AbstractRoad{ 
    @Override 
    void run() { 
        // TODO Auto-generated method stub 
        super.run(); 
        aCar.run(); 
        System.out.println("在高速公路行驶"); 
    } 
} 
class Car extends AbstractCar{ 
    @Override 
    void run() { 
        // TODO Auto-generated method stub 
        super.run(); 
        System.out.print("小汽车"); 
    } 
} 
class Bus extends AbstractCar{ 
    @Override 
    void run() { 
        // TODO Auto-generated method stub 
        super.run(); 
        System.out.print("公交车"); 
    } 
} 

public static void main(String[] args){ 

    AbstractRoad speedWay = new SpeedWay(); 
    speedWay.aCar = new Car(); 
    speedWay.run(); 

    AbstractRoad street = new Street(); 
    street.aCar = new Bus(); 
    street.run(); 
} 

可以看到，通过对象组合的方式，Bridge 模式把两个角色之间的继承关系改为了耦合的关系，从而使这两者可以从容自若的各自独立的变化，这也是Bridge模式的本意。
这样增加了客户程序与路与汽车的耦合。其实这样的担心是没有必要的，因为这种耦合性是由于对象的创建所带来的，完全可以用创建型模式去解决。在应用时结合创建型设计模式来处理具体的问题。

Android

在Android中桥接模式用的很多，举个例子，对于一个View来说，它有两个维度的变化，一个是它的描述比如Button、TextView等等他们是View的描述维度上的变化，另一个维度就是将View真正绘制到屏幕上，这跟Display、HardwareLayer和Canvas有关。这两个维度可以看成是桥接模式的应用。

重构

暂无

感悟

本文是在看完《重构：改善既有代码之道》，开始看四人帮的《设计模式：可复用面向对象软件的基础》之前，结合多篇博文、实际项目与个人理解写下的。
推荐一定要在有所积累甚至遇到一些你已经没必要用以往经验解决的问题（这样的解决是指最佳方案，而不是只求解决就好）的时候去看这两个思想，共鸣真的很重要。
而对于这种体系庞杂的技术知识的学习，我一向不建议只看几篇博文就了事，这样大多只会留于表面，除了拒绝纸上谈兵多实践之外，很多最重要的内容往往在书里才能说得详尽，就像各个模式之间怎么协调，各个模式之间有什么区别，多种多样的使用场景，在一个模式就能写一篇论文的情况下，几篇博文怎么可能学得尽。
最早看设计模式是在两年半前，那时候还没毕业，看的是《大话设计模式》，那时候没有多少积累，对架构最说得上的就一个MVC，所以即使看的是以通俗著称的《大话》还是云里雾里，看没两章就放弃了。
但是在代码量不断的积累和对问题不断的发现之后，再重新去看《重构》与《设计模式》，这时候的感觉是完全不一样的，特别在我之前做了一段时间项目的重构之后，不夸张地说，在看《重构》这本书时，每一章都有那种让我相见恨晚的感觉。
技术方面的成长是多方面的，一方面在于经验的积累，但是经验的积累受限于很多现实因素，另一方面的成长则是思想上的进化，当然这也可以通过实际做项目来提升，但是同样的，通过项目来学习总有一天会到瓶颈，这时候就代表你该去收获那些巨人们留下的思想了。
之前有在一些地方看过重构无用、设计模式无用之类的理论，其实并不是重构与设计模式无用，而是自己还没有到能觉得它们有用的境界，设计模式绝不是偶尔挂在嘴边聊聊两句定义就好的谈资，作为java程序员必读的三本书之一的《设计模式》，能够这么长时间传承下来自有其底蕴所在。
最后吐槽一下，《设计模式》这本书真的是神书，可是真的也晦涩难懂，很大一部分原因在于四人帮这四位大神对设计模式的深度理解而造成写书时极其简练抽象的表述，所以在坚持完前面两章后再次宣告放弃，转身投向《Head First：设计模式》的怀抱，前者200多页，后者700多页，但是哪本好读些大家都懂。
不过重构与设计模式本身就都不是能一蹴即就的，这两者都是需要不断地应用、重新认识、再应用，这样一直重复之后才能完全融会贯通，所以也不必纠结于今天看完就要全部掌握，每隔一段时间再看一下，遇到问题的时候回过头来向其寻找解决方案，这才是学习这两大思想的正途。
把《重构》《设计模式》这类更偏向于思想层面的知识放到年初就学也是为了之后进一步学习《Effective Java》、《Java编程思想》与Android源码做铺垫，阅读源码最佳的方法不是从第一行开始往下读，要么是通过问题出发，以点及面；要么就是你先试图从编码者的思想层面出发，有时候当你发现了这个模块的设计思路与模式之后，很多东西都是一点就通的，你甚至知识看到一个模块的类结构就知道整个模块的大体内容，然后就像是你自己写的这些代码一样，找任何东西都轻而易举。就像如果你不懂泛型，即使写过四五个大项目，看到一堆用上泛型的第三方库的源码一样懵逼。

参考

从Android代码中来记忆23种设计模式
Android 源码中的工厂方法模式
Android设计模式（十二）－－抽象工厂模式
Java设计模式二：抽象工厂模式(Abstract Factory)/工厂方法(Factory Method)
Android源码中的命令模式
Java设计模式系列之迭代器模式
《JAVA与模式》之访问者模式
设计模式读书笔记—–中介者模式
java设计模式之外观模式（门面模式）
组合模式
JAVA设计模式初探之适配器模式
Java设计模式（7）装饰模式（Decorator模式）
《JAVA与模式》之享元模式
JAVA设计模式初探之桥接模式
说说Java代理模式
Java 代理模式和装饰者模式的区别
Java设计模式——代理模式实现及原理