动态语言中的接口有什么意义吗？

Question

在像 Java 这样的静态语言中，你需要接口，因为 否则类型系统不会让你做某些事情。 但在 PHP 和 Python 这样的动态语言中，你只需采用 鸭子打字的优点。

PHP 支持接口。 Ruby 和 Python 没有它们。 所以没有他们你显然可以幸福地生活。

我主要是用 PHP 做我的工作，但从来没有真正用过 利用定义接口的能力。 当我需要一个 一组类来实现某些公共接口，然后 我只是在文档中描述它。

所以你怎么看？ 不使用你不是会更好吗 动态语言中的接口吗？

Answer 1

Python 3000 将具有抽象基类。 非常值得一读。

Answer 2

在像 PHP 这样的语言中，不存在的方法调用会导致致命错误并导致整个应用程序崩溃，那么接口就有意义了。

在像 Python 这样的语言中，您可以捕获并处理无效的方法调用，但事实并非如此。

Answer 3

停止尝试用动态语言编写 Java。

Answer 4

除了其他答案之外，我只想指出 Javascript 有一个 instanceof 关键字，如果给定实例位于给定对象原型链中的任何位置，该关键字将返回 true。

这意味着，如果您使用原型链中的“接口对象”作为“实现对象”（两者对于 JS 来说都是普通对象），那么您可以使用 instanceof 来确定它是否“实现”它。 这对执行方面没有帮助，但在多态性方面确实有帮助——这是接口的一种常见用途。

MDN instanceof 参考

Answer 5

Java“接口”的用途之一是允许在 Java 中使用强类型 mixins。 您可以混合适当的超类以及为支持该接口而实现的任何其他方法。

Python 具有多重继承，因此它并不真正需要接口设计来允许来自多个超类的方法。

然而，我喜欢强类型的一些好处——主要是，我喜欢早期错误检测。 我尝试使用“类似接口”的抽象超类定义。

class InterfaceLikeThing( object ):
    def __init__( self, arg ):
        self.attr= None
        self.otherAttr= arg
    def aMethod( self ):
        raise NotImplementedError
    def anotherMethod( self ):
        return NotImplemented

这在某种程度上使界面正式化。 它没有提供子类符合预期的绝对证据。 但是，如果子类无法实现所需的方法，我的单元测试将失败，并出现明显的 NotImplemented 返回值或 NotImplementedError 异常。

Answer 6

首先，Ruby 确实没有 Interface，但他们有 mixin，它以某种方式吸收了其他语言的接口和抽象类的优点。

接口的主要目标是确保您的对象应实现接口本身中存在的所有方法。

当然，接口从来都不是强制性的，即使在 Java 中，当您不知道要操作的对象类型时，您也可以想象只使用类并使用反射来调用方法，但它很容易出错，应该不鼓励很多方法。

Answer 7

好吧，检查给定对象是否支持整个接口肯定会更容易，而不仅仅是在调用初始方法中使用的一两个方法时不崩溃，例如添加一个反对内部列表。

鸭子类型具有接口的一些好处，即到处都易于使用，但仍然缺少检测机制。

Answer 8

这就像说您不需要动态类型语言中的显式类型。 为什么不把所有东西都变成“var”并在别处记录它们的类型呢？

这是程序员对程序员施加的限制。 这会让你更难搬起石头砸自己的脚； 让您犯错的空间更小。

Answer 9

作为一名 PHP 程序员，在我看来，接口基本上用作契约。 它让您说使用此接口的所有内容都必须实现一组给定的函数。

我不知道这是否有用，但当我试图理解接口的全部内容时，我发现它有点绊脚石。

Answer 10

如果您觉得必须这样做，您可以实现一种带有函数的接口，该函数将对象的方法/属性与给定的签名进行比较。 这是一个非常基本的例子：

file_interface = ('read', 'readline', 'seek')

class InterfaceException(Exception): pass

def implements_interface(obj, interface):
    d = dir(obj)
    for item in interface:
        if item not in d: raise InterfaceException("%s not implemented." % item)
    return True

>>> import StringIO
>>> s = StringIO.StringIO()
>>> implements_interface(s, file_interface)
True
>>> 
>>> fp = open('/tmp/123456.temp', 'a')    
>>> implements_interface(fp, file_interface)
True
>>> fp.close()
>>> 
>>> d = {}
>>> implements_interface(d, file_interface)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in implements_interface
__main__.InterfaceException: read not implemented.

当然，这并不能保证太多。

Answer 11

我认为这更多的是一种便利。 如果您有一个函数接受“类似文件”的对象并且仅对其调用 read() 方法，那么强制用户实现某种 File 接口是不方便的 - 甚至是限制性的。 检查对象是否具有读取方法也同样容易。

