从Android代码中来记忆23种设计模式

原文链接：http://www.jianshu.com/p/1a9f571ad7c0
 

 

相信大家都曾经下定决心把23种设计模式牢记于心，每次看完之后过一段时间又忘记了~，又得回去看，脑子里唯一依稀记得的是少数设计模式的大致的定义。其实，网上很多文章讲得都非常好，我也曾经去看过各种文章。也曾一直苦恼这些难以永久记下的设计模式，直到我接触到了《Android源码设计模式解析与实战》——何红辉与关爱明著，发现原来其实我们在Android中都接触过这些设计模式，只是我们不知道而已。既然我们都接触过，我们只需一一对号入座，对设计模式的记忆就不用死记硬背了！这里自愿无偿做个广告，《Android源码设计模式解析与实战》这本书真心不错，每个Android程序员最好都去翻翻...正如你所想的那样，本文是从这本书中的总结，相信你也会跟我一样，从中获益。

面向对象的六大原则

首先，我们为什么要学习设计模式。主要是这些模式是前人总结的经验，使用这些模式能让我们的程序更健壮、更稳定、容易扩展等等优点。在编写面向对象程序时，我们需要遵循以下6个原则，能让我们的程序维护起来更轻松~（当然还有其它好处）。

1 单一职责原则
单一原则很简单，就是将一组相关性很高的函数、数据封装到一个类中。换句话说，一个类应该有职责单一。

2 开闭原则

开闭原则理解起来也不复杂，就是一个类应该对于扩展是开放的，但是对于修改是封闭的。我们知道，在开放的app或者是系统中，经常需要升级、维护等，这就要对原来的代码进行修改，可是修改时容易破坏原有的系统，甚至带来一些新的难以发现的BUG。因此，我们在一开始编写代码时，就应该注意尽量通过扩展的方式实现新的功能，而不是通过修改已有的代码实现。

3 里氏替换原则

里氏替换原则的定义为：所有引用基类的地方必须能透明地使用其子类对象。定义看起来很抽象，其实，很容易理解，本质上就是说，要好好利用继承和多态。简单地说，就是以父类的形式声明的变量（或形参），赋值为任何继承于这个父类的子类后不影响程序的执行。看一组代码你就明白这个原则了：

//窗口类
public class Window(){
    public void show(View child){
        child.draw();
    }
}
public abstract class View(){
    public abstract void draw();
    public void measure(int widht,int height){
        //测量视图大小
    }
}
public class Button extends View{
    public void draw(){
        //绘制按钮
    }
}

public class TextView extends View{
    public void draw(){
        //绘制文本
    }
}

Window 类中show函数需要传入View，并且调用View对象的draw函数。而每个继承于View的子对象都有draw的实现，不存在继承于View但是却没实现draw函数的子类（abstract方法必须实现）。我们在抽象类设计之时就运用到了里氏替换原则。

4 依赖倒置原则

依赖倒置主要是实现解耦，使得高层次的模块不依赖于低层次模块的具体实现细节。怎么去理解它呢，我们需要知道几个关键点：

（1）高层模块不应该依赖底层模块（具体实现），二者都应该依赖其抽象（抽象类或接口）
（2）抽象不应该依赖细节（废话，抽象类跟接口肯定不依赖具体的实现了）
（3）细节应该依赖于抽象（同样废话，具体实现类肯定要依赖其继承的抽象类或接口）

其实，在我们用的Java语言中，抽象就是指接口或者抽象类，二者都是不能直接被实例化；细节就是实现类，实现接口或者继承抽象类而产生的类，就是细节。使用Java语言描述就简单了：就是各个模块之间相互传递的参数声明为抽象类型，而不是声明为具体的实现类；

5 接口隔离原则

接口隔离原则定义：类之间的依赖关系应该建立在最小的接口上。其原则是将非常庞大的、臃肿的接口拆分成更小的更具体的接口。

6 迪米特原则

描述的原则：一个对象应该对其他的对象有最少的了解。什么意思呢？就是说一个类应该对自己调用的类知道的最少。还是不懂？其实简单来说：假设类A实现了某个功能，类B需要调用类A的去执行这个功能，那么类A应该只暴露一个函数给类B，这个函数表示是实现这个功能的函数，而不是让类A把实现这个功能的所有细分的函数暴露给B。

开始学设计模式

学习了上面的六大原则之后，提前做了预热。现在开始，一起学习设计模式吧~

1 单例模式

单例模式可以说是最容易理解的模式了，也是应用最广的模式之一，先看看定义吧。

定义：确保单例类只有一个实例，并且这个单例类提供一个函数接口让其他类获取到这个唯一的实例。

