模式是在某一个背景下的某一个问题的解决方案。
设计模式在很大程度上是为了解决软件的可复用性，而根据大量工程实践总结出来的软件体系结构，隐含包括了软件工程的面向对象思想：封装、继承、多态。
为什么需要设计模式：设计模式（Design Pattern ）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，
使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码的可靠性。
设计模式一般有如下几个基本要素：模式名称、问题、目的、解决方案、效果、实例代码和相关的设计模式，关键因素包括以下四个方面：
（1）模式名称（Pattern name） （2）问题（Problem） （3）解决方案（Solution） （4）效果（Consequences）
面向对象方法中把一切都看成对象。对象是功能抽象和数据抽象的统一，对求解问题本身建模
面向对象的常用名词： 面向对象分析OOA、面向对象设计OOD 、面向对象编程OOP、面向对象编程 OOP、面向对象测试OOT
面向对象的基本原则：（1）抽象Abstraction（2）封装Encapsulation（3）模块Modularity（4）层次化Hierarchy
面向对象的几个基本概念： 对象Object、类Class 、接口Interface、多态Polymorphism 、继承Inheritance、类（及对象）之间的关系
类（及对象）之间的关系：
（1）静态联系————关联association
关联是类与类之间的连接，使一个类知道另一个类的属性和方法。是类与类之间最常用的一类关系，它是一种结构化关系，用于表示一类对象和另一类对象之间有联系。
在UML类图中，用实线连接有关联对象所对应的类，在使用Java、C#和C++等编程语言表示关联关系时，通常将一个类的对象作为另一个类的属性。
包括三种关联关系：双向关联、单向关联、自关联
双向关联类图：
单向关联类图：
自关联类图：
（2）构成关系————聚合aggregation（整体-部分）
聚合关系是关联关系的一种，是强的关联关系，是整体和个体之间的关系。表示一个整体与部分的关系。
该整体类与成员类之间形成聚合关系，成员类是整体类的一部分。
如果不能确定一个关系是聚合关系，可以将它们设为关联关系。
在UML中聚合关系用带空心菱形的直线表示。
组合关系是关联关系中的一种，比聚合关系强，如果不能确定一个关系是不是组合关系，可将其设置为聚合关系，甚至关联关系。
也表示类之间整体与部分的关系，但是组合关系中的部分和整体具有相同的生命周期，一旦整体对象不存在，部分对象也将不存在，部分对象与整体对象之间具有同生共死的关系。
在UML中组合关系用带实心菱形的直线表示。
分类关系————泛化generalization（一般-特殊）
泛化关系（Generalization）也就是继承关系，泛化关系用于描述父类和子类之间的关系，父类又称作基类或超类，子类又称作派生类。
在UML中泛化关系用带空心的三角形的直线来表示
JAVA语言中使用extends关键字、在C++/C#使用冒号“：”来实现。
接口与实现关系，接口之间也可以有与类之间关系类似的继承关系与依赖关系，但是接口与类之间还存在一种实现关系（Realization），在这种关系中，类实现了借口，类中的操作实现了接口中所申明的操作。在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示。
使用关系————依赖Dependency（行为依赖）
依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时的使用依赖关系。
大多数情况，依赖关系体现在某个类的方法使用另一个类的对象作为参数。
在UML中，依赖关系用带箭头的虚线表示
一个好的软件系统需要包含三个特性：扩展性（Extensibility）、灵活性（Flexibility）、可插入性（Pluggability）
软件设计的七大原则：
（1）单一职责原则（SRP）
就一个类而言，应该只有一个导致其变化的原因。
类的职责主要包括两个方面的：数据职责和行为职责，数据职责通过其属性来体现，而行为职责通过其方法来表现。
单一职责原则 是实现高内聚、低耦合的指导方针。
对应的设计模式：Facade 、Proxy
（2）开-闭原则（OCP）
设计一个模块时，应当使该模块在不被修改的前提下被扩展，即可在不必修改源代码的情况下改变该模块的的行为。
抽象化是开闭原则的关键，开闭原则还可以通过一个更加具体的“对可变性封装原则”来描述，对可变性封装原则要求找到系统的可变因素将其封装起来。
一种可变性不应该散落在代码的很多角落里，而应该被封装在一个对象里。（继承可被看作封装变化的方法）
一种可变性补英语另一种可变性混在一起。（继承的层次不应太多了）
对应的设计模式：Strategy 、Simple Factory 、Factory Method、Abstract Factory、Builder、Bridge、Facade、Mediator、
(3)Liskov替换原则（LSP）
一个软件实体如果使用的是一个基类的话，一定适用与其子类，而且根本不能察觉出基类对象和子类对象的去区别
即：子类型（Subtype）必须能够替换他们的基类型(Basetype).
在软件设计中如果能够使用基类对象，那么一定能够使用其子类对象。
在程序中尽量使用基类类型来对对象进行定义，而在运行时在确定其子类类型，用子类对象来替换父类对象。
如果有一个由继承关系形成的等级结构的话，那么在等级结构的树图上面的所有树叶节点都应该是具体类，
而所有的树枝节点都应该是抽象类或接口。
对应的设计模式：Strategy 、Composite、Proxy
（4）
GOF的设计模式主要包括：二十三种设计模式总结