但是，如果您的函数需要大量方法，则检查对象是否支持接口然后检查每个单独方法的支持会更容易。

Answer 12

是的，有一点是，

如果您不显式使用接口，您的代码仍然使用该对象，就好像它实现了某些方法一样，只是不清楚未说出的接口是什么。

如果你定义一个函数来接受一个接口（比如 PHP），那么它会提前失败，并且问题将出现在调用者身上，而不是执行该工作的方法身上。 一般来说，早期失败是一个值得遵循的良好经验法则。

Answer 13

接口实际上为拥有它们的静态语言（例如 Java）添加了某种程度的动态语言灵活性。 它们提供了一种查询对象在运行时为其实现合约的方法。

这个概念很好地移植到动态语言中。 当然，根据您对“动态”一词的定义，甚至包括 Objective-C，它在 Cocoa 中广泛使用了协议。

在 Ruby 中，您可以询问对象是否响应给定的方法名称。 但这是一个相当弱的保证，它会做你想做的事，特别是考虑到一遍又一遍地使用很少的单词，没有考虑完整的方法签名，等等。

在 Ruby 中，我可能会问

object.respond_to? :sync

所以，是的，它有一个名为“sync”的方法，无论它意味着什么。

在 Objective-C 中，我可能会问类似的问题，即“这看起来/行走/嘎嘎像同步的东西吗？”：

[myObject respondsToSelector:@selector(sync)]

更好的是，以一些冗长的代价，我可以问更具体的问题，即“这看起来/行走吗？” /quack 就像与 MobileMe 同步的东西？”：

[myObject respondsToSelector:@selector(sync:withMobileMeAccount:)]

这是鸭子打字到物种级别。

但是要真正询问一个对象是否有希望实现与 MobileMe 的同步...

[receiver conformsToProtocol:@protocol(MobileMeSynchronization)]

当然，您可以通过检查是否存在一系列选择器（您认为是协议/鸭子的定义）来实现协议，如果它们足够具体。 在这一点上，协议只是一大堆丑陋的responds_to的缩写？ 查询，以及一些供编译器/IDE 使用的非常有用的语法糖。

接口/协议是对象元数据的另一个维度，可用于在处理这些对象时实现动态行为。 在 Java 中，编译器恰好要求正常方法调用执行此类操作。 但即使是 Ruby、Python、Perl 等动态语言也实现了超出“对象响应哪些方法”的类型概念。 因此就有了 class 关键字。 Javascript 是唯一一种没有这个概念的真正常用的语言。 如果您有类，那么接口也很有意义。

诚然，它对于更复杂的库或类层次结构比大多数应用程序代码更有用，但我认为这个概念在任何语言中都是有用的。

另外，其他人提到了mixin。 Ruby mixin 是一种共享代码的方式——例如，它们与类的实现相关。 接口/协议是关于类或对象的接口。 它们实际上可以互补。 您可能有一个指定行为的接口，以及一个或多个帮助对象实现该行为的mixins。

当然，我想不出任何语言真正具有这两种不同的一流语言特征。 在那些有 mixin 的情况下，包含 mixin 通常意味着它实现的接口。

Answer 14

我认为接口的使用更多地取决于有多少人将使用你的库。 如果只有您或一个小团队，那么文档和约定就可以了，而需要接口将是一个障碍。 如果它是一个公共库，那么接口会更有用，因为它们限制人们提供正确的方法而不仅仅是提示。 因此，界面对于编写公共库来说绝对是一个有价值的功能，我认为缺乏（或至少不强调）是动态语言更多地用于应用程序和强类型语言用于大型库的众多原因之一。

Answer 15

我的印象是 Python 没有接口。 据我所知，在Python中你不能强制在编译时实现一个方法，因为它是一种动态语言。

Python 有一些接口库，但我没有使用过。

Python 也有 Mixins，因此您可以通过定义一个 Mixin 来创建一个 Interface 类，并为每个方法实现创建一个 pass ，但这并没有真正给您带来太多价值。

Answer 16

Rene，请阅读我的回答到 StackOverflow 上的“用动态语言构建大型系统的最佳实践”问题。 我讨论了放弃动态语言的自由以节省开发工作并轻松地将新程序员引入项目的一些好处。 如果使用得当，接口将极大地有助于编写可靠的软件。

Answer 17

如果您没有高度的安全约束（因此没有人会以您不想的方式访问您的数据）并且您有良好的文档或训练有素的编码人员（因此他们不需要解释器/编译器来告诉他们要做什么做），那么不，没有用。

对于大多数中型项目，鸭子类型就足够了。