设计模式基本原则
- 开放-封闭原则（OCP），是说软件实体（类、模块、函数等等）应该可以拓展，但是不可修改。
开-闭原则是面向对象设计中最基本的原则，曾经看过一篇文章对此归纳的非常好。
- 单一职责原则（SRP），就一个类而言，只做一件事。
- 依赖倒转原则（DIP），A. 高层模块不应该依赖低层模块，两个都应该依赖抽象。B. 抽象不应该依赖细节，细节应该依赖抽象。
- 里氏代换原则（LSP），子类型必须能够替换掉它们的父类型。
- 迪米特法则（LoD），如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
- 合成/聚合复用原则（CARP），尽量使用合成/聚合，尽量不要使用类继承。
设计模式
- 策略模式（Strategy），它定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。
- 装饰模式（Decorator），动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。
- 代理模式（Proxy），为其他对象提供一种代理以控制对这个对象的访问。
- 工厂方法模式（Factory Method），定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
- 原型模式（Prototype），用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
- 模板方法模式（Template Method），定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
- 外观模式（Facade），为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
建造者模式（Builder），将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 - 观察者模式（Observer），定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。
- 抽象工厂模式（Abstract Factory），提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
状态模式（State），当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。 - 适配器模式（Adapter），将一个类的接口转换成客户希望的另外一个接口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
- 备忘录模式（Memento），在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
- 组合模式（Composite），将对象组合成树形结构以表示‘部分-整体’的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
- 迭代器模式（Iterator），提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示。
- 单例模式（Singleton），保证一个类仅有一个实例，并提供一个访问它的全局访问点。
- 桥接模式（Bridge），将抽象部分与它的实现部分分离，使它们都可以独立地变化。
- 命令模式（Command），将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
- 职责链模式（Chain of Responsibility），使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
- 中介者模式（Mediator），用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
- 享元模式（Flyweight），运用共享技术有效地支持大量细粒度的对象。
- 解释器模式（Interpreter），给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
- 访问者模式（Visitor），表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
简单工厂模式
通过一个计算器小程序引入话题。
需求，用户输入运算符及两个参数，得出运算结果。
版本1
输入a,b,符号，然后通过swith判断运算方式。
问题：耦合，扩展性较差，每次添加新运算方式都需要改动源代码。
版本2
界面部分与逻辑部分分离耦合度下降，使得逻辑部分可以复用，更加容易维护和扩展。
问题：当需要添加运算方式的时候，需要频繁改动逻辑部分，现在需要将逻辑部分再次进行拆分，运用面向对象的继承。
版本3
逻辑部分，利用了继承，抽象父类Operation类实现getResult方法，子类加减乘除等实际的运算重写getResult，实现修改其中一个不影响另一个。
版本4
简单工厂模式，用一个单独的类来进行这个创造实例的过程，这就是工厂。将运算符号输入工厂，得到对应的运算子类，通过多态，直接使用父类的getResult方法实际上是子类的getResult方法。
- 封装、继承、多态可以降低程序耦合度。
- 用设计模式使得程序更加简单灵活，容易修改复用。
- 业务逻辑与界面逻辑分离，降低耦合度增强程序维护扩展性。
- 多态的使用可以通过父类（实际上是子类）实现计算器的结果。
- UML类图
策略模式
通过一个商场收银软件来引入话题。
需求，商场收银软件，收银员根据客户购买的商品的单价和数量向客户收费。用两个textField输入单价和数量，一个label显示总计，一个tableView记录商品清单。
版本1
确认按钮点击事件中处理计算商品总价、更新商品列表等等相关逻辑。
问题：当需要修改商品价格计算逻辑的时候，如打折、满减，就需要改动逻辑部分代码，而且更换一次就要改用一次。
版本2
添加下拉选框中提供对应的价格计算逻辑，然后在逻辑中根据选框中的index决定对应计算逻辑。
问题：逻辑部分耦合度还是高，应该跟之前的运算方法一样将价格计算逻辑抽成对象，使用简单工厂模式创建相关逻辑，逻辑中提供相关初始化参数如打折幅度、满X减Y。
版本3
抽离价格计算逻辑类，抽象类包含各种实际子类，创建时进行初始化。
问题：如果需要打折+满减则又不满足需求。
版本4
应用策略模式。价格计算抽象类就是抽象策略，正常收费、打折、返利等具体计算方法就是具体策略。客户端只需要给cashContext配置需要什么策略，context内部自行生成相关的价格计算逻辑，这样客户端就不需要引入计算逻辑抽象类和工厂方法类，进一步降低了耦合度。
- 面向对象的编程并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类。
- 策略模式（Strategy）定义了算法家族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。
- 策略模式是一种定义一系列算法的方法，从概念上来看，所有算法完成的都是相同的工作，只是具体实现不同，他可以以相同的方式调用所有的算法，减小了各种算法类与使用算法类之间的耦合。
- 策略模式为Context定义了一系列可供重用的算法或者行为，继承有助于析取出这些算法中的公共功能，打折、返利或者其他的算法，都是对实际商品收费的一种计算方式，通过继承可以得到他们的公共功能。
- 策略模式还简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试，算法之间也相互独立。
- 当不同的行为堆砌在一个类中时，就很难避免使用条件语句来选择合适的行为。将这些行为封装到一个个不同的策略类中，可以使用这些行为的类中消除条件语句（个人；理解是从把客户端中的判断逻辑转移到context中）。
- 策略模式就是用来封装算法的，但是在实践中，我们可以用来封装各种类型的规则，只要在分析过程中听到需要在不同的时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性。
- 在基本的策略模式中，选择所用的具体策略的职责还是由客户端承担，并转移给context对象，并没有减轻客户端需要选择判断的压力，而策略模式与简单工厂模式结合后，选择具体实现的职责也由context承担，这就最大化的减轻了客户端的职责。但是仍有一点不足，就是依然在context中用到了switch，后面的反射会解决这个问题。
- 任何需求的变更都是需要成本的，但高手和菜鸟的区别就是高手可以花更小的代价获取更大的收益。
单一职责原则
通过现在智能手机功能多而不专引入话题--单一职责原则。
需求，设计一个俄罗斯方块的游戏。
分析：绘制四个小方块，擦掉，然后在下一行绘制四个小方块，不断绘制和擦除就形成了方块下落的动画，所以需要方块显示和擦除的方法。方向键控制左右移动，下键实现加速，上键实现旋转，这其实都是方法。还需要考虑碰撞、堆积和消层的问题。
版本1
一个View，一个button开始，一个timer，绘制、擦除方块的方法，并同时做堆积消层的判断，然后通过键盘事件调用对应的方法，而这些方法都在view中。
版本2
界面、逻辑分离。逻辑部分使用二维数组抽象表示方块进行计算，界面根据计算出的二维数组进行显示。
- 单一职责原则（SRP）就是一个类而言，应该仅有一个引起它变化的原因。
- 一个类承担的职责过多，就等于把这些职责耦合在一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏（个人理解，不管是类、还是方法，都需要做到单一职责原则）。
- 软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑职责的分离。
开放、封闭原则
- 开放-封闭原则是说软件实体（类、模块、函数等）应该是可扩展但不可修改，或者说对于扩展是开放的，对于修改是封闭的。这样可以使得设计在面对需求的改变保持相对稳定，不断迭代。
- 无论模块多么封闭，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对那种变化进行封闭做出选择。他必须先猜测出最有可能发生的变化的种类，然后构造抽象来隔离这些变化。
- 在最初写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。
- 面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。
- 我们希望的是在开发工作展开不久就知道可能发生的变化，查明可能发生的变化等待的时间越长，要创建正确的抽象就越困难。
- 开放-封闭原则是面向对象设计的核心所在，遵循这个原则可以带来面向对象技术所声称的巨大好处，就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的部分进行抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。
依赖倒置原则
通过修电脑，电脑的各个部件易插拔、有统一的接口引入话题。
- 依赖倒置原则是抽象不该依赖于细节，细节应该依赖于抽象。
- 针对接口编程，不要针对实现编程。
- 依赖倒置原则
1.高层模块不应该依赖底层模块，两个都应该依赖于抽象。
2.抽象不应该依赖细节，细节应该依赖抽象。 - 里氏代换原则就是一个软件实体如果使用一个父类的话。那么一定适用其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，，在软件中把父类替换成它的子类，程序的行为没有变化。简单地说，子类型必须能够替换到他们的父类型（继承）。
- 只有当子类可以替换掉父类，软件单位的功能不受影响时，父类才能真正的复用，而子类也能够在父类的基础上增加新的行为。
- 正是因为子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展。
- 依赖倒转其实可以说是面向对象设计的标志，用哪种语言来编写程序或许不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象设计，反之那就是过程化设计了。
装饰模式
需求，设计一个搭配服饰的系统。
版本1
person类中有name属性和wearCloth的对象方法。
问题：当需要增加新的装扮，就需要修改person类，这样就违反了开放-封闭原则。
版本2
将服饰抽成一个抽象类，具体服装为子类。
问题：没有将不同衣服之间的先后等关系体现出来。
版本3
person类有形象展示的方法，服饰类继承person类，内部有装饰相关方法，然后具体服饰类就对其进行扩展。
- 装饰模式是动态的给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更加灵活。
- 可以把所需要的功能按照正确的顺序串联起来进行控制。
- 每个装饰对象的实现就和如何使用这个对象分离开了，每个装饰对象只关心自己的功能，不需要关心如何被添加到对象链当中（将原对象像礼物一样包裹了一层又一层，调用原对象的方法时同时执行自身装饰的方法）。
- 装饰模式是为已有功能动态地添加更多功能的一种方式。当系统需要新功能的时候，是向旧的类中添加新的代码。这些新添加的代码通常装饰了原有类的核心职责或主要行为，但是这些新添加的代码在主类中加入了新的字段、新的方法和新的逻辑，从而增加了主类的复杂度，而这些新加入的东西仅仅是为了满足一些只在某种特定情况下才会去执行的特殊行为的需要，而装饰模式就是一种非常好的解决方案。它把每个要装饰的功能放在单独的类中，并让这个类包装它所需要装饰的对象，因此，当需要执行特殊行为时，客户代码就可以在运行时根据需要有选择地、按顺序的使用装饰功能包装对象了。
- 优点总结下来就是把类中的装饰功能从类中搬移去除，这样可以简化原有的类。有效的把类的核心职责和装饰功能分开了，而且可以去除相关类中重复的装饰逻辑。
代理模式
通过男生通过第三人向女生表白引入话题。
- 代理模式是为其他对象提供一种代理以控制对这个对象的访问。
- 代理模式应用
1.远程代理，为一个对象在不同的地址空间提供局部代表，这样可以隐藏一个对象存在于不同地址空间的事实。
2.虚拟代理，根据需要创建开销很大的对象，通过它来存放实例化需要很长时间的真实对象。
3.安全代理，用来控制真实对象访问时的权限。
4.智能指引，是指当调用真实的对象时，代理处理另外一些事（KVO）。 - 代理模式其实就是在访问对象时引入一定程度的间接性，因为这种间接性可以附加多种用途。
工厂方法模式
简单工厂模式与工厂方法模式对比。
简单工厂模式通过运算符号switch判断需要创建的运算子类，工厂方法模式是一个运算方法对应一个工厂子类，工厂子类只能创建对应的运算子类（一一对应）。
简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断，根据客户的选择条件动态实例化相关的类，对于客户端来说去除了与具体产品的依赖。但是这样就会对扩展开放的同时对修改开放（添加新运算子类需要修改工厂类中的switch）。
为了解决这个问题，通过依赖倒置原则，将工厂类抽象出一个接口，接口只有一个创建抽象产品的工厂方法，然后所有的要生产具体类的工厂，就去实现这个接口，这样一个简单工厂模式的工厂类就变成了一个工厂抽象接口和多个具体生成对象的工厂。于是我们要增加新的功能时就不需要更改原有的工厂类了，只需要增加此功能的运算类和工厂子类就可以了。
- 工厂方法模式定义一个用于创建对象的接口，让子类决定实例化哪一个类，工厂方法使一个类的实例化延迟到其子类。
- 工厂方法模式在实现时，客户端还是需要决定实例化哪一个工厂来实现运算类，选择判断的问题还是存在的，也就是说工厂方法把简单工厂的内部逻辑判断转移到了客户端代码来进行。
- 工厂方法模式克服了简单共唱违背开放-封闭设计原则的缺点，又保持了封装对象创建过程的有点。
原型模式
通过多份简历的创建来引入话题。
需求，一个简历类，必须有姓名，可以设置性别和年龄，可以设置工作经历，需要三份简历。
版本1
三个简历对象需要进行三次实例化。
版本2
通过clone创建其他原型，不需要进行三次实例化。
- 对于编程，简单的复制粘贴极有可能造成重复代码的灾难。
- 原型模式，是用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象，其实就是从一个对象再创建另外一个可定制的对象，而且不需要知道任何创建的细节（实际上就是copy）。
- 一般在初始化信息不发生变化的情况下，克隆是最好的方法。既隐藏了对象的创建细节，又提高了性能。
- 深复制/浅复制的区别，多层深复制。
模板方法模式
通过试卷引入话题。
需求，设计一个抄试卷题目的类，题目是相同的，只有具体答案不同。
版本1
题目A，题目B，结构都是打印题目，打印答案。
问题：题目是相同的，只有答案不同，所以抄题目部分的代码重复了。
版本2
试卷父类，实现打印题目，子类试卷A、B，实现打印答案。
问题：答案其实除了a/b/c/d部分，都是一样的。
版本3
将试卷子类的答案代码抽离上升到父类中而不是让每个子类去重复。所以讲父类中加入一个虚方法，答案去实现这个虚方法即可。
- 既然用到了继承，并且肯定这个继承是有意义的，就应该要成为子类的模板，所有重复的代码都应该上升到父类去，而不是让每个子类去重复。
- 当我们要完成在某一细节层次一致的一个过程或一系列步骤，但其个别步骤在更详细的层次上的实现可能不同时，我们通常考虑使用模板方法模式处理。
- 模板方法模式，定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构几个重定义该算法的某些特定的步骤。
- 父类AbstractClass中有顶级逻辑的组成步骤，给出需要补全的抽象方法，有多个子类ConcreateClass可以与父类对应，实现父类所定义的一个或多个抽象方法，补全顶级逻辑的组成步骤，从而使得逻辑在ConcreateClass的实现各不相同。
- 模板方法模式就是通过把不变行为搬移到父类，去除子类中的重复代码，提供了一个很好的代码复用平台。
- 当不变和可变的行为在方法的子类实现中混合在一起的时候，不变的行为就会在子类中重复出现，我们可以通过模板方法模式将这些行为搬移到单一的地方，就能帮助子类摆脱重复的不变行为的纠缠。
迪米特法则
通过公司中的部门人员工作调度引入问题。
- 迪米特法则（LoD），又称最少知识原则，如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三方转发这个调用。
- 首先是在类的结构设计上，每一个类都应当尽量降低成员的访问权限，也就是不需要让别人知道的就不要公开。
- 迪米特法则的根本思想是强调了类之间的松耦合，类之间的耦合越弱，越有利于复用，一个处在松耦合的类被修改不会对有关系的类造成波及。
外观模式
通过股民炒股和投资基金的区别引入问题。
需求，编写一个股民炒股程序，股民需要操作多个股票的买入卖出。
版本1
股票类1、2、3、4、5都有买、卖的接口，股民需要分别调用5次买卖接口。
问题：代码耦合性过高。
版本2
股票类不做改变，但是股民类通过调用一个基金经理类的中间层来买卖股票，这样就简化了代码，降低了耦合度。
- 外观模式是为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易调用（个人理解这其实就相当于代码的抽取封装）。
- 在设计的初期阶段，就应该有意识的让两个不同的层分离，在层与层之间建立外观Facade，为复杂的子系统提供一个简单的接口，降低耦合度。
- 外观模式其实就是依赖倒置原则和迪米特法则的体现。
建造者模式
由吃饭时饭菜质量是由厨师做饭的细节决定引入话题。
需求，画一个小人，要有头、身体、双手、双脚。
版本1
直接画头、身体、双手、双脚的路径。
问题：直接画，代码未封装，如果需要修改条件会比较困难，容易出错，没有形成规范的流程。
版本2
胖人的类和瘦人的类，各自有相对应的绘制方法。
问题：还是由于没有规范的流程，在修改条件的时候容易出错。
版本3
建一个人的抽象类，有绘制头、身体等的抽象方法，然后胖人、瘦人子类实现具体方法。
- 建造者模式是将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
- 如果你需要将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示的意图时，就需要使用建造者模式。
- 建造者模式将一个产品内部表象与产品的生成过程分割开来，用户就只需要指定需要建造的类型就可以得到他们，而具体的建造过程和细节就不需要知道了。
- 建造者模式通常用于创建一些复杂的对象，这些对象内部构建间的建造顺序通常是稳定的，但对象内部的构建通常面临着复杂的变化。
- 建造者模式的好处是使得建造代码与表示代码分离，由于建造者隐藏了该产品是如何组装的，所以需要改变一个产品的内部表示只需要再定义一个具体的建造者就可以了。
- 建造者模式是在当创建复杂对象的书案发应该独立于该对象的组成部分以及他们的装配方法时适用的模式。
观察者模式/委托
由上班同事因未及时得到前台通知被老板发现看股票被批评引出话题。
需求，编写一个程序反映上班的事情。
版本1
前台的类有添加通知对象的方法、通知已添加对象的方法，同事是通知的接收者在得到通知后调用对应方法。
问题：前台类与同事类之间相互耦合，需要解耦，都去依赖抽象。
版本2
增加了抽象的观察者，具体观察者子类重写抽象方法，前台类中直使用抽象观察者父类，减少耦合。
问题：前台也是一个具体的类。
版本3
前台类现在作为通知者抽象类的子类，重写对应抽象方法，添加了删除观察者的方法。
- 观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时去监听某一个主题对象。这个主题对象在状态发生改变时会通知所有观察者对象，使他们可以自动更新自己。
- 观察者模式的动机是将一个系统分割成一系列相互协作的类有一个很不好的副作用，那就是需要维护相关对象间的一致性，我们不希望为了维持一致性而使各类紧密的耦合，这样会给维护、扩展和重用都带来不便。
- 观察者模式在一个对象的改变需要同时改变其他对象的时候使用，而且当不知道具体有多少对象有待改变时，应该考虑观察者模式。
- 总的来说，观察者模式的作用就是解除通知者与观察者之间的耦合，让耦合的双方都依赖于抽象而不是依赖于具体，从而使得各自的变化都不会影响另一边的变化。
- 委托就是一种引用方法的类型，一旦为委托分配了方法，委托将与该方法具有相同的行为，委托方法的使用可以向其他任何方法一样，具有参数和返回值，委托可以看做是对函数的抽象，是函数的“类”，委托的实例将代表一个具体的函数（其实就是OC的Block）。
- 一个委托可以搭载多个方法，所有方法被依次唤起，它可以使得委托对象所搭载的方法并不需要属于同一个类。
- 委托对象所搭载的所有方法必须有相同的原型和形式，也就是拥有相同的参数列表和返回值类型。
抽象工厂模式
从公司有两种数据库而使用方法有所不同来引入话题。
需求，创建一个数据访问的类，有新增用户、获取用户两个方法，用户类有ID和NAME两个字段。
版本1
用户对象，有id和name两个字段及对应的Get/Set方法。数据库对象，有存用户和获取用户的方法。
问题：数据库与user对象耦合度过高，需要抽离。
版本2
使用了工厂方法模式，数据库父类包含SQL和Access两个子类，实现父类的虚方法。增加User父类，子类SQLUser/AccessUser分别对应两个数据库，实现父类中增加、获取用户的虚方法。
问题：虽然这样降低了耦合度，但是当需要操作的类不止user一种的时候需要增加的部分就会非常多。
版本3
添加Department类，包含SQLDepartment和AccessDepartment两个子类，有对需要存储、获取的对象进行操作的方法。而且数据库子类有实现创建对应数据库类型的数据类型的虚方法。
问题：当要继续增加存储的数据类型的时候，需要改动数据库所有相关的类添加对应的创建方法。
版本4
静态变量存储目前选择的数据库，使用简单工厂来通过存储的静态变量选择对应的数据库实体来创建对象。这样就避免了在客户端选择具体的数据库子类实现了一部分的解耦目的（对工厂方法进行配置）。
问题：如果需要增加数据库就需要修改简单工厂方法中的switch。
版本5
通过反射来实例化具体的数据库子类，避免修改switch的问题。
- 抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
- 抽象工厂类中包含所有产品创建的抽象方法，而其子类则是具体的工厂了。通常是在运行时刻再创建一个具体的工厂类实例，然后由具体的工厂再创建具有特定实现的产品对象，也就是说为创建不同的产品对象，客户端应使用不同的具体工厂。
- 这样的最大好处在于易于交换产品系列，由于具体工厂类在整个应用中只需要在初始化的时候出现一次，这就使得改变一个应用的具体工厂变得非常容易，只需要改变具体工厂即可使用不同的产品配置。
- 但是也是有相应的缺点的，如果要增加一个产品的话，就需要改动大量相关的类。
- 使用反射可以避免在工厂模式中的if/switch判断，解除分支判断带来的耦合。
状态模式
根据一天工作精神状态的变化引入问题。
需求，输入时间、任务是否完成输出状态。
版本1
简单的使用if-else过程式函数实现。
版本2
将过程式函数抽成对象，工作对象有时间、任务完成标记属性，返回状态的函数。
问题：过多的判断导致LongMethod，拥有很多的判断分支代表它的责任过大无论是什么状态都是它负责改变。这个类违背了单一职责原则。
版本3
将各种时间段的工作拆分成子类，状态的判断在第一个子类开始，当不满足条件时将其转移到下一个子类，直到有子类符合对应的状态。比如，子类分为中午、下午、晚上，将时间交给中午类，中午类通过判断方法判断是否符合条件，不符合则调用下午类的判断方法...
- 面向对象设计其实就是希望做到代码责任分解。
- 状态模式是当一个对象的内在状态改变时允许改变其行为，这个对象看起来就像改变了其类。
- 状态模式主要解决的是当控制一个对象状态转换条件表达式过于复杂时的情况，把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的状态逻辑简化。
- 状态模式的好处是将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。就是将特定的状态相关的行为都放入一个对象中，由于所有与状态相关的代码都存在于某个子类中，所以通过定义新的子类可以很容易的增加新的状态和转换。这样做的目的就是为了消除庞大的条件分支语句，状态模式通过把各种状态转移逻辑分布到子类之间，减少互相之间的依赖（个人理解，就相当于将if-else或者switch语句通过面向对象的思想拆分开形成对应的子类，采用类似链表的方式进行判断的传递，从代码上看是避免了长方法的问题，但是从性能上来讲不推荐而且子类写起来真心麻烦）。
- 当一个对象的行为取决于它的状态，并且它必须运行时刻根据状态改变它的行为时，就可以考虑使用状态模式了。
适配器模式
通过姚明去NBA开始需要专人翻译交流沟通引入话题。姚明刚到NBA不会英文无法与他人交流，而短时间内不能让姚明学会英语，而他的队友也不能短时间学会中文，只能给姚明配备翻译。
需求，模拟教练给后卫、中锋、前锋分配进攻和防守任务。
版本1
球员抽象类有三个子类后卫、中锋、前锋，分别实现进攻和防守的方法。
问题：但是姚明（中锋）不懂英语，所以他的方法也不是父类的虚方法，并不能直接调用，而是需要一个适配器（翻译）。
版本2
教练向中锋分配任务时向翻译分配，然后翻译在向姚明转达。
- 适配器（Adapter）模式是将一个类的接口转换成客户希望的另外一个接口，Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
- 当系统的数据和行为都正确，但是接口不符的时候，应该考虑使用适配器，目的是是控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况。比如在需要对早期代码进行复用的时候很有价值。
- 在GOF的设计模式中，对适配器模式划分为两种类型，类适配器和对象适配器模式。
- 想要使用一个已经存在的类，但如果它的接口，和需求不同时，而且双方都不太容易修改的时候再使用适配器模式适配。两个类所做的事情相同或相似，但是具有不同的接口对象时要使用它。这样客户端只要调用同一接口就可以了。
备忘录模式
从打游戏存档引入问题。
需求，实现一个打BOSS前存档，打完BOSS可以恢复到存档时的状态的场景。
版本1
游戏角色类有生命、攻击、防御三种属性，首先初始化属性，然后打BOSS前保存属性，打BOSS后角色属性损耗，然后通过保存的角色对象恢复之前的状态。
问题：将游戏角色的实现细节都暴露给客户端，客户端的职责过大，而且当给角色增加新属性时就需要修改多处。
版本2
游戏角色类有保存状态、恢复状态及相关属性，角色状态备忘录类有角色的属性和对应set方法，角色状态管理类有备忘录的属性用来保存备忘录。这样就可以将具体细节封闭起来。
- 备忘录是在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可将该对象恢复到原先保存的状态。
- 就相当于将要保存的细节封装在备忘录中了，当哪一天需要更改保存的细节时也不会影响客户端。
- 备忘录模式比较适用于功能比较复杂的，但是需要维护或记录属性历史的类，或者需要保存的属性只是众多属性中的一小部分，这样发起人就可以通过管理者存储的备忘录对象恢复之前的状态。
组合模式
由文字处理一个字可以进行编辑一段话也可以进行编辑引入问题。
需求，写一个公司管理系统，总公司下属包括子公司和部门，子公司也包含相关部门。
版本1
公司Root类有增加、删除、显示、履行职责的虚方法和名称的属性，具体公司类实现相关方法和名称属性并添加一个保存其下级的数组，而部门类作为树叶节点不实现增加、删除方法。
组合模式这样就定义了包含人力资源部和财务部这些基本对象和分公司、办事处这些组合对象的类层次结构。基本对象可以被组合成更复杂的组合对象，而这个组合对象又可以被组合，这样不断的递归下去，这个代码中基本用到基本对象的地方都可以使用组合对象了。
用户是不用关心到底是处理一个叶节点还是处理一个组合部件，也就用不着为定义组合而写一些判断性语句了。
- 组合模式是将对象组合成树形结构以表示部分-整体的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性。
- 当发现需求中是体现部分与整体层次的结构时，以及你希望用户可以忽略组合对象与单个对象的不同，统一地使用组合结构中的所有对象时，就应该考虑使用组合模式了。
- 简单的来说，组合模式可以让客户可以一致的使用组合结构和单个对象。
迭代器模式
迭代器模式现在基本各种高级语言中都对其进行了封装，如for-in、enumerate等。
- 迭代器模式是提供一种方法顺序访问一个聚合对象中各种元素，而又不暴露该对象的内部表示。
- 当你需要访问一个聚合对象，而且不管这些对象是什么都需要遍历的时候，就应该考虑迭代器模式。需要对聚合有多重遍历模式时，可以考虑迭代器模式。也就是说，为便利不同的聚集结构提供如开始、下一个、是否结束、当前哪一项等统一的接口。
单例模式
（太熟了哈哈哈😂）
- 单例（Singleton）模式可以保证一个类仅有一个实例，并提供一个访问它的全局访问点。
- 通常我们可以让一个全局变量使得一个对象被访问，但不能防止你实例化多个对象，一个最好的办法就是，让类自身负责保存他的唯一实例，这个类可以保证没有其他实例可以被创建，并且可以提供一个访问该实例的方法。
- 单例模式因为单例类封装它的唯一实例，这样它可以严格地控制客户怎样访问它和何时访问它，简单地说就是对唯一实例的受控访问。
- 多线程的单例，就是在多线程的程序中，多个线程同时访问 singleton类调用单例创建方法是可能会创建多个实例的。所以需要加锁。
桥接模式
通过手机品牌和手机软件的关系引入问题。
需求，写一个有N个品牌的手机和M种APP，并表示之间的关系。（实际上，手机与APP并没有直接的联系，真实的情况应该是手机对应操作系统，操作系统再对应具体的APP）
版本1
手机抽象类有N个具体子类，手机具体子类有M个软件子类。
问题：增加、修改会变得很复杂，而且手机和APP并不应该是父子类关系。
版本2
手机实体子类中有软件属性。
- 桥接模式（Bridge）将抽象部分与它的实现部分分离，使它们都可以独立地变化。由于实现方式有多种，桥接模式的核心意图就是把这些实现独立出来，让他们各自变化，这就使得每种实现的变化不会影响其他实现，从而达到应对变化的目的。
- 对象的继承关系在编译时就已经确定好了，所以无法在运行时改变从父类继承的实现。子类的实现与它父类有非常紧密的依赖关系，以至于在父类实现中的任何变化必然会导致子类发生变化。当你需要复用子类时，如果继承下来的实现不适合解决新的问题，则父类必须重写或被其他更适合的类替换，这种依赖关系限制了灵活性并最终限制了复用性。
- 合成/聚合复用原则（CARP），尽量使用合成/聚合，尽量不要使用继承。合成和聚合都是关联的特殊种类，聚合表示一种弱的拥有关系，体现的是A对象可以包含B对象，但B对象不是A毒想的一部分；合成则是一种强的拥有关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。
- 合成/聚合复用原则的好处是优先使用对象的合成/聚合将有助于你保持每个类被封装，并被集中在单个任务上，这样类和类继承层次会保持较小规模，并不太可能增长成为不可控制的庞然大物。
命令模式
从路边烧烤摊混乱无序和烧烤店井然有序引入问题。
需求，模仿路边烧烤摊和烧烤店的模式写出对应的代码。
版本1
路边烧烤摊的紧耦合
阿里巴巴有烤羊肉和烤鸡翅两个方法，客户端相当于顾客，此时顾客与阿里巴巴紧耦合，这样虽然简单，但是极为僵化，有很多隐患比如任务的调度混乱无序、难以修改等。
版本2
烧烤店的松耦合
客户端相当于顾客，向服务员类发出命令，服务员有设置命令和通知执行两个方法，命令抽象类包含烤肉和烤鸡翅两个具体子类，烤肉者接到命令执行相关操作。
- 命令模式是将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或者记录日志，以及支持可撤销的操作；将请求操作的对象和执行操作的对象分开。
- 优点是可以比较容易地设计一个命令队列；在需要的情况下，可以较容易地将命令计入日志；在允许接受请求的一方可以决定是否否决请求；可以比较容易地实现对请求的撤销和重做；由于加入新的具体命令类不影响其他的类，因此增加新的具体命令类很容易。
职责链模式
由一个问题管理者无权解决层层上报引入问题。
感觉好像之前的状态模式，将if-else分拆成子类的链条（链表？）。
- 职责链模式是使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系，将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它位置。
- 请求者并不知道是当中的哪一个对象最终处理这个请求，这样的系统的更改可以在不影响客户端的情况下动态地重新组织和分配责任。接收者和发送者都没有对方的明确信息，而且链中的对象自己不知道链的结构，结果就是职责链可以简化对象的相互连接，他们仅需保持一个指向其后继者的引用，而不需保持它所有的候选接受者的引用，这样就大大的降低了耦合度。
中介者模式
其实就是迪米特法则的体现。
- 中介者模式是用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使耦合松散，并且可以独立地改变它们之间的交互。
- 中介者模式很容易在系统中应用，但也很容易在系统中误用。当系统中出现了多对多交互复杂的对象群时，先不要急于使用中介者模式，而要先反思你的系统在设计上是不是合理。
- 中介者的出现减少了各个对象之间的耦合，由于把对象如何协作进行了抽象，将中介者作为一个独立的概念并将其封装在一个对象中，这样关注点就从对象各自本身的行为转移到它们之间的交互上来，也就是站在更宏观的角度去看待系统（个人理解，中介者的集中化既是将对象之间交互的复杂性转移到中介者上）。
- 中介者模式一般应用于一组对象以定义良好但是复杂的方式进行通信的场合（比如计算器控件中的button和label的关系），以及想要制定一个分布在多个类中的行为，而又不想生成太多子类的场合。
享元模式
由多个项目共享代码引入问题。
需求，做N个同类型但表现形式不同的网站。
版本1
N个网站单独实现。
问题：网站内部其实很多逻辑都是相同相似的，而且网站之间也可以共享服务资源，比如存储、计算、网络带宽资源等。
版本2
类似于调用私有库，网站类在需要的情况下向网站工厂请求所需的功能对象，这样就做到了模块共享。
- 享元模式是运用共享技术有效地支持大量细粒度的对象。
- 享元模式可以避免大量非常相似类的开销，在程序设计中，有时需要生成大量细粒度的类实例来表示数据。如果能发现这些实例除了几个参数外基本上都是相同的，有时就能够大幅度地减少需要实例化类的数量。如果能把那些参数移到类实例的外面，在方法调用时将它们传递进来，就可以通过共享大幅度地减少单个实例的数目。
- 如果一个应用程序使用了大量的对象，而大量的对象造成了很大的存储开销（资源浪费）时就应该使用。但是反过来说，享元模式需要维护一个记录了系统已有的所有享元的列表，本身就耗费资源，而且这使得系统逻辑更加复杂，所以应该在有足够多的对象实例可以共享的时候才值得使用享元模式。
解释器模式
解释器模式的实际运用如正则语法、XML、JSON等等。
- 解释器模式，给定一个语言，定义它的文法中的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
- 如果特定类型的问题发生的频率足够高，那么可能有值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。
- 当有一个语言需要解释执行，并且你可将该语言中的句子表示为一个抽象语法树时，可使用解释器模式。
访问者模式
- 访问者模式表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
- 访问者模式适用于数据结构相对稳定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱，使得操作集合可以相对自由地演化。
- 访问者模式的目的是要把处理从数据结构分离出来，如果系统有比较稳定的数据结构又有易于变化的算法的话，使用访问者模式就是比较合适的。
- 访问者模式的优点就是增加新的操作很容易，因为增加新的操作就意味着增加一个新的访问者，访问者模式将有关的行为集中到一个访问者对象中。
