外观模式(facade)

要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。它提供一个高层次的接口，使得子系统更易于使用。

Android源码中Context是一个抽象类，使用了外观模式，它只是定义了抽象接口，真正的实现在ContextImpl类中。

  1. 在应用启动时，首先会fork一个子进程，并且调用ActivityThread.main方法启动该进程。ActivityThread又会构建Application对象，然后和Activity、ContextImpl关联起来，然后再调用Activity的onCreate、onStart、onResume函数使Activity运行起来。
  2. Activity启动之后，Android给我们提供了操作系统服务的统一入口，也就是Activity本身。这些工作并不是Activity自己实现的，而是将操作委托给Activity父类ContextThemeWrapper的mBase对象，这个对象的实现类就是ContextImpl。
  3. Activity的ContextImpl中有许多AlarmManager,PowerManager, PackageManager等，并实现了sendBroadcast()、startActivity()等方法。
  4. ContextImpl封装了这些功能，使得用户根本不需要知晓Instrumentation相关的信息，直接使用相关方法即可完成相应的工作

优点

  • 使用方便，使用外观模式客户端完全不需要知道子系统的实现过程；
  • 降低客户端与子系统的耦合；
  • 更好的划分访问层次；

缺点

  • 减少了可变性和灵活性；
  • 在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”；

桥接模式(bridge)

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

uml

角色介绍

  • 抽象化(Abstraction)角色：抽象化给出的定义，并保存一个对实现化对象的引用。
    修正抽象化(Refined Abstraction)角色：扩展抽象化角色，改变和修正父类对抽象化的定义。
  • 实现化(Implementor)角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接 口不一定和抽象化角色的接口定义相同，实际上，这两个接口可以非常不一样。实现当只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一化角色应层的操作。
  • 具体实现化(ConcreteImplementor)角色：这个角色给出实现化角色接口的具体实现。

ListView和BaseAdpater就是Bridge模式

uml

试想一下，视图的排列方式是无穷尽，是人们每个人开发的视图也是无穷尽的。而Android把最常用用的展现方式全部都封装了出来，而在实现角色通过Adapter模式来应变无穷无尽的视图需要。

优点

实现与使用实现的对象解耦，提供了可扩展性，客户对象无需担心操作的实现问题。 如果你采用了bridge模式，在处理新的实现将会非常容易。你只需定义一个新的具体实现类，并且实现它就好了，不需要修改任何其他的东西。但是如果你出现了一个新的具体情况，需要对实现进行修改时，就得先修改抽象的接口，再对其派生类进行修改，但是这种修改只会存在于局部,并且这种修改将变化的英雄控制在局部，并且降低了出现副作用的风险，而且类之间的关系十分清晰，如何实现一目了然。

Builder模式

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

模式的使用场景

  1. 相同的方法，不同的执行顺序，产生不同的事件结果时；
  2. 多个部件或零件，都可以装配到一个对象中，但是产生的运行结果又不相同时；
  3. 产品类非常复杂，或者产品类中的调用顺序不同产生了不同的效能，这个时候使用建造者模式非常合适；

AlertDialog使用了Builder模式。通过Builder来设置AlertDialog中的title, message, button等参数， 这些参数都存储在类型为AlertController.AlertParams的成员变量P中，AlertController.AlertParams中包含了与之对应的成员变量。在调用Builder类的create函数时才创建AlertDialog, 并且将Builder成员变量P中保存的参数应用到AlertDialog的mAlert对象中。

优点

  • 良好的封装性， 使用建造者模式可以使客户端不必知道产品内部组成的细节；
  • 建造者独立，容易扩展；
  • 在对象创建过程中会使用到系统中的一些其它对象，这些对象在产品对象的创建过程中不易得到。

缺点

  • 会产生多余的Builder对象以及Director对象，消耗内存；
  • 对象的构建过程暴露。

责任链模式(chain of responsibility)

一个请求沿着一条“链”传递，直到该“链”上的某个处理者处理它为止。

UML

Android中关于责任链模式比较明显的体现就是在事件分发过程中对事件的投递，其实严格来说，事件投递的模式并不是严格的责任链模式，但是其是责任链模式的一种变种体现。

优点

  • 责任链模式可以对请求者和处理者关系的解耦提高代码的灵活性。

缺点

  • 责任链模式的最大缺点是对链中责任人的遍历，如果责任人太多那么遍历必定会影响性能，特别是在一些递归调用中，要慎重。

命令模式(command)（TODO 没看懂）

将一个请求封装成一个对象，从而使你可用不同的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可撤销的操作。

模式的使用场景

  1. 系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。
  2. 系统需要在不同的时间指定请求、将请求排队和执行请求。
  3. 系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。
  4. 系统需要将一组操作组合在一起，即支持宏命令。