什么时候需要使用单例模式呢：如果某个类，创建时需要消耗很多资源，即new出这个类的代价很大；或者是这个类占用很多内存，如果创建太多这个类实例会导致内存占用太多。

关于单例模式，虽然很简单，无需过多的解释，但是这里还要提个醒，其实单例模式里面有很多坑。我们去会会单例模式。最简单的单例模式如下：

public class Singleton{
    private static Singleton instance;
    //将默认的构造函数私有化，防止其他类手动new
    private Singleton(){};
    public static Singleton getInstance(){
        if(instance==null)
            instance=new Singleton();
         return instatnce;
    }
}

如果是单线程下的系统，这么写肯定没问题。可是如果是多线程环境呢？这代码明显不是线程安全的，存在隐患：某个线程拿到的instance可能是null，可能你会想，这有什么难得，直接在getInstance()函数上加sychronized关键字不就好了。可是你想过没有，每次调用getInstance()时都要执行同步，这带来没必要的性能上的消耗。注意，在方法上加sychronized关键字时，一个线程访问这个方法时，其他线程无法同时访问这个类其他sychronized方法。的我们看看另外一种实现：

public class Singleton{
    private static Singleton instance;
    //将默认的构造函数私有化，防止其他类手动new
    private Singleton(){};
    public static Singleton getInstance(){
        if(instance==null){
            sychronized(Singleton.class){
                if(instance==null)
                    instance=new Singleton();
            }
        }
        return instatnce;
    }
}

为什么需要2次判断是否为空呢？第一次判断是为了避免不必要的同步，第二次判断是确保在此之前没有其他线程进入到sychronized块创建了新实例。这段代码看上去非常完美，但是，，，却有隐患！问题出现在哪呢？主要是在instance=new Singleton();这段代码上。这段代码会编译成多条指令，大致上做了3件事:

（1）给Singleton实例分配内存
（2）调用Singleton()构造函数，初始化成员字段
（3）将instance对象指向分配的内存（此时instance就不是null啦~）

上面的（2）和（3）的顺序无法得到保证的，也就是说，JVM可能先初始化实例字段再把instance指向具体的内存实例，也可能先把instance指向内存实例再对实例进行初始化成员字段。考虑这种情况：一开始，第一个线程执行instance=new Singleton();这句时，JVM先指向一个堆地址，而此时，又来了一个线程2，它发现instance不是null，就直接拿去用了，但是堆里面对单例对象的初始化并没有完成，最终出现错误~ 。

看看另外一种方式：

public class Singleton{
    private volatile static Singleton instance;
    //将默认的构造函数私有化，防止其他类手动new
    private Singleton(){};
    public static Singleton getInstance(){
        if(instance==null){
            sychronized(Singleton.class){
                if(instance==null)
                    instance=new Singleton();
            }
        }
        return instatnce;
    }
}

相比前面的代码，这里只是对instance变量加了一个volatile关键字volatile关键字的作用是：线程每次使用到被volatile关键字修饰的变量时，都会去堆里拿最新的数据。换句话说，就是每次使用instance时，保证了instance是最新的。注意：volatile关键字并不能解决并发的问题，关于volatile请查看其它相关文章。但是volatile能解决我们这里的问题。

那么在安卓中哪些地方用到了单例模式呢？其实，我们在调用系统服务时拿到的Binder对象就是个单例。比如：

//获取WindowManager服务引用
WindowManager wm = (WindowManager)getSystemService(getApplication().WINDOW_SERVICE);  

其内部是通过单例的方式返回的，由于单例模式较简单，这里不去深究。

2 Builder模式

Builder模式是什么情况呢？我不想去提它的定义，因为他的定义：将一个复杂对象的构造与它的表示分离，使得同样的构造过程可以创建不同的表示。好吧，我还是提了。但是看了这个定义并没有什么luan用。我们看看具体在什么情况下用到Builder模式：主要是在创建某个对象时，需要设定很多的参数（通过setter方法），但是这些参数必须按照某个顺序设定，或者是设置步骤不同会得到不同结果。举个非常简单的例子：

public class MyData{
    private int id;
    private String num; 
    public void Test(){
        
    } 
    public void setId(int id){
        this.id=id;
    }

    public void setNum(String num){
        this.num=num+"id";
    }
 
     
}

当然了，没有人会这么去写代码。这里只是举例子，或者是有时候很多参数有这种类似的依赖关系时，通过构造函数未免太多参数了。回到主题，就是如果是上面的代码，该怎么办呢？你可能会说，那还不简单，先调用setId函数，再调用setNum函数。是的，没错。可是，万一你一不小心先调用了setNum呢？这是比较简单的示例，如果是比较复杂的，有很多变量之间依赖的关系，那你每次都得小心翼翼的把各个函数的执行步骤写正确。
我们看看Builder模式是怎么去做的：

