依赖倒置原则

百度解释：是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合

原始定义：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象（High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions）。其核心思想是：要面向接口编程，不要面向实现编程

自己的理解：

我们写代码的时候都会定义一些service接口，然后写一些serviceImpl，我一般在controller层处理的都是引用这些service接口，而不会去引用的这个接口serviceImpl。这个controller层依赖就是接口，而细节在serviceImpl中，这样就简单做到依赖倒置的原则。

因为我简单利用service接口定义，在不同的业务的就会出现不同的实现，这个就会实现业务的松耦合，在新增的业务中，如果也满足这个定义，新增业务的实现类即可，不会影响原先的代码，这其实也属于开闭原则范畴，对扩展开发，对修改关闭。所以依赖倒置也是实现开闭原则的重要途径之一。

依赖倒置原则和好莱坞的原则非常类似，就是电影角色依赖于演员，但是不会依赖于某一个演员。演员可以看成角色的实现类，而角色就是一个接口。我需要这个角色（接口）哪个演员（实现类）来诠释（实现），会通知（调用）哪个演员（实现类）



接口隔离原则：

百度解释：客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在最小的接口上

出现这样的一个场景：刚开始你在一个接口中不同的添加方法，满足现有的业务需求。再来一个类似的业务，需要这个接口部分的方法，会怎么做？这种你可能用适配器，写一些空的是实现这个接口方法，也可以把这个接口拆分成两个或者三个接口。接口隔离原则，就是拆分原有的接口。可以把他拆分中公有的，还有一些某些业务特有的。

拆分没有一定的标准，不会定义每个接口必须不能超过多少方法，多少代码，但是也有一定的考虑原则：

• 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。

• 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。

• 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情

比如下面的这个例子：

现在一些应用程序不用看reBuild方法，一些应用程序不需要看到get put delete方法。按照现有的要求可以拆分成四个接口，也可以拆分成两条接口。按照现在的需求可以先拆分成两个接口，一个接口含有reBuild，一个接口有put，get，delete方法。可以拆分成一下：