里氏替换（Liskov Substitution Principle）
里氏替换 （LSP）：子类对象 能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏。举例：是拿父类的单元测试去验证子类的代码。如果某些单元测试运行失败，就有可能说明，子类的设计实现没有完全地遵守父类的预定，子类有可能违背了里氏替换原则。
里氏替换原则是用来知道，继承关系中子类该如何设计的一个原则。
接口隔离原则（Interface Segregation Principle ）
接口隔离原则（ISP）：调用方不应该被强迫依赖它不需要的接口。举例：Config接口拆分为Updater和Viewer两个接口
public interface Updater{
void update();
public interface Viewer{
String outputInPlainText();
Map<String,Stinrg>output();
}
public class RedisConfig implemets Updater,Viewer{
//省略其他属性和方法
@Overrride
public void update(){//……}
@Overrride
public String outputInPlainText(){//……}
@Overrride
public Map<String,String>output(){//……}
}
public class KafkaConfig implements Updater{
//……省略其他属性和方法
@override
public String outputInPlainText(){//……}
@Overrride
public Map<String,String>output(){//……}
}
public class SimpleHttpServer{
private String host;
private int port;
private Map<String,List<Viewer>> viewers = new HashMap<>();
public SimpleHttpServer(String host,int port){//……}
}
}依赖反转原则（Dependency Inversion Principle）
依赖反转原则（DIP）：高层模块（high-level modules）不要依赖底层模块（low-level）
高层模块和底层模块应该通过抽象（abstractions）来互相依赖。除此之外，抽象不要依赖具体实现细节（details），具体实现细节（details）依赖抽象。
举例：Tomecat 和 java webApp ， 两者都依赖同一个“抽象”，也就是Servlet规范。
- 控制反转（IOC）：Inversion Of Control ，框架提供了一个可扩展的代码骨架，用来组装对象，管理整个执行流程。程序员利用框架进行开发的时候，只需要往预留的扩展点上，添加跟自己业务相关的代码，就可以利用框架来驱动整个程序流程的执行。实际上，控制反转是一个比较笼统的设计思想，并不是一种具体的实现方法，一般用来指导框架层面的设计。这里所说的“控制”指的是在没有使用框架之前，程序员自己控制整个程序的执行。在使用框架之后，整个程序的执行流程通过框架来控制。流程的控制权从程序员“反转“给了框架。
- 依赖注入（DI）：Dependency Injection 依赖注入的方式来将依赖的类对象传递进来，这样就提高的代码的扩展性，我们可以灵活地替换依赖的类
- 依赖注入和控制反转恰恰相反，它是一种具体的编码技巧，我们不通过new的方式在类内部创建依赖类的对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类来使用
- 依赖注入框架
我们通过依赖注入框架提供的扩展点，简单配置一下所有需要的类及其类与类之间依赖关系，就可以实现由框架来自动创建对象，管理对象的生命周期，依赖注入等原本需要程序员来做的事情 - 依赖反转原则
依赖反转原则也叫做依赖倒置原则。这条原则跟控制反转有点类似，主要用来指导框架层面的设计。高层模块不依赖低层模块,它们共同依赖同一个抽象。抽象不要依赖具体实现细节，具体实现细节依赖抽象