public class MyBuilder{
    private int id;
    private String num;
    public MyData build(){
        MyData d=new MyData();
        d.setId(id);
        d.setNum(num);
        return t;
    }
    public MyBuilder setId(int id){
        this.id=id;
        return this;
    }
    public MyBuilder setNum(String num){
        this.num=num;
        return this;
    }

}

public class Test{
    public static void  main(String[] args){
        MyData d=new MyBuilder().setId(10).setNum("hc").build();
    }

}

注意到，Builer类的setter函数都会返回自身的引用this，这主要是用于链式调用，这也是Builder设计模式中的一个很明显的特征。

Android中用过的代码来记忆

记忆我这个例子没啥意义，我们前面说过，要通过Android中用过的代码来记忆，这样才可以不用死记硬背。那么在Android中哪里用到了Builder设计模式呢？哈哈~在创建对话框时，是不是跟上面有点类似呢？

AlertDialog.Builer builder=new AlertDialog.Builder(context);
builder.setIcon(R.drawable.icon)
    .setTitle("title")
    .setMessage("message")
    .setPositiveButton("Button1", 
        new DialogInterface.OnclickListener(){
            public void onClick(DialogInterface dialog,int whichButton){
                setTitle("click");
            }   
        })
    .create()
    .show();

这里的create()函数就想到上面代码中的build函数。看到这里是不是在内心中默默的把Builder设计模式拿下了？你并不用死记硬背~

3 原型模式

原型设计模式非常简单，就是将一个对象进行拷贝。对于类A实例a，要对a进行拷贝，就是创建一个跟a一样的类型A的实例b，然后将a的属性全部复制到b。
什么时候会用到原型模式呢？我个人认为，可以在类的属性特别多，但是又要经常对类进行拷贝的时候可以用原型模式，这样代码比较简洁，而且比较方便。

另外要注意的是，还有深拷贝和浅拷贝。深拷贝就是把对象里面的引用的对象也要拷贝一份新的对象，并将这个新的引用对象作为拷贝的对象引用。说的比较绕哈~，举个例子，假设A类中有B类的引用b，现在需要对A类实例进行拷贝，那么深拷贝就是，先对b进行一次拷贝得到nb，然后把nb作为A类拷贝的对象的引用，如此一层一层迭代拷贝，把所有的引用都拷贝结束。浅拷贝则不是。

原型模式比较简单，看看Android怎么运用原型模式：

Uri uri=Uri.parse("smsto:10086");
Intent shareIntent=new Intent(Intent.ACTION_SENDTO,uri);

//克隆副本
Intent intent=(Intetn)shareIntent.clone();
startActivity(intent);

或许我们平时不会这么去写，但是Intent对象确实提供了原型模式的函数clone()

4 工厂方法模式

定义：定义一个创建对象的接口，让子类决定实例化哪个类
先看一个例子：

public abstract class Product{
    public abstract void method();
} 

public class ConcreteProductA extends Prodect{
    public void method(){
        System.out.println("我是产品A!");
    }
}

public class ConcreteProductB extends Prodect{
    public void method(){
        System.out.println("我是产品B!");
    }
}
public  abstract class Factory{
    public abstract Product createProduct();
}

public class MyFactory extends Factory{

    public Product createProduct(){
        return new ConcreteProductA();
    }
}

看到上面的代码，是不是觉得工厂模式很简单呢？还可以通过传参的方式，让MyFactory的createProduct方法根据传入的参数决定是创建ConcreteProductA还是ConcreteProductB。

同样的，我们不希望记住这个例子，而是通过Android中的代码来记忆：
其实，在getSystemService方法中就是用到了工厂模式，他就是根据传入的参数决定创建哪个对象，当然了，由于返回的都是以单例模式存在的对象，因此不用new了，直接把单例返回就好。

public Object getSystemService(String name) {
    if (getBaseContext() == null) {
        throw new IllegalStateException("System services not available to Activities before onCreate()");
    }
    //........
    if (WINDOW_SERVICE.equals(name)) {
         return mWindowManager;
    } else if (SEARCH_SERVICE.equals(name)) {
        ensureSearchManager();
        return mSearchManager;
    }
    //.......
    return super.getSystemService(name);
  }

5 抽象工厂模式

抽象工厂模式：为创建一组相关或者是相互依赖的对象提供一个接口，而不需要制定他们的具体类
看个例子吧，将它跟工厂方法模式做个对比：

public abstract class AbstractProductA{
    public abstract void method();
}
public abstract class AbstractProdectB{
    public abstract void method();
}

