打完游戏发现考试内容一点没看，紧急抢救，精神状态不甚正常，慎读。
例子有的不是很好，为了考试的时候抄个UML图方便罢了。
0. UML图
1. 关联关系
类A用到了类B，A->B
类A用到了类B，类B也用到了类A，A—B
2. 组合关系：缺一不可
3. 聚合关系：零散聚在一起
4. 依赖关系
5. 继承
6. 实现接口
2. 设计模式
1. 简单工厂模式
要啥get啥，挺简单的。
2. 抽象工厂模式
好几组特征组合在一起，比较抽象，实际上也很麻烦。
3. 建造者模式
一个东西由好几个部分组成，一个个传参太麻烦了，不如新建一个build类，调用相应方法，最后build一下，就得到了。
4. 原型模式
PPT：孙悟空拔毛变小猴。笑死我了
我初始化我自己，我生产一个我自己出来。跟批量印刷要填的表格一样。
5. 单例模式
只能有一个实例，实例作为全局变量，大家都可以调用它。
有个很高端的例子：
某软件公司承接了一个服务器负载均衡(Load Balance)软件的开发工作，该软件运行在一台负载均衡服务器上，可以将并发访问和数据流量分发到服务器集群中的多台设备上进行并发处理，提高了系统的整体处理能力，缩短了响应时间。由于集群中的服务器需要动态删减，且客户端请求需要统一分发，因此需要确保负载均衡器的唯一性，只能有一个负载均衡器来负责服务器的管理和请求的分发，否则将会带来服务器状态的不一致以及请求分配冲突等问题。如何确保负载均衡器的唯一性是该软件成功的关键，试使用单例模式设计服务器负载均衡器。
6. 适配器模式
之前写过一个类似的功能，但现在没法直接调用，写个适配器把两个接口不同的类捏在一起吧。
关于为什么不直接创建对应的类：将目标类和适配者类解耦，通过引入一个适配器类来重用现有的适配者类，无须修改原有结构。
某公司欲开发一款儿童玩具汽车，为了更好地吸引小朋友的注意力，该玩具汽车在移动过程中伴随着灯光闪烁和声音提示。在该公司以往的产品中已经实现了控制灯光闪烁（例如警灯闪烁）和声音提示（例如警笛音效）的程序，为了重用先前的代码并且使得汽车控制软件具有更好的灵活性和扩展性，现使用适配器模式设计该玩具汽车控制软件。
缺省适配器模式：不想实现原来接口的全部方法，所以加个适配器，子类有选择性地继承下去。
7. 桥接模式
这图真的很好笑我得把它放上来
分析：
蜡笔：颜色和型号两个不同的变化维度（即两个不同的变化原因）耦合在一起，无论是对颜色进行扩展还是对型号进行扩展都势必会影响另一个维度
毛笔：颜色和型号实现了分离，增加新的颜色或者型号对另一方没有任何影响
桥接模式主要实现毛笔，换一种颜色，重新把某个特征set一下，然后接着用，而不是重新建立一个类。
8. 组合模式
啥玩意，有点难懂，不会要考吧
主要针对树形结构，且对叶子节点和非叶子节点执行同一操作应使用不同处理方式。所有结点继承一个接口，给每个结点继承接口的时候实现不同处理方式。
计算后缀表达式的值
每个结点都有calculate操作，对叶子节点是取出值，符号是计算，但写的时候只要调用calculate就好了，这个类的calculate方法提前已经设置好了。
某软件公司欲开发一个杀毒(Antivirus)软件，该软件既可以对某个文件夹(Folder)杀毒，也可以对某个指定的文件(File)进行杀毒。该杀毒软件还可以根据各类文件的特点，为不同类型的文件提供不同的杀毒方式，例如图像文件(ImageFile)和文本文件(TextFile)的杀毒方式就有所差异。现使用组合模式来设计该杀毒软件的整体框架。
9. 装饰模式
这个简单，给组件加黑框，给文字加下划线，反正把什么东西扔进去就会处理好换回来，跟流水线一样。
某软件公司基于面向对象技术开发了一套图形界面构件库——VisualComponent，该构件库提供了大量基本构件，如窗体、文本框、列表框等，由于在使用该构件库时，用户经常要求定制一些特殊的显示效果，如带滚动条的窗体、带黑色边框的文本框、既带滚动条又带黑色边框的列表框等等，因此经常需要对该构件库进行扩展以增强其功能。 现使用装饰模式来设计该图形界面构件库。
10. 外观模式
这图挺形象的，看完就懂了：
某软件公司要开发一个可应用于多个软件的文件加密模块，该模块可以对文件中的数据进行加密并将加密之后的数据存储在一个新文件中，具体的流程包括3个部分，分别是读取源文件、加密、保存加密之后的文件，其中，读取文件和保存文件使用流来实现，加密操作通过求模运算实现。这3个操作相对独立，为了实现代码的独立重用，让设计更符合单一职责原则，这3个操作的业务代码封装在3个不同的类中。 现使用外观模式设计该文件加密模块。
11. 享元模式
这图也很灵魂：
面向对象不可避免要建立很多类，创建很多实例。但有些实例可能就是为了某个服务而创建，反复创建浪费内存。不如把它们放到一个池子里，直接拿出来用。和单例模式有点像，可能是把很多单例模式放在一起吧。
某软件公司要开发一个围棋软件。该软件公司开发人员通过对围棋软件进行分析发现，在图中，围棋棋盘中包含大量的黑子和白子，它们的形状、大小都一模一样，只是出现的位置不同而已。如果将每一个棋子都作为一个独立的对象存储在内存中，将导致该围棋软件在运行时所需内存空间较大，如何降低运行代价、提高系统性能是需要解决的一个问题。为了解决该问题，现使用享元模式来设计该围棋软件的棋子对象。
12. 代理模式
开代理，懂的都懂，我出于某种原因不能自己request，发送请求，让别人帮我request
犹记上这课时大家发出了会心的笑声。
也是创建了一个类去访问别的类，但重点在于请求与访问。
13. 职责链模式
层层审批，创建一个对象，给它设置处理方法和要传递给的下一个对象。每个对象只有两个选择：处理和传递，不能既处理又传递。说实话我觉得这玩意不会考。
14. 命令模式
将一个请求封装为一个对象，从而让你可以用不同的请求对客户进行参数化，对请求排队或者记录请求日志，以及支持可撤销的操作。
让干啥就干啥，和简单工厂有点像，但重点是do而非get
为了用户使用方便，某系统提供了一系列功能键，用户可以自定义功能键的功能，例如功能键FunctionButton可以用于退出系统（由SystemExitClass类来实现），也可以用于显示帮助文档（由DisplayHelpClass类来实现）。 用户可以通过修改配置文件来改变功能键的用途，现使用命令模式来设计该系统，使得功能键类与功能类之间解耦，可为同一个功能键设置不同的功能。
15. 解释器模式
根据一些规则处理一些东西，就像编译器干的活。我错了，它就是个抽象编译器。
解释器模式包含以下4个角色：
AbstractExpression（抽象表达式）
TerminalExpression（终结符表达式）
NonterminalExpression（非终结符表达式）
Context（环境类）
和那啥玩意，组合模式，有点像。不过组合模式指定场景是树上，这个指定场景是解释某种语句。
16. 迭代器模式
新建一个类去遍历某一种类。这个模式有点具体，毕竟很多库都有迭代器。
17. 中介者模式
定义一个对象来封装一系列对象的交互。就像用QQ聊天。
操作内部有大量互动，于是把互动剥离出来，很常见的就是UI和逻辑分离。
某软件公司要开发一套CRM系统，其中包含一个客户信息管理模块。界面组件之间存在较为复杂的交互关系：如果删除一个客户，将从客户列表(List)中删掉对应的项，客户选择组合框(ComboBox)中的客户名称也将减少一个；如果增加一个客户信息，则客户列表中将增加一个客户，且组合框中也将增加一项。 为了更好地处理界面组件之间的交互，现使用中介者模式设计该系统。
18. 备忘录模式
某软件公司要使用Java语言开发一款可以运行在Android平台的触摸式中国象棋软件，由于考虑到有些用户是“菜鸟”，经常不小心走错棋；还有些用户因为不习惯使用手指在手机屏幕上拖动棋子，常常出现操作失误，因此该中国象棋软件要提供“悔棋”功能，在用户走错棋或操作失误后可恢复到前一个步骤。为了实现“悔棋”功能，现使用备忘录模式来设计该中国象棋软件。
这图有点难懂。MementoCaretaker管理状态，上面那个类是状态。每走一步更新一下，后悔的时候把之前状态拿出来。
19. 观察者模式
很多东西观察一个，它一变，观察者都得到通知。深入理解建议学习rxjs。
在某多人联机对战游戏中，多个玩家可以加入同一战队组成联盟，当战队中的某一成员受到敌人攻击时将给所有其他盟友发送通知，盟友收到通知后将做出响应。 现使用观察者模式设计并实现该过程，以实现战队成员之间的联动。
20. 状态模式
内部状态改变的时候改变操作策略，就是重新给它状态那设置一个类，类自带处理方法，避免一堆if else。
21. 策略模式
定义一系列算法，将每一个算法封装起来，并让它们可以相互替换。策略模式让算法可以独立于使用它的客户变化。和上面没啥区别，把状态换成策略罢了，从由内部决定换成外部设置。
22. 模板方法模式
定义一个操作中算法的框架，而将一些步骤延迟到子类中。模板方法模式使得子类不改变一个算法的结构即可重定义该算法的某些特定步骤。说人话就是有一个大致流程，流程的每一步有很多替换项。
23. 访问者模式
把一些元素组合起来，我当你的参数，你当我的参数，展现出不同的操作。
总算完了。我干嘛打那把游戏呢。
瞎叨叨两句：总感觉难理解的设计方法都是特意弄出来弥补面向对象固有缺陷的。有时候写代码也感觉很尴尬，干嘛非把这玩意弄成一个类呢。有几个模式很像，可以细分，但没必要，知道是那么个东西即可。
清华大学出版社这套PPT真的很典，收藏了。
