这段时间在学习设计模式，对于每个模式的UML图感觉不好理解，究其原因，应该是我们对类与类之间的关系不是很清楚，所以，我们首先，需要弄懂类之间的关系才能看懂类图。
继承（Inheritance）
继承用冒号":"表示,C#中不支持多重继承,即一个子类只能继承一个父类,但一个类可以实现多个接口,接口之间用逗号","隔开,如果一个类继承一个父类同时,实现一个或多个接口,一般父类名写前面,接口写后面之间用逗号“,”隔开。
继承的条件？？
如果子类继承父类,那么子类具有父类非private的属性和方法；子类具有自己的特殊属性和方法。
在下图中，StudentA类继承TestPaper类，并对TestPaper类中虚方法进行了重写。
这里用了一个重要的设计模式模板方法模式，我觉得这个模式比较好记住，因为它只包含一种关系---------------继承。
由于每个对象(学生)都是做一样的试卷(父类)，我们可以把(学生)对象具有的一些属性、方法抽象出来，作为一个父类或抽象类,由学生类来继承父类，减少了每个学生类中重复的代码，在学生对象中只有关于自己特定行为的代码。
在我们做项目时，如果很多对象具有类似的属性或方法，我们就可以考虑用模板方法增加一个抽象类把相同的代码抽象出来，通过继承，减少子类中重复的代码和复杂度。
关联（Associate）
关联表示两个类之间的关系，一个类可能需要了解另一个类的内部成员或者方法，这种关系就叫关联。关联可以分为单向关联和双向关联。
我们以外观模式来分析，如下图中，外观原理图及C#代码，Facade外观类，有四个子类SubSystemOne、 SubSystemTwo 、SubSystemThree、 SubSystemFour，外界通过Facade类来访问子系统内部，就必须让Facade类了解每个子系统对象，在关联关系中关联类以被关联类作为对象变量，这样关联类就可以了解被关联类内部成员或方法。
在生活中股民通过基金会来买股票，就是一种典型的外观模式范例，股民不必直接操纵股票对象，股民甚至可以不懂股票。
外观模式定义（Facade）：为子系统中的一组接口提供了一个一致界面，此模式定义了一个高层接口，这个接口使得子系统更加容易使用。
那么什么时候使用外观模式呢？
- 在设计初期阶段，应该有意识的将两个层分离，在数据访问层、业务逻辑层、表示层，每个层之间使用Façade,可以为复杂的子系统提供一个简单接口，使得耦合大大降低。
- 在开发阶段，我们往往会不断的重构而使系统变的越来越复杂，增加Facade，可以减少复杂度。
- 在维护一个遗留的大型系统时，可能这个系统已经非常复杂，难以维护和扩展，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂工作。
