为什么使用动态/松散类型语言的接口？
我使用 php 工作，接口的概念对我来说似乎有点无用。通过阅读，我了解到接口是“契约设计”的一部分，但至少不保证返回特定类型的类型，实际上不存在任何契约。看起来就像一份合同，上面写着：“我们同意执行以下操作：”——没有任何协议条款。
如果我想保证一个对象有一个方法，那么接口似乎并不是特别有用。如果我尝试调用对象没有的方法，我会收到致命错误，因此我很快发现该类没有具有该名称的方法。如果我想聪明一点，事先检查一个类是否有方法，然后检查接口，并查看该对象是否实现该接口，这似乎并不比直接检查该对象（我会这样做）节省我的时间无论如何，看看该类是否具有该方法，无论它实现或未实现任何接口）。
换句话说，仅仅因为我有一组具有特定名称的方法，并不能保证我有任何特定的行为。如果我保证返回某种类型的变量，我至少对输出会有一些了解，并且我可以编写使用具有该接口的对象的代码，因为我知道我会得到什么它的。如果它返回一个字符串，我可以继续编码，至少可以确定我之后正在处理字符串输出。因此，当指定返回类型时，我至少保证了某些行为。保证行为是接口用途的一部分还是不是？
我唯一能想到的是，当我编写代码时，它可以作为我自己的便利贴，以确保稍后在编写该类时创建某些方法。当我编写代码时，它看起来更像是脚手架；当我实际使用它时，我并没有看到太多好处。因此，对我来说，在创建类时比在编写类时更要保持标准。这种好处似乎并没有真正体现在合同设计的概念中。
使用动态/松散类型语言（如 PHP）中的接口实际上可以获得什么好处？它们是否很棒，或者是更强大的 OO 语言实现的东西，所以 PHP 也实现了它？
I work in php, and the concept of interfaces seems to me a little useless here. From reading, I understand that interfaces are part of "design by contract", but without at least guaranteeing a return of a type of a particular kind, there really isn't any contract. It seems it's like a contract that reads, "We agree to do the following: '' " -- there are no terms of the agreement.
If I want a guarantee that an object has a method, it doesn't seem like interfaces are particularly useful. If I try to call a method that an object doesn't have, I get a Fatal Error, so I find out pretty quickly that that class doesn't have a method with that name. If I want to be smart and check beforehand whether a class has a method, then checking the interface, and seeing whether the object implements that interface doesn't seem to save me any more time than just checking that object directly ( which I would do anyways to see if the class had that method regardless of any interfaces it did or didn't implement).
In other words, just because I have a set of methods that have particular names, that doesn't guarantee me any particular behavior. If I'm guaranteed a return of a variable of a certain type, I at least have some inkling of what the output would be, and I can write code that uses an object with that interface, because I know what I'm getting out of it. If it returns a string, I can continue coding with at least the certainty that I'm dealing with a string output afterward. So I'm guaranteed at least some behavior when a return type is specified. Is guaranteeing behavior part of what interfaces are for, or no?
The only thing I can think of is that when I'm writing code, it serves as a post-it note to myself to be sure to create certain methods when writing that class later on. It seems more like scaffolding for when I'm writing the code; I don't see much benefit from when I'm actually using it. So it's more for me to keep the standard when I'm creating classes than when I'm writing them. This benefit doesn't really seem to be captured in the concept of design by contract.
What benefit(s) do you actually get from using an interface in dynamic/loose-typed languages like PHP? Are they great, or is it something that more robust OO languages implement, so PHP implements it also?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
当您实际期望对象实现方法时，就会使用接口。
例如，如果我正在构建一个数据库包装器并且它支持您在引导程序中注册的行为，那么在运行您的行为（例如，sluggable）之前，我将使用以下方法检查它们是否实现了我的“DB_Wrapper_Behaviour_Interface”：
Interfaces are used when you actually expect an object to implement a method.
For example, if I'm building a DB wrapper and it supports behaviours, which you register yourself in a bootstrap, then before running your behaviours (for example, sluggable), I will check that they implement my "DB_Wrapper_Behaviour_Interface" by using:
如果没有返回类型，按合同进行设计会变得更加困难，但不要忘记支持“告诉”而不是“询问”。
我认为界面就像一种责任。您正在编码并且需要一个协作者。您要求它执行某些操作，因为您正在编写的代码无法执行所有操作。所以你要求另一个对象做某事。界面保证协作者能够完成工作，但隐藏了“如何”完成的部分。
现在您可能会争辩说这里不需要正式合同，因为如果协作者无法执行您要求它执行的操作，系统无论如何都会抛出错误。但我认为这忽略了将接口作为一种责任的意义。
Design by contract is made more difficult without return types, but don't forget to favour 'tell' over 'ask'.
I believe an interface to be something like a responsibility. You are coding and need a collaborator. You ask it to do something because the code you are working on can't do everything. So you're asking another object to do something. An interface guarantees that the collaborator will do the job, but hides the 'how' it's done part.
Now you could argue that there's no need for the formal contract here, since the system will throw an error anyway if the collaborator can't do what you're asking it to do. But I think that misses the point in using interfaces as a responsibility.
遇到致命错误并不总是“容易”。有时，您必须执行特定的模块/操作才能看到您的类中实际上缺少某些内容。
该接口使您能够确保每个方法都已实现并记录这些方法（参数到底是什么，返回值应该是什么样子）。如果参数/值是具有特定结构的数组并且您不想使用类（为了简单起见），这非常有用。
Getting a fatal error is not always "easy". Sometimes you have to go on a specific module/action to see that something is actually missing in your class.
The interface enables you to make sure every method is implemented and to document these method (what the parameters are exactly going to be, what the return values should look like). This is useful if the parameters/values are arrays with a particular structure and you don't want to use classes instead (for the sake of simplicty).
我想指出的是，PHP 5.4 将支持类型提示。现在我认为只有函数参数的类型提示，但我想返回值也会有。 （至少已经有一个 RFC，尽管这是一个非常古老且过时的RFC。）
I want to note, that PHP 5.4 will support type hinting. Right now I think there is only type hinting for function arguments, but I suppose there will be for return values, too. (At least there already is an RFC, though a very old and outdated one.)