宋先森的博客

装饰模式，动态的给一个对象添加一些额外的职责。装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案。一、装饰模式装饰模式通过组合的方式扩展对象的特性，这种方式允许我们在任何时候对对象的功能进行扩展，甚至是运行时扩展。与继承相比，组合关系的优势就在于不会破坏类的封装性，且具有较好的松耦合性，可以使系统更加容易维护。但是它的缺点就在于要创建比继承更多的对象。其UML图

解释器模式（Interpreter Pattern）：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用来解释语言中的句子。一、解释器模式解释器模式用来做各种各样的解释器，如正则表达式的解释器等等，其UML图如下所示： 解释器模式由以下部分组成：抽象表达式（Expression）：声明一个所有的具体表达式角色都要实现的抽象接口。该接口中的interpret（）方法，称作解释

中介者模式（Mediator）：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变他们之间的交互。一、中介者模式1.1 为什么使用中介者模式？在软件开发中，对象和对象之间存在着大量的关联关系，导致系统的结构变得复杂，可扩展性降低。举例来看，下图所示的各个国家之间的关系图，倘若再加入一个新的国家，需要和其相关联的国家进行连接，变得很复杂。

访问者模式（Visitor）：表示一个作用于某对象结构中的各元素的操作。它使你可以不在改变个元素类的前提下定义作用于这些元素的新操作。 一、访问者模式在软件开发中，有时候我们对同一个对象可能会有不同的处理，对相同对象元素也存在不同的操作方式。比如，我们的银行账户，每个月都有收入和支出，不同的人（your girlFriend）去操作账户，有不同的操作方式。这就使用到了访问者模式。访问者模式的目的是

状态模式（State）：当一个对象内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。一、状态模式在软件开发中，有很多情况是一个对象的行为取决于一个或多个动态变化的属性，这样的属性叫做状态，这样的对象叫做有状态的对象，这样的对象从实现定义好的一系列值中取出。当一个这样的对象与外部事件产生互动时，其内部状态就会发生改变，从而使得系统的行为发生变化。状态模式主要解决的是当控制一个对象状态转换的

迭代器模式（Iterator）：提供一种方法顺序访问一个聚合对象中各个元素，而不是暴露该对象的内部表示。在软件开发过程中，因为业务的需要，我们会创建不同的集合或者数组，每次遍历取值都要重复相同的代码。在设计模式中能够将遍历进行封装，而不会暴露内部的表示，还能够提供多种不同的遍历方式。这就是迭代器模式，其UML图如下：迭代器模式由以下组成部分：抽象迭代器（Iterator）:所有迭代器都需要实现的接

