通过理论,代码示例,Android源码来学习外观模式

介绍

外观模式 (Facade) 在开发过程中的运用评率非常高，尤其是在现阶段，各种第三方 SDK “充斥” 在我们周边，而这些 SDK 大多会使用外观模式。通过一个外观类使得整个系统的接口只有一个统一的高层接口，这样能够降低用户的使用成本，也对用户屏蔽了很多实现细节。当然，在我们的开发过程中，外观模式也是我们封装 API 的常用手段，例如，网路模块、图片模块，可能你已经在开发中运用无数次外观模式，只是没有在理论中认识它，下面我们就来学习它。

定义

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

使用场景

1. 为一个复杂子系统提供一个简单接口。子系统往往因为不断演化而变得越来越复杂，甚至可能被替换。大多数模式使用时都会产生更多、更小的类，这使子系统更具可重用性的同时也更容易对子系统进行定制、修改，这种易变性使得隐藏子系统的具体实现变得尤为重要。Facade 可以提供一个简单统一的接口，对外隐藏子系统的具体实现、隔离变化。
2. 当你需要构建一个层次结构的子系统时，使用 Facade 模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过 Facade 接口进行通信，从而简化了它们之间的依赖关系。

通过理论,代码示例,Android源码来学习享元模式

介绍

享元模式是对象池的一种实现，享元模式用来尽可能减少内存使用量，它适合用于可能存在大量重复对象的场景，来缓存可共享的对象，达到对象共享、避免创建过多对象的效果，这样一来就可以提升性能、避免内存移除等。

定义

使用共享对象可以有效地支持大量的细粒度的对象。

使用场景

• 系统中存在大量的相似对象。
• 细粒度的对象都具备较接近的外部状态，而且内部状态与环境无关，也就是说对象没有特定身份。
• 需要缓冲池的场景。

通过理论,代码示例,Android源码来学习装饰模式

介绍

装饰模式 (也称为 Decorator Pattern) 也称为包装模式，属于结构型模式之一，其使用一种对客户端透明的方式来动态的扩展对象的功能，同时它也是继承关系的一种替代方案之一。在现实生活中你也看见很多装饰模式的例子，或者可以大胆地说装饰模式无处不在，就拿人来说，人需要各式各样的衣着，不管你穿着怎么，但是，对于个人的本质来说是不变的，充其量只是在外面披上一层 “遮羞物” 而已，这就是装饰模式。

定义

动态的给一个对象田爱军一些额外的职责。就是增加功能来说，装饰模式生成子类更为灵活。

使用场景

需要透明且动态地扩展类的功能时。

通过理论,代码示例,Android源码来学习适配器模式

介绍

适配器模式在我们开发中使用率极高，从最早的 ListView、GridView 到现在的 RecyclerView 都需要使用 Adapter ，并且在开发中我们遇到的优化问题，出错概率较大的地方也基本都出在 Adapter,这是一个让人又爱又恨的角色。

说到底，适配器是将两个不兼容的类融合到一起，它有点像粘合剂，将不同的东西通过一种转换使得它们能够协作起来。例如，经常碰到要两个没有关系的类型之间进行交互，第一个解决方案是修改各自类的接口，但是如果没有源代码或者我们不愿意为了一个应用而修改各自的接口，此时怎么办？这种情况我们往往会使用一个 Adapter,在这两种接口之间创建一个 “混血儿” 接口，这个 Adapter 会将这两个接口进行兼容，在不修改原有代码的情况下满足需求。

定义

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

使用场景

1. 系统需要使用现有的类，而此类的接口不符合系统的需要，即接口不兼容。
2. 想要建立一个可以重复使用的类，用于一些彼此之间没有太大关联的类，包括一些可能在将来引进的类一起工作。
3. 需要统一的输出接口，而输入端的类型不可预知。

通过理论,代码示例,Android源码来学习组合模式

介绍

组合模式（Composite Pattern）也称为部分整体模式 (Part Whole Pattern) ，属于结构性设计模式，组合模式比较简单，它将一组相似的对象看做一个对象处理，并根据一个树状结构来组合对象，然后提供一个统一的方法去访问相应的对象，以此忽略掉对象与对象集合之间的差别。

定义

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

使用场景

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

通过理论,代码示例,Android源码来学习代理模式

介绍

代理模式 (Proxy Pattren) 也称为委托模式，是属于结构型设计模式，其重要性不言而喻，相信在看过本篇文章之后会发现不少设计模式中都有代理模式的影子。那么何为代理模式？其实代理在我们日常生活中并不少见，对于程序员来说最常接触的莫过于代理上网了，连上代理服务器地址，就可以轻松畅游全世界的网络；总而言之，也许你并不留意，但是代理是无处不在，现实生活如此，我们的 Code 世界里也是如此！既然这样，我们来探究下代理模式倒是有多普遍。下面首先看下代理模式的定义吧。

