模式5:Levelize Modules

 由  Gou Rui 发布

模式描述

在软件开发中,模块之间的组织关系有一个很重要的原则就是“层级化”。


具体描述

  1. 层级化的模块关系,要求模块之间的依赖必须是无环的,也就是说不能出现类似A依赖B,B依赖C,C再依赖A的情况出现。
  2. 在1的基础上,按照下面的方法定义模块的层级关系:
    • 没有任何依赖的模块分配为 level 0。
    • 如果某个模块仅仅依赖 level 0 中的模块,将其分配为 level 1。
    • 依赖 level n 的模块被分配为level n+1 ,如果某个模块依赖多个level的模块,取level最大的那个模块的level值为n。(n>=1)


图片来自:http://www.kirkk.com/modularity/2009/12/levelize-modules/


实现变种

层级(level)和分层(layer)到底有什么区别?分层可能更多的是确定系统责任,而层级更多的是帮助理解系统结构,尤其是依赖。并且层级的粒度更细,一个分层可能有多个层级在其中,反之则不可能。

层级化的设计模式刚刚好介于 [无环关系](Acyclic Relationships) 和[物理分层](Physical Layers)之间。它既要求模块依赖无环,又类似更细粒度的物理分层。一般来说底层的模块(相比于比较高层的模块来说)应该有更少的依赖,更多的被依赖,并且粒度应该更细,更加轻量级。

不过层级化也需要考虑一个尺度,这个尺度可以大概理解为你是否允许某个模块拥有跨越多个层级的依赖:比如 level 5 的模块是否可以依赖 level 2 的模块。严格的层级化要求任何模块只能依赖下一个相邻层级的模块,而比较宽松的层级化则允许夸层级的依赖。理论上来说严格的层级化似乎更好,但是实际上宽松的层级化更加的容易掌握,我们建议在这两者中找到一个最适合当前情况的平衡点,并且当你每定义一个跨层级依赖的时候,你都非常清楚你这样做带来的优势,而不是盲目的下决定。


结果

总的来说,层级化能够让开发者将模块依赖关系的复杂性看的更加清楚。比如一个 level 5 的模块肯定比 level 1 的模块拥有更加复杂的依赖关系。如果一个低层级模块拥有过多的依赖,那么它将会大大的增加整个系统的维护开销。这时候你会考虑干什么?——重构吧!

层级化模块也为层级化构建提供了可能,后者对大型复杂系统的快速构建起到了非常重要的作用,尤其是那些还要做持续集成的团队,更是对构建速度的要求很高。

层级化还能增强模块的可测试性(见测试模块),它能够为模块的测试策略提供一个指引。低层级的模块必然是比高层级的模块更容易测试的,因为它没有那些复杂的依赖关系。比如一个处于UI分层的模块就很难独立测试,我们必须利用mock或者stub来模拟UI模块的依赖。

此外,层级化还能帮助我们考察模块的可复用性,低层级的模块自然是更加容易被复用到其他的系统中。


总结

模块的层级化依赖于模块间依赖的无环性。它帮助你理解系统的依赖结构,让你在构建优化、复用和测试去复杂化上获得很多益处。

查看评论