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

介绍

备忘录模式属于行为模式，该模式用于保存对象当前状态，并且在之后可以再次恢复到此状态，这有点像我们平时口头禅 ”有没有后悔药“ 。备忘录模式实现的方式需要保证被保存的对象状态不能被对象外部访问，目的是为了保护好被保存的这些对象状态的完整性以及内部实现不向外暴露。

定义

在不破坏封闭的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样，以后就可将该对象恢复到原先保存的状态。

使用场景

1. 需要保存一个对象在某一个时刻的状态或部分状态。
2. 如果用一个接口来让其他对象得到这些状态，将会暴露对象的实现细节并破坏对象的封装性，一个对象不希望外界直接访问其内部状态，通过中间对象可以间接访问其内部状态。

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

介绍

观察者模式是一个使用率非常高的模式，它最常用的地方是 GUI 系统、订阅-发布，因为这个模式的一个重要作用就是解耦，将被观察者和观察者解耦，使得她们之间的依赖性更小，甚至做到毫无依赖。以 GUI 系统来说，应用的 UI 具有易变性，尤其是前期随着业务的改变或者产品的需求更改，应用界面也会经常性变化，但是业务逻辑基本变化不大，此时， GUI 系统需要一套机制来应对这种情况，使得 UI 层与具体的业务逻辑解耦，观察者模式此时就派上用场了。

定义

定义对象间一种 1 对 N 的关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。

使用场景

1. 关联行为场景，需要注意的是，关联行为是可拆分的，而不是 “组合” 关系。
2. 事件多级触发场景。
3. 跨系统的消息交换场景，如消息队列、事件总线的消息机制。

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

介绍

责任链模式 (Iterator Pattern) ,属于行为型设计模式之一。什么是 “链” ？我们将多个节点首尾相连所构成的模型称为链 。就好比生活中一个个铁圆环一个连这一个环环相扣一样。

定义

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

使用场景

1. 多个对象可以处理同一个请求，但是具体由哪个对象处理则在运行时动态决定。
2. 在请求处理者不明确的情况下向多个对象中的一个提交一个请求。
3. 需要动态指定一组对象处理请求。

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

介绍

状态模式中的行为是由状态来决定的，不同的状态下有不同的行为。状态模式和策略模式的结构几乎完全一样，但它们的目的、本质却完全不一样。状态模式的行为是平行的、不可替换的，策略模式的行为是彼此独立、可相互替换的。用一句话来表述，状态模式把对象的行为包装在不同的状态对象里，每一个状态对象都有一个共同抽象状态的基类。状态模式的意图是让一个对象在其内部改变的时候，其行为也随之改变。

定义

当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。

使用场景

1. 一个对象的行为取决于它的状态，并且它必须在运行时根据状态改变它的行为。
2. 代码中包含大量与对象状态有关的条件语句，例如，一个操作中含有庞大的分支语句 (if-else / switch-case) , 且这些分支依赖于该对象的状态。

状态模式将每一个条件分支放入一个独立的类中，这使得你可以根据对象自身的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化，这样通过多态来去除过多的、重复的 if - else 等分支语句。

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

介绍

在软件开发中常常遇见这样的问题：实现某个功能可以有多种算法或者策略，我们根据实际情况选择不同的算法或者策略来完成该功能。例如，排序算法，可以有多种的实现方式。

那么，针对这种情况，应该怎么处理？是将这些算法写在一个类中，每一个方法对应一个具体的排序算法；还是将这些排序算法封装在同一个方法中，通过 if…else 或者 case 等条件判断语句来选择具体的算法。这 2 种实现方法我们都可以称之为硬编码。当然，这样是可以实现需求，但是，当很多算法在一个类时，这个类就会变得很臃肿，维护成本就会变高，并且在维护时容易发生错误，如果我们需要新增或者修改算法类的源码，这个就需要动封装好的类，那么这就违背了单一职责和开闭原则了。

如果将这些算法或者策略抽象出来，提供统一的接口，不同的算法或者策略有不同的实现类，这样在程序客户端就可以通过注入不同的实现对象来实现算法或者策略的动态替换，这种模式的可扩展性，可维护性也就更高，这就是我们今天要学习的策略模式。

定义

策略模式定义了一系列算法，并将每一个算法封装起来，而且使他们还可以相互替换，策略模式让算法独立于使用它的客户而独立变化。

使用场景

• 针对同一类型问题的多种处理方式，仅仅是具体行为有差别时。
• 需要安全的封装多种同一类型操作时。
• 出现同一抽象类有多个子类，而又需要使用 if-else 或者 switch-case 来选择具体子类时。

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

介绍

