• 2006-04-26

    逻辑耦合

    Tag:向上走

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/2365399.html

    关于设计,“高内聚,低耦合”一直是我心中的一个核心原则。

    从前谈起耦合的话题,脑子首先闪现的是数据之间的耦合。最常见的便是所谓的全局变量,好好的一个变量,因为有太多地方访问,造成的结果就是我们无法得知自己无法准确的预期程序的行为,因为程序有副作用。我在《有状态的程序》中说过,自己对于有副作用的程序并无好感。最近因为技术调研的关系,我看了一些关于函数式编程(Functional Programming)的东西。在我看来,FP之所以是一种很好的编程范型,因为采用这种范型编程的人更倾向于编写无副作用的程序。如果砖的质量好,至少比质量不好的砖盖出的楼更让人放心一些。

    今天参加了一个评审会,我有幸遇到了另外一种耦合。问题简化一下是这样:

    在一个处理中,有条件A、B,当满足条件A的时候,需要进行a处理,满足B的时候,需要进行b处理。A和B是两个独立的条件,也就是a和b可能同时进行。在我同事的设计中,A和B出现了优先级,也就是如果满足了A,则只进行a处理,否则,如果满足B,进行b处理。前面说过,A和B是两个无关的条件,所以,有人提出,如果存在优先级,这个设计是不是存在漏情况的可能,因为A和B可能同时满足。对此,负责设计的同事给出的答案是,a的处理可以涵盖b的处理。

    不知道我的叙述是否把问题描述清楚了,或许,这个简化过的模型不足以体现原有问题的复杂度。在原有问题上,条件和处理至少有4组。换句话说,优先级的出现,使得前面的处理必须能够涵盖后面各种情形的处理。

    单从结果上来说,因为已经实现了这个算法,所以,至少从已经有的结果上来看,运行得还不错。如果我们不考虑日后的扩展,这样的结果是可以忍受的,但是,现阶段的讨论就是为了日后的扩展,在可以看见的未来,条件增加的概率极大。

    回到前面的问题上。a的处理真的涵盖了b的处理了吗?就算他们真的考虑了这个问题,那么a的处理中也包含了b的逻辑?如果不是这样,那么a如何涵盖b的处理,反之,a包含了b的逻辑,那么这两个块之间绝对存在耦合。无论怎么说,这都是难以解释的。再进一步,即便我们认可这样的方式,当我们增加了新的条件该怎么办?我们是不是要在a中增加对新条件的支持,如果是,a的处理就会可能随着条件的增加无限扩展,如果不是,那么我们如何保证a能够正确处理新增的条件呢?如果采用置之不理的鸵鸟战术,嗯……。反正,逻辑上的不完备让我对此心有不安。

    从逻辑上来说,合并条件的处理并不是不可以,只是合并得让人觉得有些匪夷所思就有问题了,至少他们给出的理由让人难以信服。最简单的解耦方式,当然是将A和B作为两个独立的条件,让它们的处理完全正交,消除它们之间的耦合。不过,从我同事已经实现的部分来看,让他们把a和b完全独立开来也不是一件容易的事,这算是对他们的一次考验吧!

    相对于数据耦合来说,逻辑耦合更加难以发现。像这次,如果没有评审会的讨论,仅仅通过阅读代码,恐怕很难发现这个问题。

    分享到:
    引用地址: