Duck Typing与协议 vs. 继承-优快云博客

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

根据irb中的运行结果：
\u0026gt;\u0026gt; StringIO.is_a?(IO)

\u0026gt;\u0026gt; =\u0026gt;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编程语言的使用者们在很久以前就已经很明白了。Smalltalk与ObjectiveC，作为动态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) \u0026amp;\u0026amp; 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(\"\\

Duck Typing与协议 vs. 继承

相关推荐