架构师训练营作业 --Week2

什么是依赖倒置？

Dependence Inversion Principle(DIP)依赖倒置，aka. 依赖反转。定义：

• High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces).

• Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

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



当类A与类B的关系是“has-a”关系时，我们可以说类A依赖类B。随着时间推移，类A的业务扩展了，需要依赖类C完成一些功能，类B和类C在功能上是相似的。要实现这样的新需求，必须修改类A，加入对类C的依赖。很显然，当再有类似需求时，类A需要被再次修改，因为类A与类B和类C的依赖关系是在类A中维护的。当有新功能增加时，总是需要修改既有代码的设计是不好的设计，耦合度太高。解决方案就是将类B和类C的功能抽象成接口I，类B和类C都实现接口I，而类A依赖I。这样的设计，使得类A从需求变化中解放出来，将对I实现类对依赖关系交由类A的使用者决定，这就是依赖倒置。

依赖倒置在Spring Security框架中的应用

Spring Security 是一个通用的安全认证框架。它支持几乎所有常见的认证方式。在具体业务场景中，Spring Security框架是将用户选定认证方式串联到业务逻辑中的模块，既高级别模块。而用户指定的认证方式是低级别模块。为了实现依赖倒置，Spring Security抽象出了AuthenticationProvider接口来指代认证方式，然后在AuthenticationManager中在运行时将具体AuthenticationProvider实现类提供给安全认证模块。以下是Ldap和Dao认证方式的类图。为了方便描述，非必要域及方法已去除。



用接口隔离原则优化 Cache 类的设计

现有设计将管理缓存用的reBuild方法暴露给应用程序，违反了接口隔离原则。应该将reBuild方法抽出放到另一个管理接口中，与使用缓存的方法隔离开。应用程序在使用时，应该调用接口，而非Cache类。重新设计后的类图如下。

在应用程序中，应该像这样调用接口：

Cache cache = new GeneralCache();

在缓存管理接口中调用：

CacheManager cacheManager = new GeneralCache();