接口的全部意义在于为您提供灵活性，使您的类强制实现多个接口，但仍然不允许多重继承。从多个类继承的问题很多，维基百科的页面很好地总结了这些问题。

接口是一种折衷。关于多重继承的大多数问题并不适用于抽象基类，所以现在大多数现代语言禁用多重继承，但却调用抽象基类接口，并允许一个类“实现”任意数量的抽象基类。

在我看来，接口应该优于非函数抽象类。如果性能受到影响，我也不会感到惊讶，因为只实例化了一个对象，而不是解析两个对象，并将它们组合在一起(尽管，我不能确定，我不熟悉OOP PHP的内部工作原理)。

的确，与Java相比，接口没有那么有用/有意义。另一方面，PHP6将引入更多的类型提示，包括返回值的类型提示。这将为PHP接口增加一些价值。

interfaces定义了需要遵循的方法列表(想想API)，而抽象类提供了一些基本/通用的功能，这些功能由子类细化以满足特定需求。

对我来说，使用接口和抽象类之间的区别更多地与代码组织有关，而不是由语言本身强制执行。在为其他开发人员准备代码时，我经常使用它们，以便它们保持在预期的设计模式内。接口是一种“契约式设计”，您的代码同意响应一组规定的API调用，这些API调用可能来自您没有访问权限的代码。

虽然从抽象类继承是一个“是一个”关系，但这并不总是你想要的，实现接口更像是一个“像一个”关系。在某些情况下，这种差异可能相当显著。

例如，假设您有一个抽象类Account，许多其他类都是从这个抽象类扩展而来的(Account的类型等等)。它有一组特定的方法，只适用于该类型组。但是，这些帐户子类中的一些实现了Versionable、Listable或Editable，以便它们可以被扔到期望使用这些api的控制器中。控制器并不关心对象的类型

相比之下，我还可以创建一个不从Account扩展的对象，比如User抽象类，仍然实现Listable和Editable，但不实现Versionable，这在这里没有意义。

通过这种方式，我说FooUser子类不是一个帐户，但确实像一个可编辑对象。同样，BarAccount从Account扩展而来，但不是User子类，而是实现了可编辑、可列表和可版本。

将所有这些可编辑的、可列表的和可版本的api添加到抽象类本身不仅是混乱和丑陋的，而且会重复Account和User中的公共接口，或者强制我的User对象实现Versionable，可能只是抛出一个异常。

我们看到抽象类和接口的相似之处在于它们提供了必须在子类中实现的抽象方法。但是，二者仍有以下差异:

1.接口可以包含抽象方法和常量，但不能包含具体方法和变量。 2.接口中的所有方法都必须在公共可见性中 范围。 3.一个类可以实现多个接口，同时它可以继承 只来自一个抽象类。

                                  interface                      abstract class
the code                     - abstract methods               - abstract methods
                             - constants                      - constants                  
                                                              - concrete methods
                                                              - concrete variables

access modifiers             
                             - public                         - public
                                                              - protected
                                                              - private
                                                                etc.
number of parents          The same class can implement
                           more than 1 interface              The child class can 
                                                              inherit only from 1 abstract class

希望这将有助于任何人理解!

下面是PHP接口的要点

It is used to define required no of methods in class [if you want to load html then id and name is required so in this case interface include setID and setName]. Interface strictly force class to include all the methods define in it. You can only define method in interface with public accessibility. You can also extend interface like class. You can extend interface in php using extends keyword. Extend multiple interface. You can not implement 2 interfaces if both share function with same name. It will throw error.

示例代码:

interface test{
    public function A($i);
    public function B($j = 20);
}

class xyz implements test{
    public function A($a){
        echo "CLASS A Value is ".$a;
    }
    public function B($b){
        echo "CLASS B Value is ".$b;
    }
}
$x = new xyz();
echo $x->A(11);
echo "<br/>";
echo $x->B(10);

接口的存在不是作为类可以扩展的基础，而是作为所需函数的映射。

下面是一个不适合抽象类的接口的例子: 假设我有一个日历应用程序，它允许用户从外部源导入日历数据。我将编写类来处理导入每种类型的数据源(ical, rss, atom, json)，每个类都将实现一个公共接口，以确保它们都具有我的应用程序获取数据所需的公共方法。

<?php

interface ImportableFeed 
{
    public function getEvents();
}

Then when a user adds a new feed I can identify the type of feed it is and use the class developed for that type to import the data. Each class written to import data for a specific feed would have completely different code, there may otherwise be very few similarities between the classes outside of the fact that they are required to implement the interface that allows my application to consume them. If I were to use an abstract class, I could very easily ignore the fact that I have not overridden the getEvents() method which would then break my application in this instance whereas using an interface would not let my app run if ANY of the methods defined in the interface do not exist in the class that implemented it. My app doesn't have to care what class it uses to get data from a feed, only that the methods it needs to get that data are present.

To take this a step further, the interface proves to be extremely useful when I come back to my calendar app with the intent of adding another feed type. Using the ImportableFeed interface means I can continue adding more classes that import different feed types by simply adding new classes that implement this interface. This allows me to add tons of functionality without having to add unnecessarily bulk to my core application since my core application only relies on there being the public methods available that the interface requires so as long as my new feed import classes implement the ImportableFeed interface then I know I can just drop it in place and keep moving.

这只是一个非常简单的开始。然后，我可以创建另一个接口，所有日历类都需要实现该接口，该接口提供了更多特定于类处理的提要类型的功能。另一个很好的例子是验证提要类型的方法，等等。

This goes beyond the question but since I used the example above: Interfaces come with their own set of issues if used in this manner. I find myself needing to ensure the output that is returned from the methods implemented to match the interface and to achieve this I use an IDE that reads PHPDoc blocks and add the return type as a type hint in a PHPDoc block of the interface which will then translate to the concrete class that implements it. My classes that consume the data output from the classes that implement this interface will then at the very least know it's expecting an array returned in this example:

<?php
interface ImportableFeed 
{
    /**
     * @return array
     */
    public function getEvents();
}

没有太多空间来比较抽象类和接口。接口是简单的映射，在实现时要求类具有一组公共接口。