1：什么依赖倒置原则，为什么又叫好莱坞原则

1.1依赖倒置原则定义

高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。

要面向接口编程，不要面向实现编程

---依赖抽象编程

1.2对依赖倒置的理解



良好的设计要给系统提供更好的稳定性，减少变动对系统的影响。目的就是提高效率节约成本。依赖倒置目的-提高系统稳定性，减少变化的影响-根还是开闭原则。



一般分析问题的思路，是先从要做什么，然后怎么做，对应的程序分层上，高层是需求，明确要做什么，低层是要怎么做， 是具体实现。比如高层实现一个服务，服务里需要做数据存储，存储放到底层。这是最常见的软件层次化划分结构。这样很容易导致将高层依赖与底层。



高层依赖底层有问题吗？一般情况下抽象是需求的概括，是稳定的，而具体实现是容易调整与变化的。底层是实现是细节，如果高层依赖底层，高层就不稳定了。因此常规做法是，层间做好约定，高层只依赖接口，不依赖底层的具体实现，底层实现这个接口。



接口归属于哪里？接口应该放到稳定的地方。

如果高层的逻辑比较稳定就放到高层，这就是依赖倒置的倒置为，框架类设计是典型的依赖倒置场景。比如：设计一个数据检查的框架，装配需要检查的数据与检查器，实现对数据的检查。检查器是底层的实现，可以有多种检查规则。框架定义好检查接口

interface IChecker{

CheckResult Check(DataItem data)

}

这个IChecker 放到框架中定义，实现做多种检查策略的实现，注册到框架。



如果底层比较稳定就可以放到底层。比如String 类在语言中就是稳定的，当然不需再抽象一层。实际中程序依赖的很多工具库都没有再做一层抽象，也可以理解为在本系统中底层的实现是稳定的。



高层底层都不稳定（多种实现，多种选择），而约定稳定，接口就独立一层。比如servlet ，就是一个标准，应用服务器可以有多种实现，web应用当然更多。 servlet 可以认为就是独立定义的一层。



在实践中那一层稳定，要根据自己的具体场景判断。并不一定要倒置。比如公司有缓存实现，业务调用缓存，当然缓存接口不会放到业务的服务层。只是如果所有实现都是接口放到底层就出问题了，仔细审视自己的场景了吗？稳定的是底层吗？

1.3好莱坞原则

Don't call me ,I will call you

不要调用我，我会调用你。

接口是高层定义的（我-接口层-在高层），底层只实现接口，不要调用接口（等着被调用），接口由高层调用。

因此接口所有权在高层的场景，就是好莱坞式---Don't call me ,I will call you。



1.4典型场景-框架

框架定义，目的---必然依赖倒置。

框架：针对某类场景的可重用设计，由具体实现去填充血肉，框架驱动这个场景的运行。具体实现按框架约束（标准）实现细节。

框架定义好约束，由具体实现去扩展。因此约束是在框架中定义的，接口归于框架层。

框架在要解决的场景中，是主干，框架驱动程序的运行，框架属于高层。

框架的设计时典型的依赖倒置，市面上的框架也都是这么设计的。



IOC 场景Spring 是典型的框架。组件的装配由IOC框架（Sping ）负责，应用只需要按照Spring对IOC定义的规范即可。比如以注解实现，就按Spring要求注解，不需去找Spring 。Spring 会去找你（扫到你的注解），然后实现装配。用XML 配置也是一样，只是Spring定义了多种规范，实现哪一种都可以。



2：接口隔离原则优化Cache类设计

类图如下