1、单例模式
可以说设计模式中最常应用的一种模式了，据说也是面试官最喜欢的题目。但是如果没有学过设计模式的人，可能不会想到要去应用单例模式，面对单例模式适用的情况，可能会优先考虑使用全局或者静态变量的方式，这样比较简单，也是没学过设计模式的人所能想到的最简单的方式了。
一般情况下，我们建立的一些类是属于工具性质的，基本不用存储太多的跟自身有关的数据，在这种情况下，每次都去new一个对象，即增加了开销，也使得代码更加臃肿。其实，我们只需要一个实例对象就可以。如果采用全局或者静态变量的方式，会影响封装性，难以保证别的代码不会对全局变量造成影响。
考虑到这些需要，我们将默认的构造函数声明为私有的，这样就不会被外部所new了，甚至可以将析构函数也声明为私有的，这样就只有自己能够删除自己了。在Java和C#这样纯的面向对象的语言中，单例模式非常好实现，直接就可以在静态区初始化instance，然后通过getInstance返回，这种就被称为饿汉式单例类。也有些写法是在getInstance中new instance然后返回，这种就被称为懒汉式单例类，但这涉及到第一次getInstance的一个判断问题。
常用的场景
单例模式常常与工厂模式结合使用，因为工厂只需要创建产品实例就可以了，在多线程的环境下也不会造成任何的冲突，因此只需要一个工厂实例就可以了。
优点
1.减少了时间和空间的开销（new实例的开销）。
2.提高了封装性，使得外部不易改动实例。
缺点
1.懒汉式是以时间换空间的方式。
2.饿汉式是以空间换时间的方式。
image.png
双检查锁
image.png
2、状态模式
- 概述
当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。 - 解决的问题
主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同的一系列类当中，可以把复杂的逻辑判断简单化。 - 模式中的角色
3.1 上下文环境（Context）：它定义了客户程序需要的接口并维护一个具体状态角色的实例，将与状态相关的操作委托给当前的Concrete State对象来处理。
3.2 抽象状态（State）：定义一个接口以封装使用上下文环境的的一个特定状态相关的行为。
3.3 具体状态（Concrete State）：实现抽象状态定义的接口
4.代码实例（略） - 模式总结
5.1 优点
5.1.1 状态模式将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。
5.1.2 所有状态相关的代码都存在于某个ConcereteState中，所以通过定义新的子类很容易地增加新的状态和转换。
5.1.3 状态模式通过把各种状态转移逻辑分不到State的子类之间，来减少相互间的依赖。
5.2 缺点
5.2.1 导致较多的ConcreteState子类
5.3 适用场景
5.3.1 当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，就可以考虑使用状态模式来。
5.3.2 一个操作中含有庞大的分支结构，并且这些分支决定于对象的状态。
