UML类图描述设计模式
面向对象的设计原则：
1、单一职责原则（Single Responsibility Principle），一个类只负责一个功能领域中的相应职责；
2、开闭原则（Open-Closed Principle），软件实体应该对扩展开放，对修改关闭；
3、里氏代换原则（Liskov Substitution Principle），所有引用基类对象的地方能够透明地使用其子类的对象；
4、依赖倒转原则（Dependence Inversion Principle），抽象不应该依赖于细节，细节应该依赖于抽象；
5、接口隔离原则（Interface Segregation Principle），使用多个专门的接口，而不使用单一的总接口；
6、合成复用原则（Composite Reuse Principle），尽量使用对象组合，而不是继承来达到复用的目的；
7、迪米特法则（Law of Demeter），一个软件实体应当尽可能少地与其他实体发生相互作用。
创建的艺术-创建型模式
1.确保对象的唯一性 - 单例模式
单例模式（Singleton Pattern），确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。单例模式是一种对象创建型模式。
2.集中式工厂的实现 - 简单工厂模式
简单工厂模式（Simple Factory Pattern），定义一个工厂类，它可以根据参数的不同返回不同的实例，被创建的实例通常都具有相同的父类。因为在简单工厂模式中用于创建实例的方法是静态（static）方法，因此简单工厂模式又被称为静态工厂方法模式（Static Factory Pattern），它属于类创建型模式。
3.多态工厂的实现 - 工厂方法模式
工厂方法模式（Factory Method Pattern），定义一个用于创建对象的接口，让子类决定将哪一个类实例化。工厂方法模式让一个类的实例化延迟到其子类。工厂方法模式又简称为工厂模式（Factory Pattern），又可称作虚拟构造器模式（Virtual Contructor Pattern）或多态工厂模式（Polymorphic Factory Pattern）。工厂方法模式是一种类创建模式。
4.产品簇的创建 - 抽象工厂模式
抽象工厂模式（Abstract Factory Pattern），提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。抽象工厂模式又称Kit模式，它是一种对象创建型模式。
5.对象的克隆 - 原型模式
原型模式（Prototype Pattern），使用原型实例指定创建对象的种类，并且通过克隆这些原型创建新的对象。原型模式是一种对象创建型模式。
6.复杂对象的组装和创建 - 建造者模式
建造者模式（Builder Pattern），将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。建造者模式是一种对象创建型模式。
组合的艺术-结构型模式
1.不兼容结构的协调 - 适配器模式
适配器模式（Adapter Pattern），将一个接口转换成客户希望的另一个接口，使接口不兼容的那些类可以一起工作，其别名为包装器（Wrapper）。适配器模式既可以作为类结构型模式，也可以作为对象结构型模式。
2.处理多维度变化 - 桥接模式
桥接模式（Bridge Pattern），将抽象部分与其实现部分分离，使它们都可以独立地变化。它是一种对象结构型模式，又称柄体（Handle and Body）模式或接口（Interface）模式。
3.树形结构的处理 - 组合模式
组合模式（Composite Pattern），组合多个对象形成树形结构以表示具有“部分-整体”关系的层次结构。组合模式对单个对象（即叶子对象）和组合对象（即容器对象）的使用具有一致性，又可以称为“部分-整体”（Part-Whole）模式，它是一种对象结构型模式。
4.扩展系统功能 - 装饰模式
装饰模式（Decorator Pattern），动态地给一个对象增加一些额外的职责，就增加对象功能来说，装饰模式比生成子类实现更为灵活。装饰模式是一种对象结构型模式。
5.提供统一入口 - 外观模式
外观模式（Facade Pattern），外部与一个子系统的通信通过一个统一的外观角色进行，为子系统中的一组接口提供一致的入口。外观模式定义了一个高层接口，这个接口使得子系统更加容易使用。外观模式又称为门面模式，它是一种对象结构型模式。
6.实现对象的复用 - 享元模式
享元模式（Flyweight Pattern），运用共享技术有效地支持大量细粒度对象的复用。系统只使用少量的对象，而这些对象都很相似，状态变化很小，可以实现对象的多次复用。由于享元模式要求能够共享的对象必须是细粒度对象，因此它又称为轻量级模式，是一种对象结构型模式。
7.对象的间接访问 - 代理模式
代理模式（Proxy Pattern），给某一个对象提供一个代理，并由代理对象控制对原对象的引用。代理模式是一种对象结构型模式。
交互的艺术-行为型模式
1. 定义算法的框架 - 模板方法模式
模板方法模式（Template Method Pattern），定义一个操作中算法的框架，而将一些步骤延迟到子类中。模板方法模式使得可以不改变一个算法的结构即可重定义该算法的某些特定步骤。模板方法模式是一种类行为型模式。
2. 操作复杂对象的结构 - 访问者模式
访问者模式（Visitor Pattern），提供一个作用于某对象结构中各元素的操作表示，它使得可以在不改变各元素的类的前提下定义作用于这些元素的新操作。访问者模式是一种对象行为型模式。
3.算法的封装与切换 - 策略模式
策略模式（Strategy Pattern），定义一系列算法类，将每一个算法类封装起来，并让它们可以相互替换。策略模式让算法独立于使用它的客户而变化，也称为政策模式（Policy Pattern）。策略模式是一种对象行为型模式。
4.对象状态及其转换 - 状态模式
状态模式（State Pattern），允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。其别名为状态对象（Objects for states），状态模式是一种对象行为型模式。
5.请求的链式处理 - 责任链模式
责任链模式（Chain Responsibility Pattern），避免将请求发送者与接收者耦合在一起，让多个对象都有机会接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。责任链模式是一种对象行为型模式。
6.请求发送者与接收者解耦 - 命令模式
命令模式（Command Pattern），将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是一种对象行为型模式，其别名为动作（Action）模式或事务（Transcation）模式。
7.自定义语言的实现 - 解释器模式
解释器模式（Interpreter Pattern），定义一个语言的文法，并且建立一个解释器来解释该语言中的句子，这里的“语言”是指使用规定格式和语法的代码，解释器模式是一种类行为型模式。
8.遍历聚合对象中的元素 - 迭代器模式
迭代器模式（Iterator Pattern），提供一种方法来访问聚合对象，而不用暴露这个对象的内部表示，其别名为游标（Cursor）。迭代器模式是一种对象行为型模式。
9.协调多个对象之间的交互 - 中介者模式
中介者模式（Mediator Pattern），用一个中介对象（中介者）来封装一系列的对象交互。中介者使各个对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。中介者模式又称为调停者模式，它是一种对象行为型模式。
10.撤销功能的实现 - 备忘录模式
备忘录模式（Memento Pattern），在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。它是一种对象行为型模式，其别名为Token。
11.对象间的联动 - 观察者模式
观察者模式（Observer Pattern）：定义对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知并被自动更新。观察者模式的别名包括发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式、源-监听器（Source/Listener）模式或从属者（Dependents）模式。观察者模式是一种对象行为型模式。
补充：UML中类图解释
类图中类之间的从强到弱关系
泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖
泛化（Generalization）：表示的是类之间的继承关系，注意是子类指向父类。UML中用带空心三角箭头的实线表示泛化关系，箭头指向的是父类。
实现(Realization)：表示接口与实现类的关系，实现关系用一条带空心箭头的虚线表示。UML中用带空心三角箭头的虚线表示实现关系，箭头指向的是接口。
组合(Composition)：是聚合的一种特殊形式，表示的是类之间更强的组合关系。他体现的是一种contains-a的关系，这种关系比聚合更强，也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束。UML中用实心菱形头的实线来表示组合，菱形头指向整体。
举例：公司由多个部门组成；公司不存在了，部门也将不存在了。
聚合（Aggregation）：用于表示实体对象之间的关系，表示整体由部分构成的语义。与组合关系不同的是，整体和部分不是强依赖的，即使整体不存在了，部分仍然存在；聚合关系是关联关系的一种，耦合度强于关联，他们的代码表现是相同的，仅仅是在语义上有所区别：关联关系的对象间是相互独立的，而聚合关系的对象之间存在着包容关系，他们之间是”整体 - 个体”的相互关系。UML中用空心菱形头的实线表示聚合关系，菱形头指向整体。
举例：一个部门由多个员工组成，部门撤销了，人员不会消失，他们依然存在。
关联(Association)：表示的是类与类之间存在某种特定的对应关系。它是一种静态关系，通常与运行状态无关，一般由常识等因素决定的；关联关系默认不强调方向，表示对象间相互知道。UML中用双向箭头（此时箭头可以忽略）、单向带箭头的实线表示关联关系，箭头两端为相互关联的两个类。
举例：乘车人和车票之间、我和同事之间就是一种关联关系。
依赖(Dependency)：表示的是类之间的调用关系。与关联关系不同的是，它是一种临时性的关系，通常在运行期间产生，并且随着运行时的变化；依赖关系也可能发生变化；显然，依赖也有方向，双向依赖是一种非常糟糕的结构，我们总是应该保持单向依赖，杜绝双向依赖的产生。UML中用带箭头的虚线表示依赖关系，而箭头所指的则是被依赖的类。
举例：我要用打印机打印一份文件，那我和打印机之间就是依赖关系。
