写点什么

[架构师训练营第 1 期] 第二周命题作业

发布于: 2020 年 09 月 26 日

一、题目

  1. 请描述什么是依赖倒置原则,为什么有时候依赖倒置原则又被称为好莱坞原则?

  2. 请用接口隔离原则优化 Cache 类的设计,画出优化后的类图。

  • 提示

cache 实现类中有四个方法。

其中 put get delete 方法是需要暴露给应用程序的,rebuild 方法是需要暴露给系统进行远程调用的。

如果将 rebuild 暴露给应用程序,应用程序可能会错误调用 rebuild 方法,导致 cache 服务失效。

按照接口隔离原则:不应该强迫客户程序依赖它们不需要的方法。也就是说,应该使 cache 类实现两个接口,一个接口包含 get put delete 暴露给应用程序,一个接口包含 rebuild 暴露给系统远程调用。从而实现接口隔离,使应用程序看不到 rebuild 方法。

二、成果

  1. 请描述什么是依赖倒置原则,为什么有时候依赖倒置原则又被称为好莱坞原则?

  • 什么是依赖倒置原则:

高层模块不应该依赖低层模块,而是二者都应该依赖一个属于高层模块的抽象。

这个抽象不应该去依赖实现,而是实现来依赖这个抽象。

所谓的“抽象”,指的就是“规范”,比如“接口”或“配置”等。

注意这个抽象的接口或配置应该是属于高层模块的,而由低层模块去实现它

  • 为什么需要这个原则:

为了解决高层模块的可复用问题。

因为高层模块依赖低层模块的开发模式要求:

低层应该先被开发出来,高层模块才能使用它,从而完成高层模块的开发。

而这样高层依赖低层的缺点是:会导致高层模块不易被复用,因为它依赖了各种低层模块。

因此在软件设计,特别是框架设计,都要求遵循依赖倒置这一核心原则

它可以让高层模块按自己的使用场景进行抽象(定义接口等),而不必依赖低层模块。

  • 举个例子:(在课堂中的“按钮控制等软件”之外的另一个例子)

要设计一个温度控制空调的软件,温度高于阈值(limit)打开空调,温度低于阈值关闭空调。

不采用依赖倒置原则的类图为:

温度控制空调软件设计类图(依赖正置)

这样的设计存在僵化的特性,即 Sensor 直接依赖 AirConditioner,难以复用到其它场合。

当需求发生变化需要扩展时,这样的设计将不得不对修改开放,于是就会违背“开闭原则”。

而遵循依赖倒置原则后,类图为:

温度控制空调软件设计类图(依赖倒置)

通过依赖倒置,Sensor 将得以直接复用于除空调控制外的场景,如大棚遮罩控制、屏幕亮度控制等。

这里面,运用依赖倒置原则的关键在于:洞悉传感器的本质是“采集外部数据,并传递给目标对象”。

而其中,“采集机制”是怎样实现的、“目标对象”又是谁,对架构而言都不重要。

不过,作为“依赖倒置”的题外话,上面的依赖倒置后的设计还需要改进。

因为 AirConditioner 被要求实现 SensorServer 的两个方法后,它变得僵化了,缺乏复用性。

要使 AirConditioner 更具备复用性,可以做如下改进:

温度控制空调软件设计类图(依赖倒置+适配器)

说明:通过适配器将 onOverLimit() 适配成 turnOn() 或 turnOff(),onUnderLimit() 同理。

  • 为什么“依赖倒置原则”又叫“好莱坞原则”?

在遵循依赖倒置原则的系统中,框架通过调用已抽象的接口去调用代码,代码实现该接口从而被框架调用。

所以是“框架调用代码,而非代码调用框架”。

这和一句好莱坞名言“Don't call me, I will call you”有异曲同工之妙。

因此依赖倒置原则也被称为“好莱坞原则”。



  1. 请用接口隔离原则优化 Cache 类的设计(见题目图),画出优化后的类图。

优化后的类图如下:

分布式Cache类图(接口分离)

说明:将 Cache 类的四个方法分离到两个独立的接口。其中:

  • get()、put()、delete() 方法放到 Client 接口

  • rebuild() 方法放到 Maintainer 接口

从而避免了实现 Client 接口的 CacheClient 类被迫依赖 rebuild 方法带来的错误调用隐患。



附:[架构师训练营第 1 期] 第二周学习总结

发布于: 2020 年 09 月 26 日阅读数: 65
用户头像

还未添加个人签名 2018.03.26 加入

还未添加个人简介

评论

发布
暂无评论
[架构师训练营第1期]第二周命题作业