一、当你的项目发现有如下问题之一时，就需要考虑重构代码，可能会有某种模式适合。
1、代码无法进行单元测试。
2、需求的变动总是导致代码的变动。
3、有重复代码的存在。
4、继承层次过多。
5、隐藏的依赖过多。
二、UML表示法
1、UML类图
"+"代表Public，“#”代表protected，“-”代表private，即
代表变量 public string Prol; 
代表方法 public void Method1（）{ }
2、UML序列图
序列图描述系统的动态交互过程，在序列图中，垂直虚线叫做“生命线”，代表一个对象的生存周期，每一个箭头代表一个调用，
在生命线上若有空心条，代表调用的激活周期，成为激活条。
三、系统的可维护性包括如下几个方面：
1、可扩展性：有了新的需求，新的性能可以容易地添加到系统中，并且不影响现有的性能，也不会带来新的缺陷。
2、可修改性：系统某一部分的代码需要修改时不会破坏系统现有的结构，也不会影响到其他部分。
3、可替换性：可以将系统中的某些类替换为相同接口的其他类，并且系统不受影响。
四、“开-闭”原则：
指软件实体应当对扩展开放，对修改关闭，即软件实体应该在不修改的前提下扩展。
五、封装变化
程序中任何可能发生变化的部分都可以封装为对象，包括命令、事件、属性、算法、形态等。
封装变化是实现“开-闭”原则的重要手段，也是在设计中发现对象的重要途径。
因此在分析需求时，一定要注意什么是变的，什么是可能发生变化的，以及这些可能的变化会对封装带来的影响。
六、面向接口编程的优势：
1、降低程序各部分之间的耦合性，使程序模块互换成为可能。这样客户无需知道自己使用的对象类型，只要对象有客户所期望的接口即可。
并且对象也不需要知道对象是如何实现的，只要知道定义接口的抽象类。
2、使软件各部分便于单元测试，通过编制与接口一致的模拟类（Mock），可以很容易地实现软件各部分的单元测试。从而提高软件的可靠性，降低错误率。
3、易于实现软件模块的互换，软件升级时可以只部署发生变化的部分，而不会影响其他部分。
七、继承的缺点
1、继承在编译时定义，无法在运行时改变，无法在运行时动态的选择继承或者不继承某一个类。
2、继承对子类暴露了父类的实现细节，从而破坏了封装性。
3、子类和父类耦合性非常强，一旦父类发生变化，必然导致子类也发生变化。
八、设计模式解决的问题
| 问题 | 设计模式 | 描述 |
| 通过显示指定类创建对象 | 抽象工厂模式、工厂方法模式、原型模式 | 在实例化时，间接创建对象 |
| 紧耦合 | 抽象工厂模式、命令模式、外观模式、中介者模式、观察者模式和职责链模式等 | 类之间需松耦合 |
| 通过生成子类扩展功能 | 桥接模式、职责链模式、组合模式、装饰模式、观察者模式、策略模式等 |
通过生成子类来扩展功能会产生很多问题，如引起子类数量大量增加和类层次的增加。 通过对象组合技术实现功能扩展是更好的选择 |
| 对对象表示或实现的依赖 | 抽象工厂模式、桥接模式、备忘录模式、代理模式等 | 对客户隐藏对象如何表示、保存、定位或实现等。 |
| 不能方便地修改类 | 适配器模式、装饰模式、访问者模式 | |
| 对算法的依赖 | 生成器模式、迭代器模式、策略模式、模板模式、访问者模式 | 算法实现的目的是不变的，但算法本身却不是一成不变的 |
| 对软硬件环境的依赖 | 抽象工厂模式、桥接模式等 |
九、设计模式所用到的接口和类（.NET）
| 接口/类 | 设计模式 | 描述 |
| ICloneable | 原型模式 | 这个接口支持克隆，即创建与当前实例相同的实例，方法为Clone（） |
| IEnumerable/IEnumerator | 迭代子模式 | 公开枚举数支持在集合上进行简单迭代 |
| MenuCommand类/IMenuCommandService | 命令模式 | 提供了对自定义组件行为的基类 |
| CollectionBase类 | 组合模式、命令模式、享元模式、观察者模式 | CollectionBase是强制类型集合的基类，通过实现这个类可以实现强制类型 |
| IDataAdapter | 适配器模式 |
IDataAdapter定义了数据库与DataSet之间的桥接器， 针对不同的数据源的DataAdapter瞌睡实现程序与数据源的松耦合 |
十、设计模式的分类
1、创建型模式
通过一个专门实例化的类来获得具体的对象，通常我们将称这个类为“工厂”，将与实例化相关的模式称为“创建型模式”。