uml

角色介绍

  • 命令角色（Command）：定义命令的接口，声明具体命令类需要执行的方法。这是一个抽象角色。

  • 具体命令角色（ConcreteCommand）：命令接口的具体实现对象，通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。

  • 调用者角色（Invoker）：负责调用命令对象执行请求，通常会持有命令对象（可以持有多个命令对象）。Invoker是Client真正触发命令并要求命令执行相应操作的地方（使用命令对象的入口）。

  • 接受者角色（Receiver）：Receiver是真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。

  • 客户角色（Client）：Client可以创建具体的命令对象，并且设置命令对象的接收者。Tips：不能把Clinet理解为我们平常说的客户端，这里的Client是一个组装命令对象和接受者对象的角色，或者你把它理解为一个装配者。

命令模式其实就是对命令进行封装，将命令请求者和命令执行者的责任分离开来实现松耦合。

  • 每一个命令都是一个操作：请求的一方发出请求，要求执行一个操作；接收的一方收到请求，并执行操作。
  • 命令模式允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否被执行、何时被执行，以及是怎么被执行的。
  • 命令模式使请求本身成为一个对象，这个对象和其他对象一样可以被存储和传递。
  • 命令模式的关键在于引入了抽象命令接口，且发送者针对抽象命令接口编程，只有实现了抽象命令接口的具体命令才能与接收者相关联。

Android中的Runnable：客户端只需要new Thread(new Runnable(){}).start()就开始执行一系列相关的请求，这些请求大部分都是实现Runnable接口的匿名类。

优点

  1. 降低对象之间的耦合度。
  2. 新的命令可以很容易地加入到系统中。
  3. 可以比较容易地设计一个组合命令。
  4. 调用同一方法实现不同的功能

缺点

使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个命令都需要设计一个具体命令类，因此某些系统可能需要大量具体命令类，这将影响命令模式的使用。
比如上面的PeopleBean的属性增加，Receiver针对PeopleBean一个属性一个执行方法，一个Command的实现可以调用Receiver的一个执行方法，由此得需要设计多少个具体命令类呀！！

组合模式(composite)

又叫作部分-整体模式，它使我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以向处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦。 GoF在《设计模式》一书中这样定义组合模式：将对象组合成树形结构以表示“部分-整体”的层次结构。使得用户对单个对象和组合对象的使用具有一致性。
组合模式通用类图

模式的使用场景

  • 表示对象的部分-整体层次结构。
  • 从一个整体中能够独立出部分模块或功能的场景。

Adnroid系统中采用组合模式的组合视图类图。
enter image description here

使用组合模式组织起来的对象具有出色的层次结构，每当对顶层组合对象执行一个操作的时候，实际上是在对整个结构进行深度优先的节点搜索。但是这些优点都是用操作的代价换取的，比如顶级每执行一次 store.show 实际的操作就是整一颗树形结构的节点均遍历执行一次。

优点

  • 不破坏封装，整体类与局部类之间松耦合，彼此相对独立 。
  • 具有较好的可扩展性。
  • 支持动态组合。在运行时，整体对象可以选择不同类型的局部对象。
  • 整体类可以对局部类进行包装，封装局部类的接口，提供新的接口。

缺点

  • 整体类不能自动获得和局部类同样的接口。
  • 创建整体类的对象时，需要创建所有局部类的对象 。

工厂方法模式(factory method)(TODO 没完)

你要什么工厂造给你就是了，你不用管我是怎么造的，造好你拿去用就是了，奏是介么任性。任何需要生成对象的情况都可使用工厂方法替代生成。

1
2
3
4
5
6
7
8
9
10
11
12
13
/**
 * 果农类
 */
public class Grower {
	public static <T extends Fruits> T getFruits(Class<T> clz) {
		try {
			Fruits fruits = (Fruits) Class.forName(clz.getName()).newInstance();
			return (T) fruits;
		} catch (Exception e) {
			return null;
		}
	}
}
  • 简单工厂模式
  • 抽象工厂模式
  • 工厂方法模式

享元模式(flyweight)

通过共享有效支持大量的细粒度对象，节省系统中重复创建相同内容对象的性能消耗，进而提高应用程序的性能。
享元模式可分为单纯享元模式和复合享元模式。

模式的使用场景

面向对象编程在某些情况下会创建大量的细粒度对象，它们的产生，存储，销毁都会造成资源和性能上的损耗，可能会在程序运行时形成效率瓶颈，在遇到以下情况时，即可考虑使用享元模式：

  1. 一个应用程序使用了大量的对象，耗费大量的内存，降低了系统的效率。
  2. 这些对象的状态可以分离出内外两部分。
  3. 这些对象按照状态分成很多的组，当把删除对象的外部状态时，可以用相对较少的共享对象取代很多组对象。
  4. 应用程序不依赖这些对象的身份，即这些对象是不可分辨的。

