<读书笔记>(模块层面)BMS-6: 对架构构件进行解耦

"世上有两种软件设计: 一种是让设计更加简单, 以致于明显不会有缺陷. 另外一种是让设计变得十分复杂, 以致于看起来不会有明显的缺陷." -- C.A.R.Hoare

原则: 对顶层构件实现松耦合.

做法: 减少一个模块暴露给其他组件中的模块的相对代码量.

好处: 让组件更加容易进行独立维护.

这里的模块指的是一个类, 而组件是由模块组成的, 即组件包含若干模块.

软件架构在软件开发过程中的地位非常重要.

如何在实际工作中应用这个原则:

• 限制作为组件接口的模块的大小.
• 将组件的接口进行更高层级的抽象.
• 避免组件中作为接口的模块在被调用的同时还调用其他组件中的接口.

利用抽象工厂模式来暴露尽可能少的接口代码

在实践中最多用到的就是利用抽象工厂来暴露接口, 这样组件间的依赖更多就依赖到了抽象上而非实现上.

另外还有许多的办法可以对组件间进行解耦, 比如利用依赖注入等手段.

抽象工厂是将特殊"产品"的制造隐藏在"产品工厂"接口的后方.

比如我们有一个 PlatformServices 组件, 它可以提供两种平台支持, 一种是 AWS, 一种是 Azure(而后期还会添加更多的平台类型支持).

现在这个组件的接口如下:

• 启动服务
• 停止服务
• 获取指定容量的数据存储空间

基于这个接口, 我们创建两个特殊的工厂类, 分别对应 AWS 和 Azure. 而特殊的工厂类在实现的时候就必然会调用到 AWS 或 Azure 平台支持的实现代码, 但返回的都是相同的接口类型对象. 而不是特殊的 AWS 或 Azure 对象类型(这样就将它们隐藏在了组件中).

即一个产品对应一个特殊的产品工厂. 由工厂提供抽象产品, 产品的接口是统一的, 只是行为不同而已.