命令模式（Command）将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。一、命令模式在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。需要用到命令模式，其UML图如下所示：命令模式由以下部分组成：命令(Command

备忘录模式（Memento）:在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可以将该对象恢复到原先保存的状态。作为一名码农，当你辛辛苦苦忙了一天，写了若干行代码，一不小心点了退出IDE，所有的劳动都付之东流，但此时的你，要是有随时往svn或者git上提交代码的习惯，恭喜你，你的代码可以回来了。这就是备忘录模式的必要性。所谓备忘录模式就是在不破坏封装的前提下，

观察者模式又叫发布-订阅模式（Publish/Subsctibe），定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自己更新自己。一、观察者模式在软件开发中经常会遇到这样的需求：一个对象的状态发生改变，与它相关的其他对象也要做出相应的变化。例如，当我们在IDEA中运行某个java项目时，IDEA的某些窗口就会关闭，某

职责链模式（Chain of Responsibility）:很多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。一、职责链模式职责链的UML图： 职责链由以下部分组成：抽象处理者角色(Handler):定义一个处理请求的接口，和一个后继连接(可选)具体处理者角色(ConcreteHandler):处理它所

享元模式（Flyweight Pattern）：运用共享技术有效地支持大量细粒度的对象。用于减少创建对象的数量，以减少内存占用和提高性能。一、享元模式在软件开发过程中，如果有使用大量相同的对象，只要共享一个就可以，这就是享元模式，减少了不必要的内存消耗，其UML图如下所示： 享元模式由以下部分组成:抽象享元类（Flyweight）: 所有具体享元类的超类或者接口，通过这个接口，Flyweight可

模板方法模式：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构，即可重定义该算法的某些特定步骤。一、模板方法模式在软件开发中，某个方法实现需要多步操作，我们就将每一步的操作称之为基本方法，所有的步骤综合起来完成，称之为模板方法。在模板方法中，有一些步骤是固定不变的，有一些步骤是要变化的。我们就可以将其中固定的部分交由父类实现，不固定的部分交由子类实现。

组合模式（Composite）：将对象组合成树形结构，以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。一、组合模式组合模式又叫做部分-整体模式，常用来解决树型结构的问题。在下图所示的公司结构树中有工程部、人事部和下级子公司，这是一个典型的树形结构，可以利用组合模式描述公司的结构。 组合模式的UML图如下：组合模式由以下部分组成：抽象构件角色(Componen

策略模式（Strategy）：定义了算法家族，将不同的算法分别封装起来，让他们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。一、策略模式策略模式的背景:在软件开发中常常遇到这种情况，实现某一个功能有多种算法或者策略，我们可以根据环境或者条件的不同选择不同的算法或者策略来完成该功能。如查找、排序等，一种常用的方法是硬编码(Hard Coding)。在一个类中，如需要提供多种查找算法

桥接模式（Bridge）：将抽象部分与实现部分分离，使它们都可以独立的变化。一、桥接模式我们知道java的四个特性：封装、继承、多态、抽象。以继承为例，在一家衣服店，有很多类型的衣服，有T-shirt，短裤，夹克…..，而不同类型的衣服，又有不同的颜色，比如：红色、绿色、黑色……。按照继承的思想，我们可以这样理解： 但假如，该商店要加入另一种新的类型的衣服时，还得加三种不同的颜色。我们将每一种衣服

代理模式（Proxy），为其他对象提供一种代理以控制对这个对象的访问。一、代理模式生活中，我们去租房子的时候，会去找中介，因为他们比较专业，熟悉房源信息；打官司的时候，聘请律师，因为他们更有经验…,诸如此类的事件，都有代理模式的含义，其UML图如下：代理模式一般会有三个角色：抽象角色（Subject）：指代理角色和真实角色对外提供的公共方法，一般为一个接口。真实角色（RealSubject）：需要

适配器模式（Adapter）：将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类一起工作。在软件开发中，适配器模式用来解决的这样的问题：系统的数据和行为都正确，但接口不符合我们的需求，此时，我们可能需要使用适配器模式，目的是使控制范围之外的一个原有对象与某个接口匹配。在GOF的设计模式中，适配器模式分为类适配器模式、对象适配器模式、接口适配器

建造者模式（Builder）又叫做生成器模式，将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。一、建造者模式在软件开发中，我们可能要创建一些复杂的对象，这些对象的内部组成构件间的建造顺序是稳定的，但是对象的内部组成构件面临着复杂的变化。这时候，建造者模式就是一个较佳的选择。其UML图如下：建造者模式包含以下四个角色：抽象建造者（Builder）：声明了一个Product对

外观模式：为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一系统更加容易使用。一、外观模式外观模式（Facade）属于结构型设计模式，它隐藏了系统的复杂性，并向客户端提供了一个可以访问系统的接口。其UML图如下： 外观模式由下面模式组成：外观角色（Facade）：是模式的核心，被客户client角色调用，知道各个子系统的功能。同时根据客户角色已有的需求，预订功能组

原型模式（Prototype）：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。一、原型模式原型模式其实就是从一个对象中再创建另一个对象，而且不需要知道详细的创建细节，其UML图如下： 原型模式由以下部分组成：抽象原型(Prototype)角色：这是一个抽象角色，通常由一个Java接口或Java抽象类实现。此角色给出所有的具体原型类所需的接口clone(）。具体原型（Concre

抽象工厂模式（Abstract Factory）：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。一、抽象工厂模式抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。其UML图如下：抽象工厂模式由以下部分组成：抽象工厂（AbstractF

简单工厂模式的意义在于：定义一个用于创建对象的接口。 简单工厂模式不属于23种GOF中的设计模式。一般分为：普通简单工厂、多方法简单工厂、静态方法简单工厂。一、简单工厂模式简单工厂模式UML图如下： 简单工厂模式由以下部分组成： 工厂类（Factory）：简单工厂模式的核心，用来创建对象。抽象产品类（Product）：它一般是具体产品要继承的父类或者要实现的接口。

单例模式（Singleton）：保证一个类仅有一个实例，并提供一个访问它的全局访问点。一、单例模式单例模式是设计模式中常见的设计模式，单例模式有以下特点：单例类只能有一个实例。单例类必须自己创建自己的唯一实例。单例类必须给所有的对象提供这一个实例。单例模式的UML图： Singleton类，将这个类的构造器私有化，使得在外部对象中，无法通过构造器来创建Singleton的实例，只能由该类自

工厂方法模式（Factory Method）：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使得一个类的实例化延迟到其子类。一、工厂方法模式在设计模式系列之简单工厂模式一文中，我们详细介绍了简单工厂模式。当游客要求添加一种新的动物去表演时，我们既要增加一种动物，实现show()方法，而且工厂类中也要增加一种新的判断，去决定要实例化哪一个动物，这就违背了开闭原则，不是一种理想的设计模

本博目录： 一 什么是设计模式二 设计模式的原则三 设计模式的学习一、 什么是设计模式 设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。 使用设计模式的目的：为了代码可重用性、让代码更容易被他人理解、保证代码可靠性。 设计模式使代码编写真正工程化。 设计模式是软件工程的基石脉络，如同大厦的结构一样。这段话引自百