开闭原则，依赖倒置原则，单一职责原则，接口隔离原则，最少知道原则，里氏替换原则，合成复用原则

装饰器模式和代理模式在使用上很相似，都是在不修改原始类代码的情况下，动态地给真实对象的方法做增强。装饰器模式是通过创建一个包装对象来包裹原有对象，并在包装对象中添加额外的职责。装饰器可以有多个，在实际使用中，可以根据不同的场景，使用多个不同的装饰器包装来实现需求。

通常一个完整的业务流程中，会经历多个阶段，每个阶段即一个业务状态，不同状态下对应这不同的业务处理逻辑。无脑堆砌 if else 做判断然后选择对应的业务处理其实也能够完成该需求，只不过这样写代码不够优雅。使用状态模式来处理这种业务场景，能让程序可读性更好，易于维护和扩展。状态模式和策略模式从 UML 上看其实是一样的，很容易混淆。两者的区别就是策略模式下的策略是由客户端自主选择的，且每个策略之间并没有任何关系；

使用备忘录模式，主要目的就是创建对象副本，保存对象内部状态的的快照，以便在需要时恢复对象至某一个历史状态。仅仅从创建副本来看，备忘录模式和原型模式其实没啥区别，不过备忘录模式是行为型设计模式，重点在于恢复对象到某一历史状态。备忘录模式下，总共有三个角色，原始对象 Originator，对象快照 Memento，以及管理它们的 CareTaker。

使用观察者模式，便能够在对象之间建立起一种一对多（主题与观察者）的依赖关系，当主题对象改变状态时，所有依赖它的观察者对象都会得到通知并且自动更新。通过主题对象来使客户端与观察者对象之间的通信更加松散耦合、灵活可扩展。一般用来解耦不同的业务逻辑，比如将实时更新、动态同步等功能与其它业务逻辑解耦。可分为两种模式：推模型和拉模型。

在类设计中，一个类的功能实现可能还依赖其它类，甚至存在两个类之间互相依赖，你中有我，我中有你。表现在代码中就是类往往直接持有另外一个类的引用，类与类之间严重耦合，一个类的修改可能会影响到其他的类，不好维护。中介者模式即是将对象之间的交互逻辑抽取出来，通过中介者来管理，使得对象之间无需直接引用，降低对象之间的耦合。集中管理交互逻辑相对更加容易维护。相较于观察者模式，中介者中的对象能够实现相互通信，而观察者只能单方面接受被观察者的通知。

命令模式解耦了命令请求者（Invoker）和命令执行者（receiver），使得 Invoker 不再直接引用 receiver，而是依赖于抽象的命令接口。具体的命令类则直接引用 receiver，通过调用 receiver 的方法来执行命令。解耦之后，具体命令的增删改不再影响 Invoker，同时，抽象出来的命令请求还能队列化，从而实现撤销和重试功能，或做排列组合合成复杂的命令。

使用设计模式的主要目的之一就是解耦，让程序易于维护和更好扩展。责任链则是将处理逻辑进行解耦，将独立的处理逻辑抽取到不同的处理者中，每个处理者都能够单独修改而不影响其他处理者。使用时，依次调用链上的处理者处理逻辑。

一个类由成员变量和方法组成，成员变量即是类的数据结构，方法则是类的行为。如果一个类的数据结构稳定，但是行为多变，想要增加类的行为，就必须为类添加新的方法，违背了开闭原则。使用访问者模式，则可以在不修改原有类的前提下定义新的操作，为类增加新的行为。它能将类的数据结构和行为解耦，将多变的行为提取到访问者中，不同的访问者实现不同的行为。当类的行为变化时，只需要替换对应的访问者就能够修改类的行为了。故访问者特别适用于数据结构相对稳定，而操作易于变化的场景。

在实际开发过程中，常用各种集合来存储业务数据并处理，比如使用 List，Map，Set 等等集合来存储业务数据。存储在集合中的数据，往往需要遍历集合元素再进行相应的业务处理。不同的集合类型有不同的数据结构，遍历的方式也各不相同。而迭代器模式，就是用来简化这项工作，让开发者不必关心底层的数据结构是如何组织的，只需关注如何取用数据。它解决了数据的获取与表示之间的耦合问题，提升了集合管理的灵活性与可维护性。

在设计类时，一般优先考虑使用组合来替代继承，能够让程序更加的灵活，但这并不意味着要完全抛弃掉继承。继承在面向对象编程中用来减少代码冗余和提高复用性，是面向对象编程的一大特性。只不过在使用继承时必须满足一些条件，才能让我们更好地利用继承，设计出更易维护和扩展的程序。模板方法模式是继承使用的优雅示例，一般会设计一个抽象类，在类中定义了一个操作的算法结构，其中一些步骤被设计为抽象方法，需要子类去实现，这些方法被称为模板方法。模板方法允许子类在不改变算法结构的情况下，重新定义算法的某些特定步骤。

