肥羊汤

空对象模式空对象模式（Null Object Pattern）：通过实现一个默认的无意义对象来避免null值出现。简单地说，就是为了避免在程序中出现null值判断而诞生的一种常用设计方法。这里我们通过一个简单的例子进行介绍：（1）我们首先定义一个动物接口，然后定义一只狗，实现狗叫的方法。//定义动物接口 public interface Animal { public void makeSound(); }//定义狗 class Dog implements Anima

黑板模式黑板模式（Blackboard Design Pattern）是观察者模式的一个扩展：允许消息的读写同时进行，广泛地交互消息。黑板模式允许多个消息读写者同时存在，消息的生产者和消费者完全分开，两者在空间和时间上可以解耦，并且互不干扰。黑板模式是消息的广播，主要解决消息的生产者和消费者之间的耦合问题，核心是消息存储（黑板），它存储所有消息，并可以随时被读取。当然，消息的写入者也可以变身为消息的阅读者，读写者在时间上解耦。对于这些消息，消费者只需要关注特定消息，不处理与自己不相关的消息，

雇工模式雇工模式也叫做仆人模式（Servant Design Pattern）：行为模式的一种，它为一组类提供通用的功能，而不需要类实现这些功能，它是命令模式的一种扩展或者说是命令模式的一种简化。类图中：IServiced接口定义了“一组类”所具有的功能。 Serviced1和Serviced2是两个具体的功能。 Servant是一个雇工，负责执行上面连个功能。public interface IServiced { //具有的特质或功能 public void

对象池模式对象池模式，也称对象池服务，通过循环使用对象，减少资源在初始化和释放时的昂贵损耗。简单地说，在需要时，从池中提取；不用时，放回池中，等待下一个请求。典型例子是连接池和线程池。public abstract class ObjectPool<T> { //容器，容纳对象 private Hashtable<T, ObjectStatus> pool = new Hashtable<T, ObjectStatus>();

规格模式规格模式（Specification Pattern）：它是组合模式的一种特殊应用。同时，每个规格书都是一个策略，它完成了一系列逻辑的封装。抽象规格书ISpecification：public interface ISpecification { //候选者是否满足要求 public boolean isSatisfiedBy(Object candidate); //and操作 public ISpecification and(ISpeci

有一个产品它有多个触发事件，它产生的时候触发一个创建事件，修改的时候触发修改事件，删除的时候触发删除事件，这就类似于我们的文本框，初始化（也就是创建）的时候要触发一个onLoad或onCreate事件，修改的时候触发onChange事件，双击(类似于删除)的时候又触发onDbClick事件。主要的设计模式：工厂方法模式：负责产生产品对象，方便产品的修改和扩展，并且实现产品和工厂的紧耦合，避免产品随意被创建而无触发事件的情况发生。 桥梁模式：在产品和事件两个对象的关系中使用桥梁模式，这样两者都可以自

通过下面这个实例对组合方法进行分析：某公司“一卡通”联机交易子系统，类似于银行的交易系统。IC卡上有以下两种金额：固定金额：员工不能提现的金额，只能用来特定消费，如食堂内吃饭、理发、健身等。 自由金额：可以提现的，也可用于消费。每个月初，总部都会为每个员工的IC卡中打入固定数量的金额，然后提倡大家在集团内的商店消费。系统内有两套扣款规则：策略一：该类型的扣款分别在固定金额和自由金额上各扣除消费金额的一半。 策略二：全部从自由金额上扣除。系统设计的时候要做到可拆卸（Pluggable）

这里我们使用命令模式、责任链模式、模板方法模式，制作一个把UNIX上的命令移植到Windows上的工具。UNIX下的命令，一条命令分为命令名、选项和操作数，例如命令"ls-l/usr"。其中，ls是命令名，l是选项，/usr是操作数，后两项都是可选项。UNIX命令一定遵守以下几个规则：命令名为小写字母。 命令名、选项、操作数之间以空格分隔，空格数量不受限制。 选项之间可以组合使用，也可以单独拆分使用。 选项以横杠（-）开头。其中，ls命令中有几个常用的命令：ls：简单列出一个目录..

5种包装模式包装模式包括：代理模式、装饰模式、适配器模式、桥梁模式、门面模式。相似的特征：都是通过委托的方式对一个对象或一系列对象施行包装。从实现的角度来看，它们都是代理的一种具体表现形式。使用场景的区别：代理模式：主要用在不希望展示一个对象内部细节的场景中。 装饰模式：倡导的是在不改变接口的前提下为对象增强功能，或者动态添加额外职责。 适配器模式：主要意图是接口转换，把一个对象的接口转换成系统希望的另外一个接口 桥梁模式：在抽象层产生耦合，它可以使两个有耦合关系的对象互不影响地扩展。

策略模式VS桥梁模式策略模式：是使用继承和多态建立一套可以自由切换算法的模式；只有一个抽象角色，可以没有实现，也可以有很多实现。 桥梁模式：是在不破坏封装的前提下解决抽象和实现都可以独立扩展的模式。有两个“桥墩”——抽象化角色和实现化角色，只要桥墩搭建好，桥就有了。策略模式和桥梁模式两者的通用类图非常相似，只相差了图中红框区域，其中左图为策略模式，右图为桥梁模式。（1）策略模式邮件一般有两种格式：文本邮件（Text Mail）和超文本邮件（HTML MaiL）。使用策略模式发送邮件，..

设计模式中的行为类模式行为类模式包括责任链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式。责任链模式： 命令模式：封装命令，对动作解耦，把一个动作的执行分为命令调用者、命令接收者。 解释器模式： 迭代器模式： 中介者模式： 备忘录模式： 观察者模式： 状态模式：封装的是不同的状态，以达到状态切换行为随之发生改变的目的。（状态内部进行下一状态切换） 策略模式：封装的是不同的算法，算法之间没有交互，以达到算法可以自

设计模式中的结构类模式结构类模式包括适配器模式、桥梁模式、组合模式、装饰模式、门面模式、享元模式和代理模式。适配器模式：修饰非血缘关系类，把一个非本家族的对象伪装成本家族的对象，因此它的本质还是非相同接口的对象。（适配器） 桥梁模式：即桥接模式，将抽象和实现解耦，使得两者可以独立地变化。（公司只需要挣钱，不需要知道挣钱时每一步的具体过程） 组合模式：用来描述部分与整体的关系，使得用户对单个对象和组合对象的使用具有一致性。（一般表示树型结构，树叶与树枝） 装饰模式：修饰血缘关系类，对类的功能进行

设计模式中的创建类模式创建类模式包括工厂方法模式、建造者模式、抽象工厂模式、单例模式和原型模式。单例模式：要保持在内存中只有一个对象。 原型模式：要求通过复制的方式产生一个新的对象。实现Cloneable接口，并覆盖和重写clone()方法。克隆。 工厂方法模式：注重的是整体对象的创建方法，用一个类封装特定产品的实例化，即把new进行封装。 建造者模式：注重的是部件构建的过程。先使用一个类对产品进行组装，然后再使用导演类对其封装。 抽象工厂模式：不需要关心构建过程，只关心什么产品由什么工厂生

桥梁模式桥梁模式（Bridge Pattern）也叫做桥接模式：将抽象和实现解耦，使得两者可以独立地变化。桥梁模式中的角色：Abstraction抽象化角色：定义出角色的行为，同时保存一个对实现化角色的引用，该角色一般是抽象类。 Implementor实现化角色：接口或者抽象类，定义角色必需的行为和属性。 RefinedAbstraction修正抽象化角色：引用了实现化角色对抽象化角色进行修正。 ConcreteImplementor具体实现化角色：实现了接口或抽象类定义的方法和属性。

享元模式享元模式（Flyweight Pattern）：使用共享对象可有效地支持大量的细粒度的对象。享元模式是池技术的重要实现方式。要求细粒度对象，那么不可避免地使得对象数量多且性质相近，那我们就将这些对象的信息分为两个部分：内部状态（intrinsic）与外部状态（extrinsic）。内部状态：对象可共享出来的信息，存储在享元对象内部并且不会随环境改变而改变。 外部状态：对象得以依赖的一个标记，是随环境改变而改变的、不可以共享的状态。享元模式角色名称：Flyweight抽象享

解释器模式解释器模式（Interpreter Pattern）：给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。解释器模式是一种按照规定语法进行解析的方案，在现在项目中使用较少。解释器模式中的角色：AbstractExpression抽象解释器：具体的解释任务由各个实现类完成，具体的解释器分别由TerminalExpression和NonterminalExpression完成。 TerminalExpression终结符表达式：实现与文法

状态模式状态模式：当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。状态模式的核心是封装，状态的变更引起了行为的变更，从外部看起来就好像这个对象对应的类发生了改变一样。状态模式的角色：State抽象状态角色：接口或抽象类，负责对象状态定义，并且封装环境角色以实现状态切换。 ConcreteState具体状态角色：每一个具体状态必须完成本状态下要做的事情，以及本状态如何过渡到其他状态。 Context环境角色：定义客户端需要的接口，并且负责具体状态的切换。抽象状态角

访问者模式访问者模式（Visitor Pattern）：封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。访问者模式就是根据朋友的信息，执行了自己的一个方法。访问者模式中的角色Visitor抽象访问者：抽象类或接口，声明访问者可以访问的元素，具体到程序中就是visit方法的参数定义哪些对象是可以被访问的。 ConcreteVisitor具体访问者：访问者访问到一个类后该做的事情。 Element抽象元素：接口或者抽象类，声明接受哪

备忘录模式备忘录模式（Memento Pattern）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。类图中的角色：Originator发起人角色：记录当前时刻的内部状态，负责定义哪些属于备份范围的状态，负责创建和恢复备忘录数据。 Memento备忘录角色：负责存储Originator发起人对象的内部状态，在需要的时候提供发起人需要的内部状态。 Caretaker备忘录管理员角色：对备忘录进行管理、保存和提供备忘录。

门面模式门面模式（Facade Pattern）也叫做外观模式，是一种比较常用的封装模式：要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。Facade门面角色：客户端可以调用这个角色的方法。此角色知晓子系统的所有功能和责任。一般情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去，也就说该角色没有实际的业务逻辑，只是一个委托类。subsystem子系统角色 可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，

观察者模式观察者模式（Observer Pattern）也叫做发布订阅模式（Publish/subscribe）：定义对象间一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。角色名称：Subject被观察者：定义被观察者必须实现的职责，它必须能够动态地增加、取消观察者。一般是抽象类或实现类，仅仅完成作为被观察者必须实现的职责：管理观察者并通知观察者。 Observer观察者：观察者接收到消息后，即进行update（更新方法）操作，对接收到的信息进行处

组合模式组合模式（Composite Pattern）也叫合成模式，有时又叫部分-整体模式（Part-Whole），主要是用来描述部分与整体的关系。将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。组合模式的几个角色：Component抽象构件角色：定义参加组合对象的共有方法和属性，可以定义一些默认的行为或属性。 Leaf叶子构件：叶子对象，其下再也没有其他的分支，也就是遍历的最小单位。 Composite树枝构件：树枝对象，它的作用是组合

迭代器模式迭代器模式（Iterator Pattern）：它提供一种方法访问一个容器对象中各个元素，而又不需暴露该对象的内部细节。迭代器是为容器服务的，迭代器模式就是为解决遍历这些容器中的元素而诞生的。都是目前已经是一个没落的模式，基本上没人会单独写一个迭代器，除非是产品性质的开发。迭代器模式提供了遍历容器的方便性，容器只要管理增减元素就可以了，需要遍历时交由迭代器进行。迭代器模式的角色：Iterator抽象迭代器：负责定义访问和遍历元素的接口，而且基本上是有固定的3个方法：firs

策略模式策略模式（Strategy Pattern）也叫政策模式（Policy Pattern）：定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。策略模式的三个角色：Context封装角色：也叫上下文角色，起承上启下封装作用，屏蔽高层模块对策略、算法的直接访问， 封装可能存在的变化。 Strategy抽象策略角色：策略、算法家族的抽象，通常为接口，定义每个策略或算法必...

装饰模式装饰模式：动态地给一个对象添加一些额外的职责。 就增加功能来说，装饰模式相比生成子类更为灵活。在类图中，有四个角色需要说明：Component抽象构件：Component是一个接口或者是抽象类，就是定义最核心的对象，也就是最原始的对象。注意：在装饰模式中，必然有一个最基本、最核心、最原始的接口或抽象类充当Component抽象构件。 ConcreteComponent具体...

适配器模式适配器模式（Adapter Pattern）：将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。适配器模式又叫做变压器模式，它也是包装模式（Wrapper）的一种，另一种是装饰模式。适配器模式就是把一个接口或类转换成其他的接口或类。 如上图，我们要将两个已经成型的模块A和B联系在一起，可以通过引入一个模块C分别适配A和B，然后将ABC拼接到一起，C就是适配器。当然，这也就是适配器模式...

责任链模式责任链模式：使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。责任链模式的核心：作为请求者可以不用知道到底是需要谁来处理的（请求者不需要知道处理者是谁）。责任链模式的重点是在“链”上，“链”是由多个处理者ConcreteHandler组成的，由一条链去处理相似的请求在链中决定谁来处理这...

命令模式命令模式：将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。三个角色：Receive接收者角色：该角色就是干活的角色，命令传递到这里是应该被执行的。 Command命令角色：需要执行的所有命令都在这里声明。 Invoker调用者角色：接收到命令，并执行命令。通用Receiver类：publi...

中介者模式中介者模式：用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。组成部分：Mediator抽象中介者：定义统一的接口，用于各同事角色之间的通信。 ConcreteMediator具体中介者：通过协调各同事角色实现协作行为，因此它必须依赖于各个同事角色。 Colleague同事：每一个同事角色都知...

原型模式原型模式（Prototype Pattern）：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。原型模式的核心是一个clone()方法，通过该方法进行对象的拷贝，Java提供了一个Cloneable接口来标示这个对象是可拷贝的。JDK中Cloneable接口只是一个标记作用，不需要实现任何方法，在JVM中具有这个标记的对象才有可能被拷贝。此时，我们可以通过覆盖和...

代理模式代理模式（Proxy Pattern）：为其他对象提供一种代理以控制对这个对象的访问。Subject抽象主题角色：抽象主题类可以是抽象类也可以是接口，无特殊要求。 RealSubject具体主题角色：也叫被委托角色、被代理角色。是业务逻辑的具体执行者。 Proxy代理主题角色：也叫委托类、代理类。它负责对真实角色的应用，把所有抽象主题类定义的方法限制委托给真实主题角色实现，...

建造者模式建造者模式（Builder Pattern）也叫生成器模式：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。如上面类图，在建造者模式中，共有4个角色：Product产品类：通常是实现了模板方法模式，也就是有模板方法和基本方法。 Builder抽象建造者：规范产品的组建，一般是由子类实现。 ConcreteBuilder具体建造者：实现抽象类定...

模板方法模式模板方法模式（Template Method Pattern）：定义一个操作中的算法的框架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。模板方法模式仅仅使用了Java继承机制。类图中包含元素如下：（1）AbstractClass叫做抽象模板，其中的方法主要分为两类：基本方法：也叫基本操作，是由子类实现的方法，并且在模板方...

抽象工厂模式抽象工厂模式（Abstract Factory Pattern）：为创建一组相关或相互依赖的对象提供一个接口，而且无须指定它们的具体类。抽象工厂模式的优点：封装性。高层模块只关心接口。 产品族内的约束为非公开状态。生产过程对调用工厂类的高层模块来说是透明的，它不需要知道这个约束，具体的产品族内的约束是在工厂内实现的。抽象工厂模式的缺点：产品族扩展非常困难。抽象...

工厂模式工厂模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。抽象产品类Product负责定义产品的共性，实现对事物最抽象的定义； Creator为抽象创建类，也就是抽象工厂，具体如何创建产品类是由具体的实现工厂ConcreteCreator完成的。抽象产品类：Productpublic abstract class Produ...

单例模式单例模式：确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。单例模式通用类图（饿汉式单例），可以看出：Singleton类称为单例类； 将构造函数变为private，确保在一个应用中只产生一个实例； 通过new，在类内自行实例化的； 通过get方法返回对象。public class Singleton { //通过new，在类内自行实例化的...

单一职责原则单一职责原则（Single Responsibility Principle，SRP）：要求一个接口或类有且仅有一个原因引起变化，也就是一个接口或类只有一个职责，它就负责一件事情。好处：类的复杂性降低，实现什么职责都有清晰明确的定义； 可读性提高。 可维护性提高。 变更引起的风险降低。如果一个接口修改只对相应的实现类有影响，这对系统的扩展性、维护性都有非常大的帮助。...