public class ConcreteProductA1 extends AbstractProductA{
    public void method(){
        System.out.println("具体产品A1的方法！");
    }
}
public class ConcreteProductA2 extends AbstractProductA{
    public void method(){
        System.out.println("具体产品A2的方法！");
    }
}
public class ConcreteProductB1 extends AbstractProductB{
    public void method(){
        System.out.println("具体产品B1的方法！");
    }
}
public class ConcreteProductB2 extends AbstractProductB{
    public void method(){
        System.out.println("具体产品B2的方法！");
    }
}

public abstract class AbstractFactory{
    public abstract AbstractProductA createProductA();
    
    public abstract AbstractProductB createProductB();
}

public  class ConcreteFactory1 extends AbstractFactory{
    public  AbstractProductA createProductA(){
        return new ConcreteProductA1();
    }
    
    public  AbstractProductB createProductB(){
        return new ConcreteProductB1();
    }
}

public  class ConcreteFactory2 extends AbstractFactory{
    public  AbstractProductA createProductA(){
        return new ConcreteProductA2();
    }
    
    public  AbstractProductB createProductB(){
        return new ConcreteProductB2();
    }
}

其实Android源码中对抽象工厂出现的比较少,好在抽象工厂方法并不复杂，很容易记住，我们可以从Service中去理解，Service的onBind方法可以看成是一个工厂方法，从framework角度来看Service,可以看成是一个具体的工厂，这相当于一个抽象工厂方法模式的雏形。

 public class BaseService extends Service{
    @Nullable
    @Override
    public IBinder onBind(Intent intent){
        return new Binder();
    }
    
}

6 策略模式

定义：有一系列的算法，将每个算法封装起来（每个算法可以封装到不同的类中），各个算法之间可以替换，策略模式让算法独立于使用它的客户而独立变化。

举个例子来理解吧，比如，你现在又很多排序算法：冒泡、希尔、归并、选择等等。我们要根据实际情况来选择使用哪种算法，有一种常见的方法是，通过if...else或者case...等条件判断语句来选择。但是这个类的维护成本会变高，维护时也容易发生错误。

如何使用策略模式呢，我不打算写示例代码了，简单描述一下，就将前面说的算法选择进行描述。我们可以定义一个算法抽象类AbstractAlgorithm，这个类定义一个抽象方法sort()。每个具体的排序算法去继承AbstractAlgorithm类并重写sort()实现排序。在需要使用排序的类Client类中，添加一个setAlgorithm(AbstractAlgorithm al)；方法将算法设置进去，每次Client需要排序而是就调用al.sort()。

不知道简单描述能不能让你理解~

看看Android中哪里出现了策略模式，其中在属性动画中使用时间插值器的时候就用到了。在使用动画时，你可以选择线性插值器LinearInterpolator、加速减速插值器AccelerateDecelerateInterpolator、减速插值器DecelerateInterpolator以及自定义的插值器。这些插值器都是实现根据时间流逝的百分比来计算出当前属性值改变的百分比。通过根据需要选择不同的插值器，实现不同的动画效果。这些比较好理解，就不去粘贴Android源码了。

7 状态模式

状态模式中，行为是由状态来决定的，不同状态下有不同行为。状态模式和策略模式的结构几乎是一模一样的，主要是他们表达的目的和本质是不同。状态模式的行为是平行的、不可替换的，策略模式的行为是彼此独立可相互替换的。
举个例子把，比如电视，电视有2个状态，一个是开机，一个是关机，开机时可以切换频道，关机时切换频道不做任何响应。

public interface TvState{
    public void nextChannerl();
    public void prevChannerl();
    public void turnUp();
    public void turnDown();
}

public class PowerOffState implements TvState{
    public void nextChannel(){}
    public void prevChannel(){}
    public void turnUp(){}
    public void turnDown(){}
    
}


public class PowerOnState implements TvState{
    public void nextChannel(){
        System.out.println("下一频道");
    }
    public void prevChannel(){
        System.out.println("上一频道");
    }
    public void turnUp(){
        System.out.println("调高音量");
    }
    public void turnDown(){
        System.out.println("调低音量"); 
    }
    
}

public interface PowerController{
    public void powerOn();
    public void powerOff();
}

public class TvController implements PowerController{
    TvState mTvState;
    public void setTvState(TvStete tvState){
        mTvState=tvState;
    }
    public void powerOn(){
        setTvState(new PowerOnState());
        System.out.println("开机啦");
    }
    public void powerOff(){
        setTvState(new PowerOffState());
        System.out.println("关机啦");
    }
    public void nextChannel(){
        mTvState.nextChannel();
    }
    public void prevChannel(){
        mTvState.prevChannel();
    }
    public void turnUp(){
        mTvState.turnUp();
    }
    public void turnDown(){
        mTvState.turnDown();
    }
    
}