桥接模式，其实就是组合替代继承思想的实现。在不用桥接模式时，设计一个类如果想复用现有类的功能，并且再扩展新的方法，最容易想到的就是使用继承，子类继承父类，子类复用父类的方法，再自己实现扩展方法。使用桥接模式，将抽象部分与它的实现部分分离，以便它们可以独立地变化。桥接模式可以将继承关系转换为关联关系，从而提高了程序的灵活性和可扩展性。

适配器模式，用于将一个类的接口转换成客户端所期望的另一个接口，以解决由于接口不兼容或不匹配而无法协同工作的问题。使用适配器模式，新增加了适配类和接口，能够在不修改原来类的接口的前提下，使得原本无法一起工作的类能够一起工作，符合软件设计的开闭原则，同时也提高了代码的复用性，并降低了新旧接口之间的耦合度。

组合模式将具有父子关系的对象组合成树形结构。使用时需先抽象出节点的共有方法，提供统一的接口，使得客户端对叶子节点（无子节点）和组合节点（有子节点）的使用具有一致性。提取共有方法，可分为两种方式。

享元模式，将程序中可能反复创建且种类固定的对象缓存起来，以便共享。通常使用一个享元工厂来创建享元对象，保证享元类的一个实例只能被创建一次，客户端获取享元对象时，先查看对象是否已经创建，若已经创建，则直接从缓存中获取，否则创建新的对象返回并缓存起来。

在开发中使用代理模式，可以在不修改原始对象代码的情况下，为其增加新的操作或功能，符合软件设计的开闭原则。代理模式可分为静态代理和动态代理。

工厂模式隐藏了对象的实例化细节，调用者通过工厂获取到自己需要的对象实例，从而将客户端与调用的对象解耦。工厂模式根据不同的使用场景可分为三种。简单工厂模式，工厂方法模式，抽象工厂模式。

即使在没有学习过设计模式之前，只要是写过代码，都会在不经意间使用到外观模式，或者说用到了外观模式的思想。外观模式的定义：通过创建一个统一的高层接口，使得复杂的子系统更加容易使用。这个模式为复杂的系统提供一个简化的接口，隐藏系统的复杂性，并使得客户端代码与子系统之间的交互更加容易进行。

建造者模式适用于构建复杂对象，并将对象的构建过程和表示过程相互分离，使得同样的构建过程可以创建不同的表示。要构建的对象的成员变量需要有较好的稳定性，不会轻易增加或者删除,且一般都有默认值理论上使用建造者模式时，需要创建的对象相对复杂，有多个组成部分且这些部分的构建顺序可能不同，也可能需要不同的构建过程。实际上，即便是简单对象也能直接套用建造者模式，构造过程链式调用，代码可读性更好。

单例模式是开发中常用的设计模式，当一个类只需要一个实例，并且全局都可以访问时，使用单例模式设计就可以避免重复创建对象实例，从而节省系统资源。在实际的web 项目中一般都有 http 请求工具类，使用单例模式，创建一个实例后，调用时便可以复用该实例对象进行 http 请求操作。单例模式的写法有多种，按加载时机可分为饿汉式和懒汉式。

在业务开发中，有时需要对业务对象进行一次复制，得到一个一模一样的副本。最直观的做法就是重新 new 一个对象，然后将原型对象的值依次设置到克隆对象中，但是这样写代码过于冗余，也不高效。设计模式中的原型模式便可以很好的解决这个问题，Java 已经内置了抽象原型接口 Cloneable，只需要实现该接口，便能够通过 clone 方法快速复制一个克隆的对象，应当注意的是，clone 是浅拷贝，如果类中存在引用对象属性，则原型对象和克隆对象的该属性会指向同一个对象引用。

业务开发时，不同的业务代码值下需要执行不同的业务逻辑，最直接的做法就是堆砌 if else 来判断后再执行相应的业务逻辑。这样子做功能是可以实现，只不过就是开发一时爽，维护火葬场。若业务的选择分支多且业务逻辑复杂的情况下，那么此处代码会变得十分臃肿，违背单一职责原则。若业务需求有变动的话，修改则有可能影响其它业务逻辑，违背开闭原则。这种业务场景可以使用策略模式来实现，将不同的业务逻辑拆分到不同的策略类中，根据不同的业务代码拿到不同的策略，来执行不同的业务逻辑。