抽象工厂模式 (Abstract Factory Pattern) 也是创建型设计模式之一。上一篇讲解了 工厂方法模式 ,那么这个抽象工厂又是怎么一回事呢？大家联想一下像是生活中的工厂肯定都是具体的，也就是说每个工厂都会生产某一种具体的产品，那么抽象工厂意味着生产出来的产品是不确定的，那这岂不是很奇怪？抽象工厂模式起源于以前对不同操作系统的图形化解决方案，如不同操作系统中的按钮和文本框控件其实现不同，展示效果也不一样，对于每一个操作系统，其本身就构成一个产品类，而按钮与文本框控件也构成一个产品类，两种产品类两种变化，各自有自己的特性，如 Android 中的 Button 和 TextView 、IOS 中的 Button 、和 TextView 、 Window Phone 中的 Button 和 TextView 等。

定义

为创建一组相关或者相互依赖的对象提供一个借口，而不需要制定它们的具体类。

使用场景

一个对象如有相同的约束时可以使用抽象工厂模式。是不是听起来很抽象 ？ 举个例子，Android 、IOS 、Window Phone 下都有短信软件和拨号软件，两者都属于软件的范畴，但是，它们所在的操作系统平台不一样，即便是同一家公司出品的软件，其代码实现逻辑也是不同的，这时候就可以考虑使用抽象工厂方法模式来产生 Android 、IOS 、Window Phone 下短信软件和拨号软件。

类图

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

介绍

工厂模式 ( Factory Pattern ) ，是创建型设计模式之一。工厂方法模式是一种结构简单的模式，其在我们平时开发中应用很广泛，也许你并不知道，但是你已经使用了无数次改模式了，如 Android 中的 Activity 里各个生命周期方法，以 onCreate 方法为例，它就可以看做是一个工厂方法，我们在其中可以构造我们的 View,并通过 setContentView 返回给 Framework 处理。

定义

定义一个用于创建对象的接口，让子类决定实例化哪个类。

使用场景

在任何需要生成复杂对象的地方，都可以使用工厂方法模式。复杂对象适合使用工厂模式，用 new 就可以完成创建的对象无需使用 Factory 。

工厂模式代码示例

需求：根据用户不同的权限，匹配不同的业务模块。

定义一个抽象的业务模块类

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

介绍

原型模式是一个创建型的模式。原型二字表明了该模式应该有一个模板实例，用户从这个模板对象中复制出一个内部属性一致并且内存地址不同的对象，这个过程也就是我们俗称的 “克隆” 。被复制的实例就是我们所称的 “原型” ，这个原型是可定制的。原型模式多用于创建复杂的或者构造耗时的实例，因为这种情况下，复制一个已经存在的实例可使程序运行更高效。

定义

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

使用场景

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

UML 类图

• Client: 客户端用户。
• Prototype: 抽象类或者接口，声明具备 clone 能力。
• ConcreatePrototype: 具体的原型类

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

介绍

Builder 模式是一步一步创建一个复杂对象的创建型模式，它允许用户在不知道内部构建细节的情况下，可以更精细的控制对象的构造流程，该模式是为了将构建复杂对象的过程和它的部件解耦，使得构建过程和创建过程隔离开来。

定义

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

使用场景

1. 相同的方法，不同的执行顺序，产生不同的事件结果时。
2. 当初始化一个对象特别复杂，如参数多，且很多参数都具有默认值时。

简单代码示例

这里比如我们第一次初始化应用的时候，需要初始化一些事物，比如默认记住密码，自动登录，开机登录，崩溃重启等等。

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

介绍

单例模式是应用最为广泛的模式之一，也可能是很多入门或初级工程师唯一会使用的设计模式之吧，在应用这个模式时，单例对象的类必须保证只有一个实例存在。许多时候整个系统只需要拥有一个实例类。有利于我们的调用，避免一个相同的类重复创建实例，比如一个网络请求，图片请求/下载，数据库操作等，如果频繁创建同一个相同对象的话，很消耗资源，因此，没有理由让它们构造多个实例。全局都需要使用这个功能的时候，避免重复创建，就可以用单例，这就是单例使用场景。

定义

确保某个类只有一个实例，而且自行实例化并向整个系统提供这个实例。

使用场景

应用中重复使用某个类时，为了避免多次创建产生的资源消耗，那么这个时候就可以考虑使用单例设计模式。

单例 UML 类图

实现单例模式主要有如下几个关键点:

1. 构造函数不对外开放，一般为 private;
2. 通过一个静态方法或者枚举返回单例对象；
3. 确保单例类的对象有且只有一个，尤其是在多线程环境下；
4. 确保单例类对象在反序列化时不会被重新构建对象。