public class Client{
    public static void main(String[] args){
        TvController tvController=new TvController();
        tvController.powerOn();
        tvController.nextChannel();
        tvController.turnUp();
        
        tvController.powerOff();
        //调高音量，此时不会生效
        tvController.turnUp();
    }


}

在Android源码中，哪里有用到状态模式呢？其实很多地方用到了，举一个地方例子，就是WIFI管理模块。当WIFI开启时，自动扫描周围的接入点，然后以列表的形式展示；当wifi关闭时则清空。这里wifi管理模块就是根据不同的状态执行不同的行为。由于代码太多，我就不手打敲入了~我们只要知道大致Android里面在哪里用到了以及大概是怎么用的就好。

8 责任链模式

定义：使多个对象都有机会处理请求，从而避免请求的发送者和接受者直接的耦合关系，将这些对象连成一条链，并沿这条链传递该请求，直到有对象处理它为止。

相信聪明的你很容易理解吧，基本不需要例子来解释了，直接进如到Android源码中哪里用到了责任链：在Android处理点击事件时，父View先接收到点击事件，如果父View不处理则交给子View，依次往下传递~

9 解释器模式

定义：给定一个语言，定义它的语法，并定义一个解释器，这个解释器用于解析语言。

从定义中看起来比较抽象，其实，很简单，很容易理解！就是相当于自定义一个格式的文件，然后去解析它。不用理解的那么复杂！

我们看看Android中哪里用到了，从我们第一次学Android时就知道，四大组件需要在AndroidManifest.xml中定义，其实AndroidManifest.xml就定义了，等标签（语句）的属性以及其子标签，规定了具体的使用（语法），通过PackageManagerService（解释器）进行解析。

10 命令模式

定义：命令模式将每个请求封装成一个对象，从而让用户使用不同的请求把客户端参数化；将请求进行排队或者记录请求日志，以及支持可撤销操作。

举个例子来理解：当我们点击“关机”命令，系统会执行一系列操作，比如暂停事件处理、保存系统配置、结束程序进程、调用内核命令关闭计算机等等，这些命令封装从不同的对象，然后放入到队列中一个个去执行，还可以提供撤销操作。

那么Android中哪里用到了命令模式呢？在framework层还真不多。但是在底层却用到了，一个比较典型的例子就是在Android事件机制中，底层逻辑对事件的转发处理。每次的按键事件会被封装成NotifyKeyArgs对象。通过InputDispatcher封装具体的事件操作。

11 观察者模式

定义：定义了对象之间的一对多的关系，其实就是1对n，当“1”发生变化时，“n”全部得到通知，并更新。

观察者模式一个比较经典的应用就是：订阅——发布系统。很容易理解，发布消息时，将消息发送给每个订阅者。我们常用的微信公众号就是典型，当我们关注某个公众号时，每当公众号推送消息时，我们就会去接收到消息，当然了，每个订阅（关注）公众号的的人都能接收到公众号推送的消息。

那么Android哪里用到了观察者模式呢？我们看看ListView的适配器，有个函数notifyDataSetChanged()函数，这个函数其实就是通知ListView的每个Item，数据源发生了变化，请各位Item重新刷新一下。

12 备忘录模式

备忘录模式定义：在不破坏封闭的前提下，捕获一个对象的内部状态，并在对象之外保存这个状态，这样，以后就可将对象恢复到原先保存的状态中。

其实就是相当于一个提前备份，一旦出现啥意外，能够恢复。像我们平时用的word软件，意外关闭了，它能帮我们恢复。其实就是它自动帮我们备份过。

那么Android哪里用到了备忘录模式呢？Activity的onSaveInstanceState和onRestoreInstanceState就是用到了备忘录模式，分别用于保存和恢复。

13 迭代器模式

迭代器模式定义：提供一种方法顺序访问一个容器对象中的各个元素，而不需要暴露该对象的内部表示。

相信熟悉Java的你肯定知道，Java中就有迭代器Iterator类，本质上说，它就是用迭代器模式。

按照惯例，看看Android中哪里用到了迭代器模式，Android源码中，最典型的就是Cursor用到了迭代器模式，当我们使用SQLiteDatabase的query方法时，返回的就是Cursor对象，通过如下方式去遍历：

cursor.moveToFirst();
do{
//cursor.getXXX(int);
}while(cursor.moveToNext);

14 模板方法模式

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

不用解释太多，感觉越解释越糊涂，直接拿Android中的源码来说事！

