作业一：依赖倒置

在我们的日常开发中，经常遇到A调用B，B提供方法给A，这时候A是高层，B是底层。

通常在我们的思维中，高层依赖底层是很正常的，但是这也带来问题，如果底层发生变动，高层就必须改，这就出现了设计问题。

举一种简单的生活中的例子，我们加油很多小米的智能家居，有一款米家软件可以通过手机管理这些家居，同时有一个网关，米家对家居的操作是通过网关向具体的智能家居发出指令。

比如：我想开灯，我用手机中的米家对开灯的开关点了开启，会通过网络通知到网关，网关会通过一种通信协议通知到智能电灯。

这是一个很正常的高层调用底层的场景，米家和网关是高层，具体的智能家居是底层，看起来好像是高层依赖底层的一种场景。但是我们仔细想一下，这种场景高层依赖底层真的好么？

小米系有很多授权的企业可以生产智能电灯，每个人的智能电灯可能都有很多不同功能，如果高层依赖底层，是否要在网关层为每种电灯做适配呢？明显不合理！

那么是不是可以将网关通知电灯的这个操作做一个抽象，抽象成一个通用的协议，协议内容就是一个开灯的指令，网关只发送这个指令出去，具体接收到指令是B品牌的电灯还是C品牌的电灯，这不重要，你们都来适配我网关定义的这套抽象就好了。

这就是依赖倒置，本身应该是A依赖B，但改成了A依赖抽象，B也依赖抽象。而这个抽象是A定义的。

通常在框架中总会有依赖倒置的场景，框架是为我们简化开发，而不是增加开发复杂程度，所以绝大多数时候都是框架来主动调用我们，而不是我们去调用框架，那么框架就是高层，我们的业务就是底层。

比如spring事物管理，他定义好了事务抽象，只不过这个抽象不是我们通常理解的接口，而是一个注解，但这也是一种抽象，也是一种依赖倒置。框架设计好抽象接口，又具体业务来实现或者引入从而形成业务的高度扩展性。



好莱坞原则就是，演员提交简历后，制片人会说，不要打给我，我会打给你。这其中制片人的角色就是框架，我们不需要调用框架，框架会在合适的时候来调用你。

演员不需要打给制片人，制片人会在需要你的时候打给你，当然制片人也可能打给其他演员，因为对于制片人来说，所有的演员都是一个演员的抽象，他需要的就是这些演员中的一个，每一个之间都是可以替代的。

这也是依赖倒置原则被称为好莱坞原则的原因。



作业二：框架实现依赖倒置

Spring事物管理实现依赖倒置，由他设定的抽象注解，注解觉得事物管理的范围，注解标注触发回滚的条件。而我们实现者只需要在合适的地方引入注解即可。



还有数据库驱动也是一种依赖倒置，由jdk定义好了Drive、Connection接口，每个数据库厂商都实现了这个抽象的接口，同时在DriveManager中会在合适的时机来通过抽象来调用厂商的数据库实现，这也是一种依赖倒置。



作业三：接口隔离原则优化 Cache 类





上图是原图，其中get、put、delete三个方法是提供给调用方获取、更新、删除缓存，reBuild用于被缓存配置进行重建。



调用房只关心get、put、delete三个方法，所以不应当将reBuild方法暴漏给调用方。将以上四个方法拆分为两个接口，Cahce用于也无方使用，用于获取、更新、删除缓存。而CacheManager用于管理缓存配置。从而将接口进行隔离。