一、设计模式7大原则
面向对象：
1. 开闭原则：对扩展开放，对修改关闭
2. 依赖倒置：依赖于抽象，不要依赖于具体
拆分结构：
3. 单一职责（对业务）：一个类应该只承担一个职责，设计接口时职责要明确，保证功能单一。（需要根据需求控制粒度，并非越细越好）
4. 接口隔离（对架构）：提倡具体类不应该依赖于它不需要的接口，推依赖多个隔离的接口，而不是一个单一臃肿的接口
类之间的联系：
5. 合成复用：尽量使用组合、聚合关系，实现类的复用，少用继承关系
6. 里氏替换：针对继承复用，任何基类可以出现的地方，子类一定可以出现，避免子类直接覆盖父类的非抽象方法。
7. 最少知识原则：也称迪米特法则，一个类对其它类知道的越少越好。初衷是为了降低类之间的耦合性，尽量减少一个类和另一个类发生相互作用的可能性。使得模块功能相互独立
二、设计模式分类
（1）创建型模式
抽象工厂模式是一种创建型设计模式，它提供了一种创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
使用场景：
1.当需要创建一组相关的对象时，可以使用抽象工厂模式。例如，创建一个操作系统的界面元素，包括按钮、文本框、标签等。
2.当需要创建一组相互依赖的对象时，可以使用抽象工厂模式。例如，创建一个汽车工厂，需要创建引擎、轮胎、座椅等多个部件，这些部件之间存在依赖关系。
3.当需要在不同的平台上使用不同的实现时，可以使用抽象工厂模式。例如，创建一个跨平台的图形界面库，需要在不同的操作系统上使用不同的实现。
4.当需要在运行时动态切换不同的实现时，可以使用抽象工厂模式。例如，创建一个游戏，需要在不同的关卡中使用不同的敌人、武器等。
作用：
1）提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类
2）抽象工厂模式将一组对象的实现细节与它们的一般使用分离开来
适用场景：
1）游戏服装套装，通常一整套一起换
2）操作系统的组件模块，同一组模块需对应相同的系统
优点：
1） 规范了创建相同系列产品的方式
2）只需要暴露创建的接口 ，可以隐藏实现细节
3）容易改变产品的系列
缺点：
1）扩展产品需要额外工作，除了产品代码外，还需要改动Factory
建造者模式（Builder）是一种创建型设计模式，它的主要目的是将一个复杂对象的构建过程与其表示分离，使得同样的构建过程可以创建不同的表示。
适用场景：
1.当需要创建的对象具有复杂的内部结构，且其构建过程需要多个步骤或者多个部件参与时，可以使用建造者模式。
2.当需要创建的对象的属性较多，且这些属性之间存在一定的依赖关系时，可以使用建造者模式。
3.当需要创建的对象的表示方式较多，且需要根据不同的表示方式进行构建时，可以使用建造者模式。
4.当需要创建的对象的构建过程需要进行灵活的组合时，可以使用建造者模式。
总之，建造者模式适用于需要创建复杂对象的场景，它可以将对象的构建过程与其表示分离，使得构建过程更加灵活、可扩展和易于维护。
作用：
1）逐步构建复杂的对象
适用场景：
1）对象复杂不单一，需要通过特定组合完成创建过程。
2）对象的属性互相依赖，需要指定顺序生成产品。
优点：
1）分步创建，更加灵活
2）每个具体建造者都相对独立，可以很方便地替换具体建造者或增加新的具体建造者
缺点：
1）不适用于产品之间差异较大的的对象
2）如果内部变化复杂，则需要非常多的具体建造者类来实现这种变化从而增加系统复杂度
工厂方法模式是一种创建型设计模式，它定义了一个用于创建对象的接口，但是让子类决定实例化哪个类。工厂方法模式让类的实例化推迟到子类中进行，从而实现了解耦合，使得代码更加灵活。
使用场景：
1.当一个类不知道它所必须创建的对象的类时，可以使用工厂方法模式。
2.当一个类希望由它的子类来指定所创建的对象时，可以使用工厂方法模式。
3.当类将创建对象的职责委托给多个帮助子类中的某一个，并且希望将哪一个帮助子类是代理者这一信息局部化时，可以使用工厂方法模式。
4.当一个类需要自行创建对象时，可以使用工厂方法模式。
5.当一个类需要提供一个高层次的抽象接口以便于其它部分的代码调用时，可以使用工厂方法模式。
作用：
1）将产品的实例化延迟到具体工厂中去完成
适用场景：
1）创建对象需要使用大量重复代码
2）无需客户端知道具体产品的类别及其依赖关系，只需要知道对应工厂
优点：
1）加入新产品时，无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其他的具体工厂和具体产品，只要添加一个具体工厂和具体产品就可以了
2）能够让工厂可以自主确定创建何种产品对象，向客户隐藏了具体实现细节。
缺点：
1）每增加一个产品就要添加具体工厂类
原型模式是一种创建型设计模式，它允许通过复制现有对象来创建新对象，而不是通过实例化类来创建新对象。使用原型模式可以避免重复创建相似对象的开销，同时也可以简化对象的创建过程。
原型模式适用于以下场景：
1.当需要创建的对象的类型已经存在，并且需要创建的对象与现有对象非常相似时，可以使用原型模式来复制现有对象，而不是重新创建一个新对象。
2.当创建对象的过程比较复杂或者耗时较长时，可以使用原型模式来避免重复创建对象的开销，提高性能。
3.当需要创建的对象的类型不确定时，可以使用原型模式来动态创建对象，而不需要知道具体的类型。
4.当需要创建的对象需要根据不同的条件进行定制时，可以使用原型模式来创建不同的对象，而不需要重新编写代码。
总之，原型模式适用于需要创建相似对象的场景，可以提高代码的复用性和性能。
单例模式是一种创建型设计模式，它保证一个类只有一个实例，并提供一个全局访问点。
单例模式的使用场景包括：
1.当一个类只需要一个实例时，例如线程池、日志记录器、配置文件管理器等。
2.当多个实例会导致资源浪费或冲突时，例如数据库连接池、缓存管理器等。
3.当需要控制某个类的实例数量时，例如操作系统中的窗口管理器、任务管理器等。
4.当需要在系统中全局访问某个对象时，例如全局配置信息、全局计数器等。
总之，单例模式适用于需要保证全局唯一性、节约资源、控制实例数量等场景。
（2）结构型模式
适配器模式是一种结构型设计模式，它的主要作用是将一个类的接口转换成客户端所期望的另一个接口，从而使得原本由于接口不兼容而无法一起工作的类能够协同工作。
适配器模式的使用场景包括：
1.当需要使用一个已经存在的类，但是它的接口不符合当前需要的接口时，可以使用适配器模式来进行接口转换。
2.当需要复用一些现有的类，但是这些类的接口不符合当前系统的需求时，可以使用适配器模式来进行接口转换。
3.当需要创建一个可以复用的类，该类与其他类的接口不兼容时，可以使用适配器模式来进行接口转换。
4.当需要在不修改现有类的情况下，对现有类的功能进行扩展时，可以使用适配器模式来进行接口转换。
总之，适配器模式适用于需要将一个类的接口转换成另一个接口的场景，以便让这些类能够协同工作。
桥接模式（Bridge）是一种结构型设计模式，它将抽象部分和实现部分分离，使它们可以独立地变化。桥接模式的核心思想是将一个大类或一系列紧密相关的类拆分成两个独立的层次结构，从而能够在两个层次结构之间建立一个桥接。
使用桥接模式的场景包括：
1.当需要跨越多个平台或多个实现方式时，可以使用桥接模式来实现解耦。
2.当需要在抽象和具体实现之间增加更多的灵活性时，可以使用桥接模式。
3.当需要在运行时切换实现时，可以使用桥接模式。
4.当需要在不同的抽象实体中共享实现时，可以使用桥接模式。
当需要对一个类进行多维度的变化时，可以使用桥接模式。
组合模式（Composite）是一种结构型设计模式，它允许将对象组合成树形结构来表示“部分-整体”的层次结构，使得客户端可以统一处理单个对象和组合对象。
使用场景：
1.当需要表示对象的部分-整体层次结构时，可以使用组合模式。例如，文件系统中的文件夹和文件，图形界面中的控件和容器等。
2.当希望客户端能够忽略组合对象与单个对象的差异，统一对待它们时，可以使用组合模式。例如，对于一个文件夹，客户端可以像对待一个文件一样进行打开、复制、删除等操作。
3.当希望在不同层次结构中使用相同的操作时，可以使用组合模式。例如，对于文件夹和文件，都可以进行重命名、移动等操作。
4.当需要动态地增加或删除组合对象时，可以使用组合模式。例如，可以在运行时向文件夹中添加文件或子文件夹。
总之，组合模式适用于需要表示部分-整体层次结构的场景，同时需要对单个对象和组合对象进行统一处理的场景。
装饰模式是一种结构型设计模式，它允许在运行时动态地给一个对象添加额外的职责，而不需要修改原始对象的代码。装饰模式通过将对象包装在一个装饰器对象中，来实现对对象的功能扩展。
使用装饰模式的场景包括：
1.当需要在不影响其他对象的情况下，动态地给一个对象添加一些额外的职责时，可以使用装饰模式。
2.当需要给一个对象添加的职责是可撤销的时，可以使用装饰模式。
3.当需要通过多个不同的方式来扩展一个对象的功能时，可以使用装饰模式。
4.当需要在不修改原始对象的代码的情况下，对对象进行功能扩展时，可以使用装饰模式。
5.当需要对一个对象的功能进行动态组合时，可以使用装饰模式。
外观模式是一种结构型设计模式，它提供了一个简单的接口，隐藏了一个或多个复杂的子系统的复杂性，使得客户端可以更方便地使用这些子系统。
外观模式的使用场景包括：
1.当一个系统有多个复杂的子系统时，可以使用外观模式将这些子系统封装起来，提供一个简单的接口给客户端使用。
2.当客户端需要访问一个复杂的系统时，可以使用外观模式来简化客户端的代码，减少客户端与系统之间的耦合度。
3.当需要对一个复杂的系统进行重构时，可以使用外观模式来逐步重构子系统，同时保持外观接口不变，从而减少对客户端的影响。
4.当需要为一个复杂的系统提供一个简单的接口时，可以使用外观模式来封装系统的复杂性，使得客户端可以更方便地使用系统。
享元模式是一种结构型设计模式，它的主要目的是通过共享对象来减少内存使用和提高性能。在享元模式中，对象被分为两种类型：内部状态和外部状态。内部状态是可以共享的，而外部状态则是不可共享的。
使用场景：
1.当需要创建大量相似的对象时，可以使用享元模式来减少内存使用和提高性能。
2.当需要缓存对象以提高性能时，可以使用享元模式来实现对象的共享。
3.当需要对对象进行细粒度控制时，可以使用享元模式来实现对象的共享和复用。
4.当需要在多个对象之间共享状态时，可以使用享元模式来实现状态的共享和复用。
5.当需要在系统中使用少量的对象来代表大量的实体时，可以使用享元模式来实现对象的共享和复用。
代理模式是一种结构型设计模式，它的主要目的是为其他对象提供一个代理以控制对这个对象的访问。代理对象可以在不改变原始对象的情况下，增加一些额外的功能，比如权限控制、缓存、延迟加载等。
使用场景：
1.当需要控制对对象的访问时，可以使用代理模式来实现权限控制、安全性检查等功能。
2.当需要在访问对象之前或之后执行一些额外的操作时，可以使用代理模式来实现日志记录、性能监控等功能。
3.当需要对对象进行缓存时，可以使用代理模式来实现缓存功能，避免重复创建对象，提高性能。
4.当需要实现远程调用时，可以使用代理模式来实现远程代理，将对象的调用转发到远程服务器上执行。
5.当需要实现延迟加载时，可以使用代理模式来实现虚拟代理，将对象的创建延迟到真正需要使用时再进行创建。
特点：
1）让一个对象控制另一个对象的访问
2）让代理充当其它对象的接口
使用场景：
1）访问控制
2）缓存，为某一个操作的结果提供临时的缓存存储空间，以便在后续使用中能够共享这些结果
3）保护代理，可以控制对一个对象的访问权限，为不同用户提供不同级别的使用权限
4）远程对象，给远程服务器对象提供本地的表示
5）智能引用，可以用来管理对象的引用，比如计数引用的次数
6）日志记录、监控、审计
优点：
1）关注点分离
2）延迟实例化
3）提供额外的行为
缺点：
1）增加复杂性
2）由于间接性，增加了调试和理解代码难度
（3）行为型模式
1. 责任链模式（Chain Of Responsibility）
责任链模式是一种行为型设计模式，它的主要目的是将请求从一个对象传递到另一个对象，直到找到能够处理请求的对象为止。在责任链模式中，每个对象都有机会处理请求，如果一个对象不能处理请求，它会将请求传递给下一个对象，直到找到能够处理请求的对象为止。
使用场景：
1.当需要将请求从一个对象传递到另一个对象时，可以使用责任链模式来实现请求的传递和处理。
2.当需要动态地组合和切换对象处理请求时，可以使用责任链模式来实现对象的动态组合和切换。
3.当需要避免请求发送者和接收者之间的耦合关系时，可以使用责任链模式来实现请求的解耦。
4.当需要对请求进行过滤和处理时，可以使用责任链模式来实现请求的过滤和处理。
5.当需要对请求进行优先级排序时，可以使用责任链模式来实现请求的优先级排序和处理。
特点：
1）允许多个对象按顺序处理
使用场景：
1）有多个对象可以处理同一个请求，具体哪个对象处理该请求待运行时刻再确定
2）在不明确指定接收者的情况下，向多个对象中的一个提交一个请求
3）可动态指定一组对象处理请求，客户端可以动态创建职责链来处理请求，还可以改变链中处理者之间的先后次序
优点：
1）分离发送者和接收者，使得一个对象无须知道是其他哪一个对象处理其请求
2）仅需维持一个指向其后继者的引用，而不需要维持它对所有的候选处理者的引用
3）更多的灵活性，可在运行时对该链进行动态的增加或修改来增加或改变处理一个请求的职责
4）增加一个新的具体请求处理者无需修改原系统代码，只需要在客户端重新建链即可。
缺点：
1）由于一个请求没有明确的接收者，无法保证请求一定处理
2）对于比较长的职责链，系统性能将受到一定影响，且在进行代码调试时不太方便
3）如果建链不当，可能会造成循环调用，将导致系统陷入死循环
应用：
1）ATM取款机按顺序吐钞，优先吐100，然后吐50，然后10，然后5
2）中间件、GUI事件处理、异常处理、工作流
命令模式是一种行为型设计模式，它将请求封装成一个对象，从而使你可以用不同的请求对客户端进行参数化，对请求排队或记录请求日志，以及支持可撤销的操作。
命令模式的使用场景包括：
1.需要将请求发送者和接收者解耦，使得发送者和接收者不直接交互。
2.需要支持撤销操作，即可以撤销已经执行的命令。
3.需要支持命令的排队执行、记录日志、重做等操作。
4.需要支持事务性操作，即一组命令可以作为一个事务进行执行。
5.需要支持命令的异步执行，即可以将命令放入队列中，由后台线程异步执行。
6.需要支持命令的分布式执行，即可以将命令发送到远程服务器执行。
命令模式在实际应用中广泛使用，例如文本编辑器中的撤销、重做操作，电视遥控器中的按钮操作，以及数据库事务管理等。
解释器模式是一种行为型设计模式，它定义了一种语言文法，并且定义了一个解释器来解释该语言中的语句。该模式的主要目的是将一个复杂的问题分解成简单的问题，并且提供一种简单的方式来解决这些问题。
使用场景：
1.当需要解释一种语言时，可以使用解释器模式。例如，编译器、解释器、正则表达式等。
2.当需要对一些规则进行解释时，可以使用解释器模式。例如，数学公式、逻辑表达式等。
3.当需要对一些复杂的数据结构进行解释时，可以使用解释器模式。例如，XML文档、JSON数据等。
4.当需要对一些简单的语法进行解释时，可以使用解释器模式。例如，命令行解释器、配置文件解释器等。
总之，解释器模式适用于需要解释一种语言或规则的场景，它可以将复杂的问题分解成简单的问题，并且提供一种简单的方式来解决这些问题。
迭代器模式是一种行为型设计模式，它提供了一种访问聚合对象中各个元素的方法，而不需要暴露聚合对象的内部结构。该模式的主要目的是提供一种通用的方式来遍历聚合对象中的元素，而不需要关心聚合对象的具体实现。
使用场景：
1.当需要遍历一个聚合对象中的元素时，可以使用迭代器模式。例如，遍历一个列表、数组、树等。
2.当需要对聚合对象进行不同的遍历方式时，可以使用迭代器模式。例如，正序遍历、倒序遍历、随机遍历等。
3.当需要隐藏聚合对象的内部结构时，可以使用迭代器模式。例如，遍历一个数据库查询结果集时，不需要暴露查询语句和数据库连接等细节。
4.当需要提供一种通用的遍历方式时，可以使用迭代器模式。例如，Java中的Iterator接口就提供了一种通用的遍历方式，可以用于遍历各种类型的集合。
总之，迭代器模式适用于需要遍历聚合对象中的元素，并且需要提供一种通用的遍历方式的场景。它可以隐藏聚合对象的内部结构，提供不同的遍历方式，并且提供一种通用的遍历接口。
中介者模式是一种行为型设计模式，它的主要作用是解耦多个对象之间的交互关系，将对象之间的交互转移到中介者对象中进行处理。中介者模式适用于以下场景：
1.当多个对象之间存在复杂的交互关系，导致对象之间的耦合度过高，难以维护和扩展时，可以考虑使用中介者模式。
2.当一个对象的行为依赖于其他对象的状态时，可以使用中介者模式来协调这些对象之间的交互，避免出现相互依赖的情况。
3.当系统中的对象需要进行复杂的协作时，可以使用中介者模式来简化对象之间的交互，提高系统的可维护性和可扩展性。
4.当系统中的对象之间存在循环依赖关系时，可以使用中介者模式来打破这种依赖关系，避免出现死锁等问题。
总之，中介者模式适用于需要协调多个对象之间的交互，降低对象之间的耦合度，提高系统的可维护性和可扩展性的场景。
备忘录模式是一种行为型设计模式，它允许在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便在需要时恢复对象到先前的状态。
备忘录模式适用于以下场景：
1.需要保存和恢复对象的状态，以便在后续操作中可以回滚到之前的状态。
2.需要在不破坏对象封装性的前提下，让其他对象可以访问对象的状态。
3.需要实现撤销和重做功能，以便用户可以撤销之前的操作并恢复到之前的状态。
4.需要实现快照功能，以便在某个时间点可以保存对象的状态，并在需要时恢复到该时间点的状态。
5.需要实现事务功能，以便在多个操作中可以保证数据的一致性和完整性。
观察者模式是一种行为型设计模式，它定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象，当主题对象发生变化时，它的所有观察者都会收到通知并自动更新。
观察者模式适用于以下场景：
1.当一个对象的改变需要同时改变其他对象时，可以考虑使用观察者模式。
2.当一个对象需要通知其他对象，但又不希望这些对象和它之间产生耦合关系时，可以考虑使用观察者模式。
3.当一个对象的改变需要同时改变多个对象，但是不知道具体有多少个对象需要改变时，可以考虑使用观察者模式。
4.当一个对象的改变需要通知其他对象，但是这些对象的数量和类型在运行时可能发生变化时，可以考虑使用观察者模式。
5.当一个对象的改变需要通知其他对象，但是这些对象不需要知道具体的改变细节时，可以考虑使用观察者模式。
特点：
1）一对一或者一对多的对象交互场景
使用场景：
1）一个对象的改变将导致一个或多个其他对象也发生改变，而不知道具体有多少对象将发生改变，也不知道对象是谁
2）需要在系统中创建一个触发链，A对象的行为将影响B对象，B影响C，C影响D.......，可使用观察者模式创建一种链式触发机制
优点：
1）可以实现表示层和数据逻辑层的分离，定义了稳定的消息更新传递机制
2）在观察目标和观察者之间建立一个抽象的耦合。观察目标只需要维持一个抽象观察者的集合，无须了解其具体观察者
3）支持广播通信，观察目标会向所有已注册的观察者对象发送通知，简化了一对多系统设计的难度
缺点：
1）如果在观察者和观察目标之间存在循环依赖，观察目标会触发它们之间进行循环调用
2）没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化
状态模式（State）是一种行为型设计模式，它允许对象在其内部状态发生改变时改变其行为。该模式将对象的行为封装在不同的状态类中，使得对象在不同状态下可以有不同的行为。
使用场景：
1.当一个对象的行为取决于其状态，并且它必须在运行时根据状态改变其行为时，可以使用状态模式。
2.当一个对象的行为在不同状态下有不同的实现时，可以使用状态模式。
3.当一个对象的状态转换频繁且复杂时，可以使用状态模式来简化状态转换的实现。
4.当需要在运行时动态地添加、删除或修改对象的状态时，可以使用状态模式。
5.当一个对象的状态转换需要遵循一定的规则或约束时，可以使用状态模式来实现这些规则或约束。
策略模式是一种行为型设计模式，它定义了一系列算法，将每个算法封装起来，并使它们可以互换。策略模式使得算法可以独立于使用它的客户端而变化。
使用策略模式的场景包括：
1.当需要在运行时根据不同的情况选择不同的算法时，可以使用策略模式。
2.当一个类有多个行为，而这些行为在不同的情况下有不同的实现方式时，可以使用策略模式。
3.当需要在不同的场景下使用不同的算法时，可以使用策略模式。
4.当需要将算法的实现与使用算法的客户端分离开来时，可以使用策略模式。
5.当需要避免使用大量的条件语句来选择不同的算法时，可以使用策略模式。
模板方法模式是一种行为型设计模式，它定义了一个算法的骨架，将一些步骤延迟到子类中实现。模板方法模式使得子类可以在不改变算法结构的情况下重新定义算法中的某些步骤。
使用场景：
1.当多个类有相同的算法时，可以使用模板方法模式将这些算法抽象出来，避免代码重复。
2.当需要控制算法的流程时，可以使用模板方法模式。例如，可以在模板方法中定义算法的执行顺序，以及在何时调用哪些方法。
3.当需要在不同的情况下使用相同的算法时，可以使用模板方法模式。例如，可以在模板方法中定义算法的基本结构，然后在子类中实现不同的细节。
4.当需要在运行时动态地扩展算法时，可以使用模板方法模式。例如，可以在模板方法中定义算法的基本结构，然后在运行时动态地添加或删除某些步骤。
访问者模式是一种行为型设计模式，它的主要目的是将算法与对象结构分离开来，使得算法可以独立于对象结构而变化。
访问者模式适用于以下场景：
1.对象结构中的元素类很少改变，但经常需要在不同的场景下执行不同的操作。
2.对象结构中的元素类有很多，但是它们的接口不太可能改变，而且经常需要在不同的场景下执行不同的操作。
3.需要对对象结构中的元素进行复杂的操作，而且这些操作的实现方式可能随着时间的推移而发生变化。
4.对象结构中的元素类之间的关系比较复杂，而且需要在不同的场景下执行不同的操作。
总之，访问者模式适用于需要对一个复杂的对象结构进行操作，并且这些操作需要在不同的场景下进行变化的情况。它可以将算法与对象结构分离开来，使得算法可以独立于对象结构而变化，从而提高了系统的灵活性和可扩展性。