我们知道，启动一个Activity过程非常复杂，如果让开发者每次自己去调用启动Activity过程无疑是一场噩梦。好在启动Activity大部分代码时不同的，但是有很多地方需要开发者定制。也就是说，整体算法框架是相同的，但是将一些步骤延迟到子类中，比如Activity的onCreate、onStart等等。这样子类不用改变整体启动Activity过程即可重定义某些具体的操作了~。

15 访问者模式

定义：封装一些作用于某种数据结构中各元素的操作，它可以在不改变这个数据结构的前提下定义作用于这些元素的新的操作。

访问者模式是23种设计模式中最复杂的一个，但他的使用率并不高，大部分情况下，我们不需要使用访问者模式，少数特定的场景才需要。

Android中运用访问者模式，其实主要是在编译期注解中，编译期注解核心原理依赖APT(Annotation Processing Tools)，著名的开源库比如ButterKnife、Dagger、Retrofit都是基于APT。APT的详细使用这里不提，后面我会写关于APT相关的文章，敬请期待~

16 中介者模式

定义：中介者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显调用，从而使他们可以轻松耦合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用保证这些作用可以彼此独立的变化，中介者模式将多对多的相互作用转为一对多的相互作用。

什么时候用中介者模式呢？其实，中介者对象是将系统从网状结构转为以调停者为中心的星型结构。

举个简单的例子，一台电脑包括：CPU、内存、显卡、IO设备。其实，要启动一台计算机，有了CPU和内存就够了。当然，如果你需要连接显示器显示画面，那就得加显卡，如果你需要存储数据，那就要IO设备，但是这并不是最重要的，它们只是分割开来的普通零件而已，我们需要一样东西把这些零件整合起来，变成一个完整体，这个东西就是主板。主板就是起到中介者的作用，任何两个模块之间的通信都会经过主板协调。

那么Android中那些地方用到了中介者模式呢？在Binder机制中，就用到了中介者模式，对Binder不是很熟悉的童鞋请参考我的《 简单明了，彻底地理解Binder》。我们知道系统启动时，各种系统服务会向ServiceManager提交注册，即ServiceManager持有各种系统服务的引用 ，当我们需要获取系统的Service时，比如ActivityManager、WindowManager等（它们都是Binder），首先是向ServiceManager查询指定标示符对应的Binder，再由ServiceManager返回Binder的引用。并且客户端和服务端之间的通信是通过Binder驱动来实现，这里的ServiceManager和Binder驱动就是中介者。

17 代理模式

定义：为其他类提供一种代理以控制这个对象的访问。
其实代理模式我们平时用的也比较多，其实比较好理解，就是当我们需要对一个对象进行访问时，我们不直接对这个对象进行访问，而是访问这个类的代理类，代理类能帮我们执行我们想要的操作。代理模式比较容易理解，既然你来看这篇文章相信你对代理模式不陌生。

我们直接看看代理模式在Android中的应用，如果你查看AIDL生成的代码就知道，它会根据当前的线程判断是否要跨进程访问，如果不需要跨进程就直接返回实例，如果需要跨进程则返回一个代理，这个代理干什么事情呢?我们在《 简单明了，彻底地理解Binder》提到，在跨进程通信时，需要把参数写入到Parcelable对象，然后再执行transact函数，我们要写的代码挺多的。AIDL通过生成一个代理类，代理类中自动帮我们写好这些操作。

18 组合模式

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

上面的定义不太好理解，我们直接从Android中用到的组合模式说起。我们知道，Android中View的结构是树形结构，每个ViewGroup包含一系列的View，而ViewGroup本身又是View。这是Android中非常典型的组合模式。

19 适配器模式

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

其实适配器模式很容易理解，我们在Android开发时也经常用到。比较典型的有ListView和RecyclerView。为什么ListView需要使用适配器呢？主要是，ListView只关心它的每个ItemView，而不关心这个ItemView具体显示的是什么。而我们的数据源存放的是要显示的内容，它保存了每一个ItemView要显示的内容。ListView和数据源之间没有任何关系，这时候，需要通过适配器，适配器提供getView方法给ListView使用，每次ListView只需提供位置信息给getView函数，然后getView函数根据位置信息向数据源获取对应的数据，根据数据返回不同的View。

20 装饰模式

定义：动态的给一个对象添加额外的智者，就增加功能来说，装饰模式比子类继承的方式更灵活。
通过简单代码来理解装饰模式：

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

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

}

public class Decorator{
    private Component component;
    public Decorator(Component component){
        this.component=component;
    }
    public void operate(){
        operateA();
        component.operate();
        operateB();
    }
    public void operateA(){
        //具体操作
    }
    public void operateB(){
        //具体操作
    }
}

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

21 享元模式

定义：使用享元对象有效地支持大量的细粒度对象。

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

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

22 外观模式

定义：要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。

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

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

23 桥接模式

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

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

24 MVC、MVP、MVVP模式

