单一职责原则，就一个类而言，有且仅有一个引起它变化的原因

每个类都必须要有一个唯一的明确的职责，只做一件事，并且做好

仅仅当某种情况发生时（通常与此类职责相关）才需要修改这个类的代码
原则解析
类名和方法名应该与其所承担的职责相符

一个类与其他类之间的依赖性越少越好

使用“方法抽取”重构方式，将事件响应方法的代码抽取为独立的方法
SRP单一职责原则 违背这一原则的典型表现
将UI代码与功能代码混在一起， 分析类中的所有方法，将于数据处理、业务逻辑相关的代码抽取为独立的类
一个窗体搞定一切
将可以复用的类，转换为可复用的组件
应用关键：SOC
分离关注点，让关注点彼此独立 DAL：将数据存取代码抽取为独立的类xxxRepository，并移到独立的类库项目中

BLL：业务逻辑层中的类xxxService，通过DAL层中的类访问数据库，并通过少量公用的外观类向上层
分层设计
开放功能

UI:表示层中的类，通过业务逻辑层的外观类调用业务逻辑功能，不直接访问数据库

一个软件开发完毕后，当需要扩展功能时，不要修改原来的代码（封闭），而应该派生出新类
（开放）
OCP开闭原则
仅当原程序有BUG时，才对程序进行修改，原因是在修改代码时，不引入新Bug

面向对象设计
SOLID设计原则 当从一个类派生出子类时，所有使用其基类的代码，在接收一个子类对象时，都应该能正常的工作，而不会出
错或崩溃

应用实例：插件系统（浏览器插件，插件不应该导致宿主程序崩溃）
LSP-Liskov替换原则 在具体实现上，要求应该针对“接口”或“抽象基类”进行编程，充分利用面向对象的多态
性，让实现同一接口或抽象基类的子对象可以相互取代而不影响到程序的其他部分
应用指南
与实现具体功能的特定类型相比，封装与抽象出来的“接口”与“抽象基类”具有更强的稳
定性，因此，基于它开发出来的上层应用也会具有稳定性。

要避免弄出一个“什么都有”的大接口，而应该将其定义的功能从逻辑上进行分组，将切分为多个
高层模块
小的接口
ISP接口隔离原则
这样一来，各个类就可以依据实际情况选择实现不同的接口，而在不同的场景下，实现了多个接口的
对象又可以向外界展示出不同的特性
抽象基类或接口

一个较大的系统，对象间的依赖关系导致出现复杂的关联网，一个类的修改，必须复查
所有依赖于它的代码，否则可能引发BUG
下层模块
高层模块不应该依赖于底层模块，两者都应该依赖于抽象
抽象不应该依赖于细节，细节应该依赖于抽象
DIP依赖倒置原则
一个类不要依赖于具体的类，应该依赖于抽象的类或接口 进一步弱化耦合性，类本身不直接实例化它所依赖类的对象，而是由外界动态地将其注入

与DIP原则密切相关的另一个概念是IoC控制反转，有一个框架比如Ninject、SimpleInjector更是直接基于DIP与IoC这一想
法构建出来的