抽象的成本

2010-08-08 黄毅

任何程度的抽象都像DSL,会有自己的Domain,当你的问题在这个Domain里面,抽象的好处就能体现,当你的问题不在这个Domain里面,抽象很可能就会成为障碍。

比如说面向对象。你可以想象在一个严重面向对象的项目里面进行单步执行会是什么样的下场,面向对象的设计模式通常都很成功地把顺序执行的代码流分散到许多不同的类方法里面。

不,我并不是想说面向对象的坏话。事实上,如果你有幸能联系上这个面向对象项目的作者的话,他大概会这么回答你: 谁叫你丫用面向过程的方式来看面向对象的代码了,你去看看我们的UML设计图,多清新的结构图,多清楚的类关系啊。

所以,我想说的是,其实这是用一个Domain的思维去理解另一个Domain的代码的必然后果。

当然,现实情况是很多用面向对象方法构造的项目,你无法完全抛弃面向过程的方法,单纯通过设计图,类体系结构去理解的,你会发现单步的方法是必须的,这才是悲剧发生的真正原因。

换句话说就是,面向对象作为一个抽象机制,它有自己独特的代码组织结构,但它却没有自己完备的语义模型,无法在抽象体系内部对代码的含义做出精确的解释,从而不得不回退到面向过程或者说操作语义来理解程序。而这个时候,面向对象的抽象就成为了理解的障碍。

任何一个没有完备的语义模型的抽象都是有成本的,那就是当你不得不回退到操作语义时,这些抽象机制通常都会变成你的障碍。

函数式语言我不了解,据说他们有指称语义模型,可以独立于指令流对代码的含义做出精确的解释。不过我仍然担心的是,当你不得不考虑它实际执行的指令流时,会是更大一个悲剧。


blog comments powered by Disqus

转载请注明出处,收藏或分享这篇文章到: