OOP SOLID原则

  OOP SOLID原则如下：

---

S = 单一职责原则 Single Responsibility Principle

O = 开放闭合原则 Opened Closed Principle 

L = Liscov替换原则 Liscov Substitution Principle

I = 接口隔离原则 Interface Segregation Principle

D = 依赖倒置原则 Dependency Inversion Principle

 

单一职责原则

---

单一是指模块、类、方法的职责单一。当对这些软件对象修改时，不会因为修改某一个方面的功能而影响另一方面。

模块：比如MVC，M-领域模型（负责数据的存储，业务的处理）、 V-视图（负责数据的显示）、C-控制器（负责请求到方法的映射）

类：比如我们常用的ado.net，包含Connection、Command等对象。Connection只负责连接的管理，Command只负责查询命令管理。

方法：一个方法只做一个动作。

　　　如何保证单一职责？我觉的取决于我们的抽象能力，建立合适的领域模型。比较直观的方式是控制类和方法的大小，应用设计模式，将代码分配到合适的地方。比如使用创建者模式，将负责的对象创建过程从调用方解耦到builder类。充血模型中，实体包含他自己相关   　的属性和功能，比如user实体，只应负责user相关数据的管理，而不要去管理role、dept等实体，这是抽象的分界，也不要去管user的持久化，这是user仓储对象应做的事。

开放闭合原则

---

闭合耦合处的修改，开放具体实现的扩展。 

耦合处：接口、抽象类、或者间接类，以这些进行交互，因为这部分抽象有共性，比较稳定。

找出变化，封装变化，让变化之外的结构固定，即这部分代码是不应该修改的，为抽象增加一个新的具体实现来进行功能扩展。例如策略模式。

接口隔离原则

---

接口需小而精炼。

依赖倒置

---

调用模块和被调用模块不应直接交互，被调用模块暴露出的应该是抽象（接口、抽象类），而非实际的类。

所谓依赖即调用，一般的调用方式有下面几种： 
1. 构造函数参数；
2. 方法参数；
3. 类成员引用；

在这些地方的引用，尽量不要直接使用具体的类型（派生类和接口实现类），而要使用接口或抽象类，来达到灵活扩展性。

依赖有强弱，按强到弱排列如下：

1. 类成员引用；（组合，少用继承，多用组合，UML中的关联关系）

2. 构造函数参数；（UML中的依赖）

3. 方法参数；（UML中的依赖）

为了实现依赖倒置，我们需要用依赖注入（DI），如何注入，就是上面所说3种方式。

如何存储这些依赖实例？就需要依赖容器。
是实例就有生命周期，周期分为3种：
瞬时：调用后马上回收
会话：一次请求期间存在，可在一次请求内重复调用
单例：应用重启前只存在一个并且一直存在