在一般的开发中享元模式并不常用，其常常应用于系统底层的开发，以便解决系统的性能问题。

将事物的共性共享，同时又保留它的个性。为了做到这点，享元模式中区分了内蕴状态(Internal State)和外蕴状态(External State)。内蕴状态就是共性，外蕴状态就是个性了。内蕴状态存储在享元内部，不会随环境改变而变化，是可以共享的；外蕴状态是不可以共享的，它随环境的改变而变化，通常外蕴状态是由客户端来保持的（因为环境的变化是由客户端引起的）。

优点

  • 大幅度地降低内存中对象的数量，节省系统资源的开销

    缺点

  • 为了使对象可以共享，享元模式需要将部分状态外部化，使得系统的逻辑变得复杂。
  • 读取状态外部化的享元对象，影响了系统速度，使运行时间有所加长。

迭代器模式(Iterator)

迭代器（Iterator）模式，又叫做游标（Cursor）模式。GOF给出的定义为：提供一种方法访问一个容器（container）对象中各个元素，而又不需暴露该对象的内部细节。

对Android来说,集合Collection实现了Iterable接口,就是说,无论是List的一大家子还是Map的一大家子,我们都可以使用Iterator来遍历里面的元素。

一个集合想要实现Iterator很是很简单的,需要注意的是每次需要重新生成一个Iterator来进行遍历.且遍历过程是单方向的,HashMap是通过一个类似HashIterator来实现的。

优点

  • 面向对象设计原则中的单一职责原则，对于不同的功能,我们要尽可能的把这个功能分解出单一的职责，不同的类去承担不同的职责。Iterator模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样不暴露集合的内部结构，又可让外部代码透明的访问集合内部的数据。

缺点

  • 会产生多余的对象，消耗内存；
  • 遍历过程是一个单向且不可逆的遍历
  • 如果你在遍历的过程中,集合发生改变,变多变少,内容变化都是算,就会抛出来ConcurrentModificationException异常.

原型模式

用原型实例指定创建对象的种类，并通过拷贝这些原型创建新的对象。

模式的使用场景

  1. 类初始化需要消化非常多的资源，这个资源包括数据、硬件资源等，通过原型拷贝避免这些消耗；
  2. 通过 new 产生一个对象需要非常繁琐的数据准备或访问权限，则可以使用原型模式；
  3. 一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式拷贝多个对象供调用者使用，即保护性拷贝。

在Android源码中，以熟悉的Intent来分析源码中的原型模式。

1
2
3
4
@Override
public Object clone() {
    return new Intent(this);
}

为深拷贝，重新生成了对象，而不是浅拷贝(直接复制引用)

优点

原型模式是在内存二进制流的拷贝，要比直接 new 一个对象性能好很多，特别是要在一个循环体内产生大量的对象时，原型模式可以更好地体现其优点。

缺点

这既是它的优点也是缺点，直接在内存中拷贝，构造函数是不会执行的，在实际开发当中应该注意这个潜在的问题。优点就是减少了约束，缺点也是减少了约束，需要大家在实际应用时考虑。

代理模式(proxy)

代理模式给某一个对象提供一个代理对象，并由代理对象控制对原对象的引用。

直观来说，Binder是Android中的一个类，它继承了IBinder接口。从IPC角度来说，Binder是Android中的一种跨进程通信方式，Binder还可以理解为一种虚拟的物理设备，它的设备驱动是/dev/binder，该通信方式在linux中没有；从Android Framework角度来说，Binder是ServiceManager连接各种Manager（ActivityManager、WindowManager，etc）和相应ManagerService的桥梁；从Android应用层来说，Binder是客户端和服务端进行通信的媒介，当你bindService的时候，服务端会返回一个包含了服务端业务调用的Binder对象，通过这个Binder对象，客户端就可以获取服务端提供的服务或者数据，这里的服务包括普通服务和基于AIDL的服务。

Binder一个很重要的作用是：将客户端的请求参数通过Parcel包装后传到远程服务端，远程服务端解析数据并执行对应的操作，同时客户端线程挂起，当服务端方法执行完毕后，再将返回结果写入到另外一个Parcel中并将其通过Binder传回到客户端，客户端接收到返回数据的Parcel后，Binder会解析数据包中的内容并将原始结果返回给客户端，至此，整个Binder的工作过程就完成了。由此可见，Binder更像一个数据通道，Parcel对象就在这个通道中跨进程传输，至于双方如何通信，这并不负责，只需要双方按照约定好的规范去打包和解包数据即可。

优点

  • 给对象增加了本地化的扩展性，增加了存取操作控制

缺点

  • 会产生多余的代理类

回调模式

装饰模式

策略模式