当谈起软件设计的目的时,能够获得所有人认同的答案只有一个:功能实现。 因为这是一个软件存在的根本原因。
而在计算机软件发展的初期,这一点也正是所有人做软件设计的唯一动机。因而,很自然的,整个软件都被放在单一过程中,然后用到处存在的goto语句控制流程。
尽管理论上讲,任意复杂的系统都可以被放入同一个函数里。但随着软件越来复杂,即便是智商最为发达的程序员也发现,单一过程的复杂度已经超出他的掌控极限。这逼迫人们必须对大问题进行分解,分而治之。
时至今日,尽管超大函数,上帝类依然并不罕见,但当大到一定程度,上帝类的创造者最终也会发现自己终究没有上帝般的掌控力。因而,哪怕是软件设计素养为负值的开发者,或多或少也会对一个复杂系统进行一定程度的拆分。
这就是模块化设计的最初动机。
一旦人们开始进行进行模块化拆分,就必须解决如下两个问题:
更简单的说:怎么分?然后再怎么合?
而这两个问题的答案,正是现代软件设计的核心关注点。
为了找到这两个问题的答案,我们需要重新回到最初的问题:为何要做软件设计?
Kent Beck给出的答案是:软件设计是为了在让软件在长期范围内容易应对变化。
在这个精炼的定义中,包含着三个关键词:长期,容易,变化。这意味着:
对此,Kent Beck提出了一个更为精炼的原则:局部化影响。意思是说:我们希望,任何一个变化,对于我们当前的软件设计影响范围都可以控制在一个尽量小的局部。
这当然是所有严肃的软件从业者都梦寐以求的。
每个读过基础软件工程教程的人都知道:一个易于应对变化的软件设计应该遵从高内聚,低耦合原则。
所谓内聚性,关注的是一个软件单位内部的关联紧密程度。因而高内聚追求的是关联紧密的事物应该被放在一起,并且只有关联紧密的事物才应该被放在一起。简单说,就是Unix的设计哲学:
来源: http://www.infoq.com/cn/articles/change-driven-orthogonal-design