定义

为其它对象提供一种代理以控制对这个对象的访问。

使用场景

当无法或不想直接访问某个对象存在困难时可以通过一个代理对象来间接访问，为了保证客户端使用的透明性，委托对象与代理对象需要实现相同的接口。

通过理论,代码示例,Android源码来学习中介者模式

介绍

中介者模式 (Mediator Pattern) 也称为调解者模式或调停者模式，Mediator 本身就有调停者和调解者的意思。在日常生活中调停者或调解者这个角色我们见得比较多的是 ”和事佬“，也就是说调解两个有争端的人的角色。

定义

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

使用场景

当对象之间的交互操作很多且每个对象的行为操作都依赖彼此时，为防止在修改一个对象的行为时，同时涉及修改很多其他对象的行为，可采用中介者模式来解决紧耦合问题。该模式将对象之间的多对多变成一对多关系，中介者对象将系统从网状结构变成以调解者为中心的星形结构，达到降低系统的复杂性，提高可扩展性的作用。

通过理论,代码示例,Android源码来学习访问者模式

介绍

访问者模式是一种将数据操作与数据结构分离的设计模式，它是 《设计模式》中较为复杂的一个，但它的使用频率并不高，正如《设计模式》的作者 GOF 对访问者模式的描述：大多数情况下，你并不需要使用访问者模式，但是当你一旦需要使用它时，那你就是真正的需要它了。

访问者模式的基本思想是，软件系统中拥有一个由许多对象构成的、比较稳定的对象结构，这些对象的类都拥有一个 accept 方法用来接受访问者对象的访问。访问者是一个接口，它拥有一个 visit 方法，这个方法对访问到的对象结构中不同类型的元素做出不同的处理。在对象结构的一次访问过程中，我们遍历整个对象结构，对每一个元素都实施 accept 方法，在每一个元素的 accept 方法中会调动访问者的 visit 方法，从而使访问者得到以处理对象结构的每一个元素，我们可以针对对象结构设计不同的访问者类来完成不同的操作，达到区别对待的效果。

定义

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

使用场景

1. 对象结构比较稳定，但经常需要在此对象进行很多不同的并且不相关的操作。
2. 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免这些操作 “污染” 这些对象的类，也不希望在增加新操作时修改这些类。

通过理论,代码示例,Android源码来学习模板方法模式

介绍

在面向对象开发过程中，通常会遇到这样的一个问题，我们知道一个算法所需的关键步骤，并确定了这些步骤的执行顺序，但是，某些步骤的具体实现是未知的，或者说某些步骤的实现是会随着环境的变化而改变的，例如，执行程序的流程大致如下:

1. 检查代码的正确性；
2. 链接相关的类库；
3. 编译相关代码；
4. 执行程序；

对于不同的程序设计语言，上述 4 个步骤都是不一样的，但是，它们的执行流程是固定的，这类问题的解决方案就是这们这篇的主要内容 - 模板方法模式。

定义

定义一个操作中算法的框架，将一些步骤交于子类具体实现，使得子类可以改变一个算法的结构即可重定义该算法的某些特定步骤。

使用场景

1. 多个子类有公有的方法，并且逻辑基本相同时。
2. 重要、复杂的算法，可以把核心算法设计为模板方法，周边的相关细节功能则由各个子类实现。
3. 重构时，模板方法模式是一个经常使用的模式，把相同的代码抽取到父类中，然后通过钩子函数约束其行为。

通过理论,代码示例,Android源码来学习迭代器模式

介绍

迭代器模式 (Iterator Pattern) 又称为游标 (Cursor) 模式 ，是行为型设计模式之一。迭代器模式算是一个比较古老的设计模式，其源于对容器的访问，比如 Java 的 List 、Map 、数组等，我们知道对容器对象的访问必然会设计遍历算法，我们可以将遍历的方法封装在容器中，或者不提供遍历方法。如果我们将遍历的方法封装到容器中，那么对于容器类来说就承担了过多的功能，容器类不仅仅要维护自身内部的数据元素而且还要对外提供遍历的接口方法，因为遍历状态的存储问题还不能对同一个容器同时进行多个遍历操作，如果我们不提供遍历方法而让使用者自己去实现，又会让容器内部细节暴露无遗，正因于此，迭代模式应运而生，在客户访问类与容器体之间插入了一个第三者 - 迭代器，很好地解决了上面所述的弊端。

定义

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

使用场景

遍历一个容器对象时。