为什么接口在动态/松散
我在PHP工作，接口的概念在这里似乎有点无用。 从阅读中我了解到接口是“按合同设计”的一部分，但是至少没有保证返回某种特定类型，实际上没有任何合同。 这看起来像是一个合同，上面写着：“我们同意做以下事情：''' - 协议没有条款。
如果我想保证一个对象有一个方法，它看起来并不像接口那样特别有用。 如果我尝试调用某个对象没有的方法，那么我会遇到致命错误，所以我很快发现该类没有具有该名称的方法。 如果我想聪明一点，事先检查一个类是否有方法，然后检查接口，并查看对象是否实现了该接口，这似乎不会为我节省更多时间，而不仅仅是直接检查该对象（我会这样做反正看看这个类是否有这个方法，而不管它有没有或没有实现的接口）。
换句话说，仅仅因为我有一组具有特定名称的方法，并不能保证我有任何特定的行为。 如果我保证返回某个类型的变量，那么我至少会对输出结果有所了解，并且我可以编写使用该接口的对象的代码，因为我知道我要输出什么内容的。 如果它返回一个字符串，我可以继续编码，至少可以确定我正在处理一个字符串输出。 所以我保证至少有一些行为时指定返回类型。 保证行为是接口的一部分，还是不行？
我能想到的唯一的事情是，当我编写代码时，它会作为一个便笺给我自己，以便在稍后编写该类时确保创建某些方法。 当我编写代码时，它似乎更像脚手架; 当我真正使用它时，我看不到什么好处。 因此，当我创建课程时比我写作时更重要的是保持标准。 这个好处似乎并没有被合约设计概念所捕捉。
在PHP等动态/松散类型语言中使用接口实际上会带来哪些好处？ 它们很棒，还是更健壮的OO语言实现的东西，所以PHP也实现了它？
当你真正希望一个对象实现一个方法时，使用接口。
例如，如果我正在构建一个数据库包装器，并且它支持在引导程序中注册自己的行为，那么在运行您的行为（例如可扼杀）之前，我会检查他们是否使用以下代码实现了我的“DB_Wrapper_Behaviour_Interface”
if(!($behaviourObject instanceof DB_Wrapper_Behaviour_Interface)) {
throw new Exception("Your behaviour doesn't implement my interface");
}
如果没有退货类型，通过合同设计会变得更加困难，但不要忘记在'问'上倾向'告诉'。
我相信一个界面就像是一种责任。 你正在编码，需要一个合作者。 你要求它做一些事情，因为你正在处理的代码不能做所有事情。 所以你要求另一个对象去做一些事情。 一个接口保证协作者将完成这项工作，但隐藏了“如何完成”的一部分。
现在你可以争辩说，这里不需要正式的合同，因为如果合作者不能做你要求的事情，那么系统会抛出一个错误。 但我认为这忽略了使用接口作为一项责任。
获得致命错误并不总是“容易”。 有时你必须继续进行特定的模块/操作，才能发现课堂中实际上缺少的东西。 该接口使您可以确保实现每个方法并记录这些方法（参数的确切内容，返回值的外观）。 如果参数/值是具有特定结构的数组并且您不想使用类（为了简单起见），这非常有用。
链接地址: http://www.djcxy.com/p/47519.html