依赖倒置原则以及接口隔离方式实现接口设计
1,依赖倒置原则
在我们的日常开发中,经常会遇到类似如,Controller 调用 Service,Service 调用对应的 Dto 程序获取 Po。那么在这种调用依赖中就存在着层级关系。对于调用 Dto 程序来讲,Service 就是他的上层模块或者程序,他的依赖调用关系是从上到下的;而我们的依赖倒置原则定义为,上层模块不在依赖下层模块,上下没有依赖关系而是都依赖一个抽象或者规则,这个抽象是要属于上层模块,这个抽象是由下层模块实现。
依赖倒置原则定义了模块依赖关系,确定了程序开发设计上的顺序,同时也确定了团队之间的合作关系。依赖倒置原则可以让我们的软件增加复用的能力,在一定程度上保证了健壮性。
好莱坞规则
依赖倒置原则它同时也被称为好莱坞原则(Don`t call me,I will call you);正式因为依赖倒置的特点,它同时也是指导我们设计框架的核心点。我们在使用框架的时候,调用顺序永远都是框架调用我们的应用程序,而不是我们的应用程序调用框架。像是 Tomcat,Spring 等等;Tomcat 根据 Servlet 规范进行框架设计,而我们程序实现 Servlet 进行编程,Tomcat 在运行时会调用我们的程序。
2,单一职责原则和接口隔离原则
单一职责原则
单一职责原则也被称为内聚性原则,意为能够引起一个类变化的原因只能有一个,否则就不是单一的。
这里对职责以及职责中变化的原因形容的比较抽象,我添加一些自己的理解。我认为现在日常开发中见到的基本上都不是严格意义上的单一职责的类或者抽象,也做不到严格的单一,只要区分业务或者细化到依赖对象上是单一的就可以算是单一职责。例如,我又要有操作订单的接口又要有操作药品的接口,那么这个抽象就不是单一职责的。如果一个抽象中既有对订单的增删改查也有同步订单,那么我可以认为这个是单一的。
单一职责原则设计的优势就在于可以大大减少代码量,增加阅读体验;减少了编程中容易造成误操作的问题;增加了程序的复用性和健壮性。
接口隔离原则
接口隔离原则意为,不应该强迫依赖程序去依赖他们不需要的方法。例如,一个抽象中有对配置 Config 的操作,有对缓存 Cache 的增删改查操作。那么对与使用缓存的客户端来讲,Config 操作的接口是不需要暴露给我们的客户端使用者的,同理也适用与需要操作 Config 的客户端。
3,使用接口隔离设计优化 Cache 类
描述:
Cache 类有 4 个方法,get/put/delete 是客户端程序要使用的操作缓存的方法,reBuild 方法是 rpc 客户端程序要使用的同步缓存的方法。那么对于客户端来讲 rebuild 不应该被暴露给自己,同理适用 rpc 客户端程序。
评论 (1 条评论)