MVC
全称为Model-View-Controller，也就是模型-视图-控制器。MVC结构如下图所示：

MVC

在Android中对MVC的应用很经典，我们的布局文件如main.xml就是对应View层，本地的数据库数据或者是网络下载的数据就是对应Model层，而Activity对应Controller层。

 

MVP
MVP全称为Model View Presenter，目前MVP在Android应用开发中越来越重要了，它的结构图如下：

MVP

它降低了View与Model之间的耦合。彻底将View与Model分离。MVP不是一种标准化的模式，它由很多种实现。

 

MVVM

全称是Mode View ViewModel,它的结构如下所示：

 

MVVM

我们在使用ListView时，会自定义一个ViewHolder,在RecyclerView中是必须使用ViewHolder，这主要是提高性能，因为不需要每次去调用findViewById来获取View。其实ViewHolder就是个ViewModel。

作者：huachao1001
链接：https://www.jianshu.com/p/1a9f571ad7c0
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

 

 

 

 

 

 

关于Java 23种设计模式的有趣见解

 

 

 

转载地址： 
http://www.jcodecraeer.com/a/chengxusheji/shejimoshi/2012/1029/482.html

在网络上流畅很广的一篇旧文，暂时没找到原作者，目前所看到的最早转载时间是 2005 年 2 月 28 日。作者用轻松的语言，形象解释了 23 种模式，有很好的启发作用。特此记录，方便自己查看。

创建型模式

1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory

工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。

2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻译机好卖）

建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。

3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。

工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。

4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你要不要）

原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。

5、SINGLETON—俺有6个漂亮的老婆，她们的老公都是我，我就是我们家里的老公Sigleton，她们只要说道“老公”，都是指的同一个人，那就是我(刚才做了个梦啦，哪有这么好的事)

单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。

结构型模式

6、ADAPTER—在朋友聚会上碰到了一个美女Sarah，从香港来的，可我不会说粤语，她不会说普通话，只好求助于我的朋友kent了，他作为我和Sarah之间的Adapter，让我和Sarah可以相互交谈了(也不知道他会不会耍我)

适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。

7、BRIDGE—早上碰到MM，要说早上好，晚上碰到MM，要说晚上好；碰到MM穿了件新衣服，要说你的衣服好漂亮哦，碰到MM新做的发型，要说你的头发好漂亮哦。不要问我“早上碰到MM新做了个发型怎么说”这种问题，自己用BRIDGE组合一下不就行了

桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。

8、COMPOSITE—Mary今天过生日。“我过生日，你要送我一件礼物。”“嗯，好吧，去商店，你自己挑。”“这件T恤挺漂亮，买，这条裙子好看，买，这个包也不错，买。”“喂，买了三件了呀，我只答应送一件礼物的哦。”“什么呀，T恤加裙子加包包，正好配成一套呀，小姐，麻烦你包起来。”“……”，MM都会用Composite模式了，你会了没有？

合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。

9、DECORATOR—Mary过完轮到Sarly过生日，还是不要叫她自己挑了，不然这个月伙食费肯定玩完，拿出我去年在华山顶上照的照片，在背面写上“最好的的礼物，就是爱你的Fita”，再到街上礼品店买了个像框（卖礼品的MM也很漂亮哦），再找隔壁搞美术设计的Mike设计了一个漂亮的盒子装起来……，我们都是Decorator，最终都在修饰我这个人呀，怎么样，看懂了吗？

装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。

10、FACADE—我有一个专业的Nikon相机，我就喜欢自己手动调光圈、快门，这样照出来的照片才专业，但MM可不懂这些，教了半天也不会。幸好相机有Facade设计模式，把相机调整到自动档，只要对准目标按快门就行了，一切由相机自动调整，这样MM也可以用这个相机给我拍张照片了。

门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。

11、FLYWEIGHT—每天跟MM发短信，手指都累死了，最近买了个新手机，可以把一些常用的句子存在手机里，要用的时候，直接拿出来，在前面加上MM的名字就可以发送了，再不用一个字一个字敲了。共享的句子就是Flyweight，MM的名字就是提取出来的外部特征，根据上下文情况使用。

享元模式：FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能影响内蕴状态，它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量。

12、PROXY—跟MM在网上聊天，一开头总是“hi,你好”,“你从哪儿来呀？”“你多大了？”“身高多少呀？”这些话，真烦人，写个程序做为我的Proxy吧，凡是接收到这些话都设置好了自动的回答，接收到其他的话时再通知我回答，怎么样，酷吧。

代理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象必须有系统的其他角色代为创建并传入。

行为模式

