再论抽象

我刚开始进博客园的第一篇文章是不是就是说抽象这个事的?时光荏苒啊.... 有段日子不上了,刚才在园子里看见这么篇文章,觉得有必要就我这些年的思想进展,重新讨论下这个问题。

原文在这里:http://www.cnblogs.com/yuyijq/archive/2011/04/26/2028789.html,不长,一定要读一下好知道我这篇文章讨论的基础,我就不重复文章中的重构过程了。类似的例子几年前在博客园的评论上探讨过(好象是跟伍迷),不过现在重新再看这个问题,我个人是清晰了不少。

我们先讨论 IsValid(三个String参数一个Int参数) 重构为 IsValid(User) 的情况,因为弄清楚这个,其他的在很大程度上也就是不言自明的了。

文中的这个User和EMail的提取和打包,其实不是抽象,是具体化。

说到抽象,那个基于字符串的接口,虽然可能大家会觉得这很诡异,但我仍然要说,那才是真正的抽象。说白了就是y=f1(x1,x2,x3,x4),其中x1,x2,x3,x4分别代表原文中对应的变量,这都是为了得出y,f1不可缺少的自变量。

再看变成基于对象的方式,y=f2(x),x现在的概念是个User,事实上这个概念是f2根本不关心的;而且无论你实现别的功能没有,User这个概念都天生隐含着超出f2所关心的属性。这就好比丈量面积,你不用线和面,却偏偏要用墙和院子这样的概念。

抽象的定义是抽出仅当前问题关心的属性。

那么看f1和f2,哪个更符合这一定义呢?即便不这么学究化,是User更具体呢,还是String更具体呢?诚然,我们关心的是类似于“用户名”、“电子邮件地址”这样的东西,但在f1这个抽象中,它必须关心的仅仅是那三个String一个Int的值。

同时,即便我们把这些变量打包到一个具体的模型上去,就作者使用的这个编程语言而言,我们也不可能使得附属于这个模型的字符串得到什么约束。我还是可以错把邮件地址赋给UserName而把用户名赋给EMail;当然,出错的地方肯定变了。

(学究化的问题:根本地,我们当然关心这个字符串是不是用户名;可上面说了无论打不打包,我们也无法保证它。但这真的是没法解决的吗?我个人的答案是这至少可以部分解决,但需要语言提供新的、真正表达概念而不是建立具体化模型的能力)

文中的IsValid经重构,丧失了它本来有的最大的通用性并且变成了对变化敏感的。

由于f1只关心必要的属性,这就使得他产生了最大的通用性和最小的依赖。而f2由于依赖一个接口,这就产生了耦合。大家都把解耦当作面向对象的一个用途,却总是通过具体化不断的产生对接口的依赖。这最终会造成f2虽然明明不用改动其内在,但却大大缩小了复用的范围同时也就容易被变化影响;而这正是面向对象的所要解决的。

道理很简单:其一是有了User、Email这样的具体化(无论是不是纯接口)以后,这些更大的概念必然会承担更多的工作,各种各样的设计都可能导致接口变化从而殃及池鱼;其二,如果一个对象,包含属性x1、x2、x3、x4,但却属于另一个接口,那么f2是不可用的。

当然,我们可以把x1、x2、x3、x4做成一个纯接口Z的属性,并让具体化对象(在这里是User)继承这个接口。但这在很多时候是得不偿失的:为了f3(Z)的效果,我们只是把f1(user.x1、user.x2、user.x3、user.x4)的工作放到了User继承接口Z的代码里。每一个新来的,如果要利用f3,哪怕只用f3一次,也要实现Z接口,或者包装到一个实现Z接口的类中。而若Z只是为了f3一个方法准备的,这代价未免太大了些。

 文中的例子只是基本的网状模型,是“基于对象”而不是“面向对象”。

显而易见的,面向对象只是一个名词,怎么叫没有太大意义。但是我们要采取可以达成一致的共识,使得交流更加容易。判断“一个设计是否是面向对象的”,有一个非常明显的特征,就是是否是使用了多态。

