我们经常用耦合度来衡量一个系统架构的水平,似乎也没有多少人抱有疑义,但我要说,这只是大多数情况下一个良好的架构所表现出来的特质,而并非一个系统
架构所真正应该追求的目标。
真正追求的目标实际上很通俗很直白,就是理解高于一切。 一个易于理解和沟通的架构,无论如何都是优秀的,不论是采用了面向过程,面向对象,还是其他的
什么方法论,即使它比另一个难于理解的架构具有更高的耦合度。
做一个思想实验吧。
假设有一个写成了一团乱麻的软件,我们面临的任务是,如果把它切割为不同的部分,让它的架构变得清晰起来。如果是一个小组来承接这个任务,定有一番争
吵,有人喜欢把数据放在一起,用过程去操作它们,有人喜欢抽象出一些通用的对象,有人会想出一种通用架构,然后用这种架构的特例形式来实现软件功能。其
实,即使你一个人去完成这个任务,也时常面临非此即彼的选择,每一种选择都有好处有弊端。
其实,做为一个有经验的设计师,会意识到,这几种视角其实都是有道理的,在面临不同的问题领域时,会有不同的优劣。
传统的软件形态很难容纳多种视角在一个系统中共存, 这时常逼迫设计师们做出无奈的选择。
真的只能这样了?我们应该想到,采用不同视角设计出来的不同的软件实现,其实在逻辑上是一种同构的关系,代码不同,但功能一致,在设计期间视角的转换并
不是一件不可能的事情。在所谓的视角转换的过程中,软件的功能并不会发生变化,但你观察软件的角度的的确确是变了。在某个视角中的类,也许在另一个视角
中被分割为数据和过程,这取决于你进行不同领域设计时的关注点。