如何理解依赖倒置？

一、什么是依赖倒置原则，为什么有时候依赖倒置原则又被称为好莱坞原则？

在软件设计中，如果高层直接依赖低层或抽象依赖与实现，那低层或实现带来的变动，会直接影响的高层或抽象；

为了降低这种影响，我们应该使用接口来隔离变化，高层定义抽象依赖于它，低层对象实现高层定义的抽象；这样将低层具体实现的变化不会影响到高层，这种依赖关系的反转称为依赖倒置；

这种高层定义抽象，需要调用低层时，会根据具体实现动态调用低层，完全不需要低层实现主动查找高层，所以又被称为好莱坞原则，Don't call me, I will call you!

二、请描述一个你熟悉的框架，是如何实现依赖倒置原则的

实现依赖倒置的框架有很多，这里我们可以简单来看 Spring 是如何使用依赖倒置原则的；

在软件开发中，我们通常需要创建一些无状态具有特定功能或业务函义的类，类与类之间会存在相互依赖的关系，而这些类如果让程序员手工创建这些类，一是过程繁锁，创建代码重复，二是类的生命周期，依赖关系管理复杂；

有没有一种方式，让开发的同学通过约定的行为，即可让类在使用的时候，已自动创建好，开发只需要关注业务中如何使用即可。

Spring Ioc 容器解决了上面的问题，通过对运行时类的抽象为 bean，将容器对象抽象在 BeanFactory，由 BeanFactory 负责 Bean 对象的元信息读取、解析，实例化、初始化、使用、回收等整个生命周期的管理。

这样开发只需要通过简单的注解或 xml 形式的声明，Ioc 容器会自动创建好这些 Bean，自动为相互有依赖关系的 bean 注入依赖，无需人为干涉!

三、请用接口隔离原则优化 Cache 类的设计，画出优化后的类图

如图所示，如果客户端只需使用 get、put、delete ，而系统后台控制程序例用 reBuild,该如何优化?

优化后：

本周总结：

万事万物皆对象，现实的抽象，可以通过软件形式表述。

软件设计的根源是解决现实问题，将现实问题映射到编程领域，即所谓的问题域；

软件设计的核心正是要解决一个个问题域；问题域分解下来就有了我们的业务模型，业务模型进一步分解，就有了代码模型，和数据模型。

业务模型是怎么活动的，反映在代码模型上，一个好的系统应该是拥抱业务需求的快速迭代的。

这就需要系统拥有很好的扩展性，灵活性，易读，易维护这些特性，而这些最终反映在代码模型体现为，类的组织结构，交互行为、都要具备上述特性。

那如何做一个易读、易维护，扩展性好软件系统呢? 必须要尊循以下设计原则：

开闭原则：不需要修改软件实体，就能够扩展功能

依赖倒置原则： 高层模块不能依赖低层模块，而是大家都依赖抽象

抽象不能依赖实现，而是实现依赖抽象

里式替换原则：任何基类出现的地方都能被其子类替换

接口隔离原则：不要强迫客户依赖它们不需要的方法