类似定义被不同的权威做出过,比如C++的作者Stroustrup,我在这里就不重复了,我的想法是既然无力改变,只能跟从。文中的例子很显然并没有利用多态(当然文中的例子也没有多态的用武之地)。

对象使用的便捷性 vs 通用性+可重用性

为什么文中的这个例子如此具有代表性、似乎每个人都经常这么做?一个理由可能是现代化IDE提供的对网状模型的使用的便捷性,而且人们总是不自觉的做出实体可能被复用的假设。不过,一个需要注意的事实是:单纯复用实体并省不下多少工作量。

当然,基于对象的网状模型通过具体化带来的便捷性(这里的便捷性是基于User导航到其子属性考虑的,不是从IsValid考虑的),不仅是那些领域爱好者,即便是我也爱不释手的。在动态语言如JavaScript中,由于我们没有“死”接口,基于字典的对象使用起来就很方便,又没有上述种种损失(如果忽略打错字造成的麻烦的话)。为什么呢?

这是因为,字典作为一种通用接口,我们在使用时,往往基于人为的约定和协议。比如这个例子里,你传进来的字典必须有name字段等等。去迎合这些约定,其手工成本要比实现接口低得多,而且一个函数签名可以兼容所有的字典:没有类,只有ducktypes。

那么在静态语言里又怎么办呢?很遗憾,我们没有太好的办法。要么丧失通用性并承担可能的接口改变所造成的风险、要么放弃对象属性导航使用上的便利性;或者对于相对大型的项目而言,最可靠的办法应该是小粒度的纯接口。不过即便在最后一种情况下,我们也应该仔细衡量接口的设计,心里始终记得一点,接口是那种一旦发布并被四处依赖,就很难再改变的东西。

更多

接下来看看原文作者的接下来的重构:把IsValid放入User,既然IsValid严重耦合与User的接口这也就是必然的了(让我们回忆下GoF95一书的副标题吧..);引入Email类,使得我们又多了一个更具体的概念去依赖。由于这些重构没有一个是基于最小化接口的(而是创造实体),与作者的结论相反,这些行为不是提升而是降低了抽象的层次。

这里值得引起我们兴趣的是作者虽然是在进行属性打包的工作,最后又部分的走向了拆分。我个人倾向于,在这来来回回的过程中,就会得到粒度合适于项目及项目可能的变化的接口。虽然这个接口可能不是最符合抽象原则的(而f3(Z)显然符合),但一般会是一个好的平衡点。

即便在现实工作中,我们不得不经历这样的反复,但是探讨何时开始使用基于对象的能力仍旧是必要的(和很多人的直觉相反,多态的面向对象倒是很容易找到用武之地:它总是对应着预期的未来的变化)。在我看来,若有一组操作:f3、f4、f5...,都可以接受一个粒度相对合适的Z,那么Z的创造就成为必然的了(这说的是Z主要作为接口)。

另一方面,原文作者提到的信息隐藏也是一个考虑因素。对于命令式语言,很多时候状态的维护都是不可避免的,有时候,一些状态要严格的保证一致性(这里需要说明的是,纯粹的信息隐藏不具有任何意义),比如状态a、b,他们之间有一定的联系,我们不能只改变a而不改变b,由于使用者可能不了解这种复杂性,我们就需要把它们封装起来。

最后的废话

园子里不是推荐一篇《程序设计的 Top 10 做与不做》说“面向对象比你想象中的还难很多”么,我重复过无数遍的bob大叔的说法也是如此。这里不讨论面向对象的优劣,对我而言,面向对象当然有其用武之地,但是我们必须有明确的目的:这目的除了上述何时使用“基于对象”的因素,便是需要多态发挥作用的时候,比如GoF95中所描述的那些使用场景、比如IoC等等。

希望我这篇文章中阐述的我的一些经验,能对大家有点用途。我的整体建议是,我们最好还是对面向对象抱点敬畏之心。这整套方法加上各种权威的草根的书籍文章,其中的陷阱不可胜数啊....

posted on 2011-05-02 18:51  怪怪  阅读(3756)  评论(90编辑  收藏  举报

导航