划分子系统、接口——《一线架构师实践指南》笔记之三

提纲：

划分子系统遵循四个原则的相关：职责、通用性、开发技能、工作量。

协作决定接口。

 

如何划分子系统

下面是分层的细化、分区的引入、机制的提取这3种策略背后的4个通用设计原则：

职责不同的单元划归不同子系统。

通用性不同的单元划归不同子系统。

需要不同开发技能的单元划归不同子系统。

兼顾工作量的相对均衡，进一步切分太大的子系统。

如图13-11所示，子系统的每种划分策略，都是一到多个原则综合作用的结果。

498)this.style.width=498;" height=437<

 

接口设计的事实与谬误

世界是复杂的，很多东西难以直接获得。例如，直接追求幸福，是永远追不到的。（《乐在工作》一书中说幸福是副产品。）

殊不知，合理的接口设计也不是"直接"得到的。

由于面向对象非常强调"自治"，许多人不知不觉地形成了一种错误认识：面向对象推崇"我的接口我做主"。很遗憾，"自治"正确，但"我的接口我做主"这个推断是错误的。

软件世界中本无模块。1968年，Dijkstra发表了第1篇关于层次结构的论文《The Structure of THE-multiprogramming System》。1972年，Parnas发表论文《On the criteria To Be Used in Decomposing System into Modules》论及了模块化和信息隐藏的话题……这些是架构学科开始萌芽的标志。

那么，为什么要对软件进行模块化设计呢？是为了解决复杂性更高的大问题。于是，我们突然领悟：对问题进行分解，分别解决小问题，其实这只是手段。每个架构师应牢记：

"分"是手段，"合"是目的。不能"合"在一起支持更高层次功能的模块，又有何用呢？

因此，我们必须把模块放在协作的上下文之中进行考虑。架构师设计接口时，要考虑的重点是"为了实现软件系统的一系列功能，这个软件单元要和其他哪些单元如何协作"，总结成一句话就是：协作决定接口。

相反，直接设计接口，是很多"面向接口的"架构依然拙劣的原因之一。类似"我的接口我做主"的观点是错误的（如图13-12所示），每个模块或子系统（甚至类）无视协作需要而进行的接口定义很难顺畅地被其他模块或子系统使用。

498)this.style.width=498;" height=373<

"世界上最短的距离不是直线"，又多了一个例证。