13、CHAIN OF RESPONSIBLEITY—晚上去上英语课，为了好开溜坐到了最后一排，哇，前面坐了好几个漂亮的MM哎，找张纸条，写上“Hi,可以做我的女朋友吗？如果不愿意请向前传”，纸条就一个接一个的传上去了，糟糕，传到第一排的MM把纸条传给老师了，听说是个老处女呀，快跑!

责任链模式：在责任链模式中，很多对象由每一个对象对其下家的引用而接

起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。

14、COMMAND—俺有一个MM家里管得特别严，没法见面，只好借助于她弟弟在我们俩之间传送信息，她对我有什么指示，就写一张纸条让她弟弟带给我。这不，她弟弟又传送过来一个COMMAND，为了感谢他，我请他吃了碗杂酱面，哪知道他说：“我同时给我姐姐三个男朋友送COMMAND，就数你最小气，才请我吃面。”，:-(

命令模式：命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。系统支持命令的撤消。

15、INTERPRETER—俺有一个《泡MM真经》，上面有各种泡MM的攻略，比如说去吃西餐的步骤、去看电影的方法等等，跟MM约会时，只要做一个Interpreter，照着上面的脚本执行就可以了。

解释器模式：给定一个语言后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方法，代表对命令对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。

16、ITERATOR—我爱上了Mary，不顾一切的向她求婚。

Mary：“想要我跟你结婚，得答应我的条件”

我：“什么条件我都答应，你说吧”

Mary：“我看上了那个一克拉的钻石”

我：“我买，我买，还有吗？”

Mary：“我看上了湖边的那栋别墅”

我：“我买，我买，还有吗？”

Mary：“你的小弟弟必须要有50cm长”

我脑袋嗡的一声，坐在椅子上，一咬牙：“我剪，我剪，还有吗？”

……

迭代子模式：迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起形成的总体称之为聚集，聚集对象是能够包容一组对象的容器对象。迭代子模式将迭代逻辑封装到一个独立的子对象中，从而与聚集本身隔开。迭代子模式简化了聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象，每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。

17、MEDIATOR—四个MM打麻将，相互之间谁应该给谁多少钱算不清楚了，幸亏当时我在旁边，按照各自的筹码数算钱，赚了钱的从我这里拿，赔了钱的也付给我，一切就OK啦，俺得到了四个MM的电话。

调停者模式：调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。

18、MEMENTO—同时跟几个MM聊天时，一定要记清楚刚才跟MM说了些什么话，不然MM发现了会不高兴的哦，幸亏我有个备忘录，刚才与哪个MM说了什么话我都拷贝一份放到备忘录里面保存，这样可以随时察看以前的记录啦。

备忘录模式：备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一个对象的状态捉住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。

19、OBSERVER—想知道咱们公司最新MM情报吗？加入公司的MM情报邮件组就行了，tom负责搜集情报，他发现的新情报不用一个一个通知我们，直接发布给邮件组，我们作为订阅者（观察者）就可以及时收到情报啦

观察者模式：观察者模式定义了一种一队多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。

20、STATE—跟MM交往时，一定要注意她的状态哦，在不同的状态时她的行为会有不同，比如你约她今天晚上去看电影，对你没兴趣的MM就会说“有事情啦”，对你不讨厌但还没喜欢上的MM就会说“好啊，不过可以带上我同事么？”，已经喜欢上你的MM就会说“几点钟？看完电影再去泡吧怎么样？”，当然你看电影过程中表现良好的话，也可以把MM的状态从不讨厌不喜欢变成喜欢哦。

状态模式：状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子类。

21、STRATEGY—跟不同类型的MM约会，要用不同的策略，有的请电影比较好，有的则去吃小吃效果不错，有的去海边浪漫最合适，单目的都是为了得到MM的芳心，我的追MM锦囊中有好多Strategy哦。

策略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中提供。由于算法和环境独立开来，算法的增减，修改都不会影响到环境和客户端。

22、TEMPLATE METHOD——看过《如何说服女生上床》这部经典文章吗？女生从认识到上床的不变的步骤分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步骤(Template method)，但每个步骤针对不同的情况，都有不一样的做法，这就要看你随机应变啦(具体实现)；

模板方法模式：模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造子的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架，而将逻辑的细节留给具体的子类去实现。

23、VISITOR—情人节到了，要给每个MM送一束鲜花和一张卡片，可是每个MM送的花都要针对她个人的特点，每张卡片也要根据个人的特点来挑，我一个人哪搞得清楚，还是找花店老板和礼品店老板做一下Visitor，让花店老板根据MM的特点选一束花，让礼品店老板也根据每个人特点选一张卡，这样就轻松多了；

访问者模式：访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由的演化。访问者模式使得增加新的操作变的很容易，就是增加一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节点类中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问者类中，而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。