BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Duck Typing与协议 vs. 继承

| 作者 Werner Schuster 关注 6 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2007年12月6日. 估计阅读时间: 8 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

在ruby-core邮件列表中,一个关于Ruby中动态类型的问题引发了一系列讨论

根据irb中的运行结果:

>> StringIO.is_a?(IO)
>> =>false

对我来说,这看起来不合逻辑。是有意而为之吗?如果是的话,为什么?

有一种答案是这样的:

因为StringIO没有使用IO作为它的基类实现,所以它不是IO。

不过这又有什么关系呢?如果你使用标准的Duck Typing,这根本就无所谓。使用Duck Typing时,类的层次关系无关紧要。类只不过是Duck Typing的一种实现细节。你也不用关心#is_a?、#respond_to?等方法。只要假定对象提供你要调用的方法,然后调用它们就可以了。

原来的问题(以及邮件列表辩论中出现的一些帖子)应该是来自对OOP中继承所担当的角色的混淆。StringIO和IO不需要同样的超类,因为它们之间没有任何共同之处,除一点之外:它们支持的一系列方法。

看来这就是Duck Typing的基本想法:让对象可以响应一系列方法就够了,没必要要求它属于某个类型。

此处没有什么新概念,也不是Ruby特有的东西。将“方法”这个词换成OOP的术语“消息”,上面的句子就变为:“【……】让对象可以响应一系列消息”。听起来真的很像是某个(网络)协议(Protocol)的概念。毕竟,如果一个系统可以理解并响应诸如“PUT”、“GET”、“POST”等以特定的方式发送给它的消息,就可以说它理解HTTP协议。

让我们进一步看看这个想法:某个客户端,比如说Web浏览器,只关心它通信的服务器是否理解HTTP,它才不管服务器是什么类型呢。总之:如果Mosaic浏览器被硬编码为需要另一端的服务器是NCSA或Netscape的HTTP服务器,互联网恐怕就不会像现在这样蓬勃发展了。通过忽略通信另一端的类型,并且只要求以特定的方式回应“GET”消息,Web开发的两端(服务器端与客户端)都可以彼此独立地进行演化。

这种方式与协议的类似之处,OOP编程语言的使用者们在很久以前就已经很明白了。SmalltalkObjectiveC,作为动态OOP语言,早就使用“协议”(Protocol)这个词来指代此概念了。

协议的概念当然很有用,正好用来给特定的信息定一个名称。这也有助于澄清上述邮件列表中争论的问题。StringIO与IO共享的不是共同的祖先,而是共同的协议。

此概念并不仅限于动态语言。在一些静态语言中,比如Java就通过引入接口,而向前跨进了一大步。接口被用来:

  • 命名一系列信息
  • 静态检查一个类是否实现了这些信息

虽然在一些语言中,比如C++,通过抽象基类和多继承也能做得到,但抽象基类混淆了继承和协议的概念。

当然,静态检查的保障是有限的 :接口只能检查一些有特定签名的方法——它不能保证方法的行为,甚或是方法的返回值,甚至也不能保证方法是可以被调用的——比如说在使用Java的Collection API的时候,要小心应对Java的java.lang.UnsupportedOperationException。

毫无疑问,接口也有它们自己的问题,比如演化性。改变一个接口,会破坏所有实现了该接口的类。像Eclipse这样的大型项目,会提供API演化的指导建议,其中规定了一个接口在发布之后就不可以再发生变化。这样的状况下,有时会建议大家多使用抽象类而不是接口,因为抽象类可以添加新的函数,但令其实现为空,这样子类就可以,但是不必实现这些新函数。当然,这个问题可以通过定义粒度合适的接口来解决,每个接口对应一个方法,并且通过对已有接口的扩展来搭建完整的接口集合,每个接口对应一定单独的API调用。

要解决保证一个对象支持某个协议这个问题,在Ruby中,可以通过将接口检查委托给一个谓语函数(predicate function)来完成。如下示例:


def supports_api?(obj)
 obj.respond_to?(:length) && obj.respond_to?(:at)
end 

此做法可行,但是同时会带来一个小问题:respond_to?只对定义在一个类中的方法起作用。如果一个对象用method_missing来实现它的部分接口(例如一个代理),虽然对这些方法的调用没有问题,但针对它们调用respond_to?会返回false。这就是说respond_to?检查可以工作,但是它不适合用来替换静态检查(Rick de Natale将这种编码风格称为“Chicken Typing”,这是防御性编程的一种)。

另一种静态定义细粒度接口的方式是Scala语言的结构化类型

def setElementText(element : {def setText(text : String)}, text : String) = 
{
element.setText(text.trim()
.replaceAll("\n","")
.replaceAll("\t",""))
}

此函数需要element参数有一个setText(text:String)方法,但是它不关心对象的特定类型。

将精力集中于某个对象的特定类型或类层次结构同样会限制灵活性。需要一个int类型参数的接口只能通过赋予int或Integer类型(通过自动装箱)参数来调用——别的都不行。长远来看,一个只需要对象提供to_i方法(返回一个整型、FixNum或者BigNum都可)的方法会更加灵活。开发者无法控制的类可能不会继承自需要的类,不过它们仍然可能支持同一个协议。

介于动态(Duck Typing)和静态(接口,Scala的结构化类型)之间的,是Erlang的Behaviors。Erlang的模块(可以对比Ruby的Module)将功能分组在一起。一个模块可以使用-behaviour(gen_server).来表明它实现了gen_server Behavior,也就是说它输出了一系列特定的函数。Erlang编译器支持该用法,当模块没有输出Behavior需要的全部函数时,编译器会发出警告信号。

这也说明,不仅仅是那些提供类、对象、继承等等概念,将自己定义为“OOP”的编程语言,才适用协议的一般原理 。

你是如何记录在Ruby中对协议的使用的?即,你如何确定有互动关系的对象彼此同意并传递的一系列消息?

查看英文原文:Duck Typing and Protocols vs. Inheritance
译者简介:郑柯,目前任职《程序员》杂志社高级编辑,有志于在中国的软件开发业界推广Agile的理念和方法论,笃信以人为本,关注人,关注敏捷,关注Ruby。 参与InfoQ中文站内容建设,请邮件至china-editorial@infoq.com

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

另一个办法 by Chen Jerome

不知道异常的开销如何,不然可以用检查是否raise NoMethodError来检查是否支持某方法。

[Ruby中文社区] - www.ruby-lang.org.cn

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT