Why does PHP have interfaces?

@pjskeptic has a good answer, and @Kamil Tomšík has a good comment on that answer.

The great thing about dynamically typed languages like PHP is that you can try to use methods on objects and it won't scream at you unless the method isn't there.

The issue with dynamically typed languages like PHP is that you can try to use methods on objects and it will scream at you when the method isn't there.

Interfaces add a convenient way of calling methods on an unknown object and being certain that the methods are there (not that they're necessarily correct or going to work). It's not a necessary part of a language, but it makes coding more convenient. It allows strongly typed OOP developers to write strongly typed PHP code, which can then work alongside loosely typed PHP code written by a different PHP developer.

a function like:

foo( IBar $bar )
{
  $baz = $bar->baz();
  ...
}

is more convenient than:

foo( $bar )
{
  if ( method_exists( $bar, 'baz' ) )
  {
    $baz = $bar->baz();
  }
  else
  {
    throw new Exception('OMGWTF NO BAZ IN BAR!');
  }
  ...
}

and IMHO simple, readable code is better code.

PHP is loosely typed, but it can be strongly typed about things like method parameters.

Consider the following example:

interface Car { function go(); }

class Porsche { function go() {} }

function drive(Car $car) {}

$porsche = new Porsche();

drive($porsche);

The above code would output:

Argument 1 passed to drive() must implement interface Car, instance of Porsche given

PHP is not loosely or strongly, but dynamically typed.

About interfaces, the first thing you should ask yourself is: what are most of the benefits of interfaces?

In OOP, interfaces are not just about types, but about behaviour as well.

Since PHP also has a type hint feature, you can use interfaces just as you would in a pure oo language, such as Java.

interface File
{
    public function getLines();
}

CSVFile implements File
{
    public function getLines()
    {}
}

XMLFile implements File 
{
    public function getLines()
    {}
}

JSONFile implements File 
{
    public function getLines()
    {}
}

class FileReader
{
    public function read(File $file)
    {
        foreach($file->getLines() as $line)
        {
            // do something
        }
    }
}

With PHP interface implementation, you cal also create mocks for abstract classes using PHPUnit - and this is a hell of a feature:

public function testSomething()
{
    $mock = $this->getMockForAbstractClass('File');

    $mock->expects($this->once())
         ->method('getLines')
         ->will($this->returnValue(array()));

    // do your assertions
}

So, basically, you can have a SOLID compatible application in PHP by using the language features, one of them being interfaces.

Interfaces allow you to implement the open-closed principle, maintain a loosely coupled code base, and implement many of the best OOP design patterns.

For instance, if one class accepts another class as an argument:

class A {

    public function __construct(B $class_b) {
        // use class b
        $class_b->run();
    }
}

Your class A and class B now have a tight coupling, and class A cannot use any other class except B. The type hinting makes sure that you have the correct type of argument, but has now cemented the relationship between A and B.

Lets say that you want class A to be able to use all types of classes that have a run() method however. This is basically (but not quite) the COMMAND design pattern. To solve, you would instead type hint using an interface instead of a concrete class. B would them implement that interface, and will be accepted as an argument for class A. This way class A can accept any class that uses that interface as an argument for its constructor.

This type of coding is used in most OOP design patterns, and allows for MUCH easier changes of code at a later time. These are part of the fundamentals of AGILE programming.

Interfaces are useful for dependency injection much more so than concrete. As a barebones example :

interface Istore { 
  public function save(); 
}

class Article_DB implements Istore 
{ 
  public function save($data) 
  {
    // do save to format needed.
  } 
}

class Article
{
   private $content;

   public function content($content)
   {
     $this->content = $content;
   }

   public function save(Istore $store)
   {
     $store->save($this->content);
   }
}

$article = new Article();
$article->content('Some content');

$store = new Article_DB();
$article->save($store);

Now say if your needs change and you want to save to a pdf. You could create a a new class for that purpose instead of polluting the Article class.

class Article_PDF implements Istore 
{ 
  public function save($data) 
  {
    // do save to format needed.
  } 
}


$article = new Article();
$article->content('Some content');

$store = new Article_PDF();
$article->save($store);

The Article class now has a contract that classes it uses to save must implement the Istore interface. It does not care where it saves or how it saves.

They're completely useless if you're duck-typer, actually when you do duck-typing, it's pretty annoying to work with libraries/framework which use any type-hinting.

This applies also for all sorts of dynamic meta-programming (magic methods).

It's the only way PHP has to deal with lack of support for multiple inheritance — class can implement multiple interfaces.

You can provide "Fake" real objects that implement the interface. You could then unit test a part of your code without requiring real servers, file systems, sockets, databases etc.