目录
UML
类（Class）：使用三层矩形框表示。 第一层显示类的名称，如果是抽象类，则就用斜体显示。 第二层是字段和属性。 第三层是类的方法。 注意前面的符号，‘+’表示public，‘-’表示private，‘#’表示protected。
接口：使用两层矩形框表示，与类图的区别主要是顶端有<
继承类（extends）：用空心三角形+实线来表示。
实现接口（implements）：用空心三角形+虚线来表示
关联（Association）：用实线箭头来表示，例如：燕子与气候
依赖（Dependency）：用虚线箭头来表示，例如：动物与氧气
聚合（Aggregation）：用空心的菱形+实线箭头来表示 聚合：表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分，例如：公司和员工
组合（Composition）：用实心的菱形+实线箭头来表示 组合：部分和整体的关系，并且生命周期是相同的。例如：人与手
关系强弱排序：组合>聚合>关联>依赖
基数：连线两端的数字表明这一端的类可以有几个实例，比如：一个鸟应该有两只翅膀。如果一个类可能有无数个实例，则就用‘n’来表示。关联、聚合、组合是有基数的
策略模式
策略模式可以用来封装算法，实践中，发现可以用它来封装几乎任何类型的规则，只要在分析过程中听到需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性。
但在基本的策略模式中，选择所用具体实现的职责由客户端对象承担，并转给策略模式的context对象。
而策略模式与简单工厂模式结合后，选择具体实现的职责也可以由Context来承担，这就最大化减轻了客户端的职责
装饰器模式
装饰器模式是为已有功能动态地添加更多功能的一种方式。
当系统需要新功能的时候，是向旧的类中添加新的代码。这些新加的代码通常装饰了原有类的核心职责或主要行为， 它们在主类中加入了新的字段，新的方法和新的逻辑。 从而增加了主类的复杂度。而这些新加的东西仅仅是为了满足一些只在某些特定情况下才会执行的特殊行为的需要。
装饰器模式提供了一个很好的解决方案，把每个要装饰的功能放在单独的类中，并让这个类包装它所要装饰的对象。因此，当需要执行特殊行为时，客户代码就可以在运行时根据需要 有选择地、按顺序地使用装饰功能包装对象。
优点：把类中的装饰功能从类中搬出去，简化原有的类，有效的把类的核心职责和装饰功能区分了。而且可以去除相关类中重复的装饰逻辑
单一职责原则
如果一个类承担的职责过多，就等于把这些职责偶合在一起，一个职责的变化可能会削弱或者一直这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏
开放-封闭原则
对于扩展是开放的，对于更改是封闭的，在最初编写代码时，假设变化不会发生，当变化发生时，就需要思考，创建抽象来隔离以后发生的同类变化。
面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有代码。
开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，对于程序组每个部分都可以地进行抽象同样不是一个好主意，拒绝不成熟的抽象和抽象本身一样重要。
依赖倒转原则
抽象不应该依赖细节，细节应该依赖于抽象。 简而言之，就是要针对接口编程，不要对实现编程。依赖倒转其实就是谁也不要依靠谁，除了约定的接口，大家都可以灵活自如。
