Skip to content

降低耦合

(本文为《信息学竞赛中的软件工程学》系列的第一篇文章)

由于本文面向的并不是专业程序员而是信息学竞赛选手,所以我有必要从基础概念讲起。按照我对软件工程学粗浅的理解,耦合就是程序中模块与模块间的关系的总和。上面的“模块”一词是一个模糊的概念,可以是一个变量、一个函数、一个类,或者是一个package(在大型软件项目中),在信息学竞赛级别的程序中,主要指的是全局变量与函数(本文中“函数”一词包含Pascal语言中所谓“过程”)。

显然,如果这样定义耦合的话,我们编的任何程序都有它的存在,而且它显然是不可避免的——你的程序用到了一个函数,它要调用其它函数,或被其它函数所调用,或读和写某个变量——在我们粗浅的定义里,这些都是耦合了。

但耦合不仅是函数A调用函数B所以A与B之间存在耦合这么简单。事实上,这已经是比较轻的一种耦合。它带来的后果仅仅是:如果函数B改名了、被移除了、改变功能了就会影响到A的功能的实现,这种情况在我们的信息学竞赛的编程过程中并不多见,而且很有可能在编译期就被检查和改正。我想说的是更深一点的东西: 比如,函数A和函数B共同使用某个全局的变量或数组,那么它们对它就必须有某种哪怕是最显而易见的约定,否则就会出问题。(这句话的前提是你用一般认为 “正确”的方法声明和使用全局变量,如果您的编程风格是把每个函数都要用到的临时循环变量i声明成全局的……那您没必要接着看下去了,道不同不相为谋,真的。)

为何要降低耦合?很简单,我们希望我们的程序尽量清晰,而不是一团蛛网或浆糊;这样利于阅读和思考,也利于修改和优化。比如说若函数A依赖于函数B的实现中某个细微的对于全局变量的副作用,那么我们可以说A和B之间的耦合很深;这可能导致我们简单地修改了B之后发现A不能正常工作 了;这可能花费我们大量的时间来寻找原因,毕竟“由于B的副作用被消除导致A的崩溃”这种事情太晦涩了,这不是我们希望看到的。

接下来说如何降低耦合:

1.一个函数只做一件事。我看到过的一些OI程序似乎在“吝啬”地使用函数。也就是说持“能少一个函数就少一个函数”的态度。然而为了减少耦合,我们应该把庞大的、笨重的东西拆成小部件,让每一个小部件和尽量少的外部的东西耦合。另外,单个函数的行数多了会导致出错这也是广泛的共识。

2.不要过早在意细节优化。我知道,有些OI程序中有很巧妙的东西,比如说在排序的同时算前缀和之类。可是,真的需要这样做 吗?为了少写几次for或者是为了还不清楚的“效率”?效率不是想当然的东西,只有Profile能告诉你真正的效率如何瓶颈在哪里。先用最清楚的逻辑描述出程序的框架,如果真的有时间效率问题那一般来说是算法复杂度的问题,在程序编好且正确之后再考虑细节优化吧。这是耦合度增加的温床。

3.减少全局变量的数量。全局变量是耦合的多发地。在软件的开发过程中甚至有些专门对付它们的模式,例如“Singleton”。相信我,你能减少它们。在这一点上我不想说太多。

4.试图面向对象。我知道很难让人像我一样,每当要在程序中用到某种数据结构——不管是最简单的队列还是复杂些的并查集或者Suffix Tree——我都会编一个class,而且很可能是Template Class。我并不是炫耀,我只是想减少耦合,我只是想使程序更清晰些。“面向对象”这个话题会在本系列中单列一篇文章来做更详尽的分析。

我不知道你是否听说过UML、MVC等等这些在软件工程界很“时髦”的缩写词。我认为这些技术(尤其是MVC)存在的主要目的就是为了减少耦合。所以说,不要再写像涂了胶水的绳结一样的程序了,试图减少耦合,从今天开始。

(由于本人对“信息学竞赛”和“软件工程学”的认识都实在粗浅,故错讹之处在所难免,请包涵和指出。)

One Comment

  1. matrix67 wrote:

    三周左撇子,呵呵

    Monday, April 2, 2007 at 12:42 | Permalink

One Trackback/Pingback

  1. Matrix67: My Blog on Monday, April 2, 2007 at 15:44

    推荐:今天和dd的一段聊å¤%A……

    http://tianyi.iyublog.com/20070402/

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*