SOLID 软件设计原则

S：单一职责原则

SRP：Single Responsibility Principle

就一个类而言，应该仅有一个引起它变化的原因。

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。

如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。

 

O：开闭原则

OCP：Open Closed Principle

对扩展开放，对修改关闭。

是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。

面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。

 

L：里氏替换原则

LSP：Liskoy Substitution Principle

所有引用基类的地方必须能够透明地使用其子类的对象。

（子类型必须能够替换掉它们的父类型。）

一个软件实体如果使用的是一个父类的话，那么一定适用其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。

只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。

由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展。

 

I：接口隔离原则

LSP：Interface Segregation Principle

类之间的依赖关系应该简历在最小的接口上。

（客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上。）

 

D：依赖倒转原则

DIP：Dependency Inversion Principle

依赖于抽象，不能依赖于具体实现。

-A：高层模块不应该依赖低层模块，两个都应该依赖抽象。 -B：抽象不应该依赖细节，细节应该依赖抽象。

 

 

 

合成/聚合复用原则-CARP

（Composite/Aggregate Reuse Principle）

尽量使用合成/聚合，而不是通过继承达到复用的目的。

 

 

迪米特法则-LOD-最少知识原则

（Law of Demeter）

一个软件实体应当尽可能少的与其他实体发生相互作用。

（如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另个一类的某一个方法的话，可以通过第三者转发这个调用。）

在类的结构设计上，每一个类都应当尽量降低成员的访问权限。

其根本思想：是强调了类之间的松耦合。

类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。