What Is the Point of Interfaces in PHP

What is the point of interfaces in PHP?

The entire point of interfaces is to give you the flexibility to have your class be forced to implement multiple interfaces, but still not allow multiple inheritance. The issues with inheriting from multiple classes are many and varied and the wikipedia page on it sums them up pretty well.

Interfaces are a compromise. Most of the problems with multiple inheritance don't apply to abstract base classes, so most modern languages these days disable multiple inheritance yet call abstract base classes interfaces and allows a class to "implement" as many of those as they want.

Why should I create Interfaces in PHP?

Perhaps a real world example will help to illustrate this. Imagine you need to build a series of logging classes that record messages to various media such as a text file, XML or a database. Each class needs to have separate code to interact with the different types of storage of course. However if they all implement the same interface the 'public face' that they show to other code is always the same. In that way other code that uses logging objects doesn't need to know what class they are instances of or what the storage medium is. All that they need to know is that all of the logging classes, by virtue of the fact that they all implement the same interface, share a common API. This can be a very powerful way of working. You can build up a library of code that solves related problems in different ways and simply 'plug and play' these in your code.

When to use Interfaces in PHP

From what I understand you use an Interface to enforce or guarantee
that when a Class is using an Interface that that class will have the
methods defined in the Interface inside of that class.

This is actually only half of the deal (the technical part). There's also the all-important architectural half, which appears when you consume the interface and it goes like this:

function feed(IAnimal $interface) {
    // ...
}

(alternatively, a "factory" function that is documented to return an instance that implements IAnimal would also serve as an example).

The idea here is that the consumer of the interface says: "I want an animal to feed. I don't care if it flies, walks, or crawls. I don't care if it's big or small. I only care that it shares some features with all other animals" -- features that would comprise the definition of the interface.

In other words, interfaces serve to abstract the contract (interface) from the concrete implementation (classes). This gives implementers of concrete classes a free hand to modify, rename, remove and add implementations without breaking the code for users of the interface, something that is not possible if you are referencing concrete classes directly in your API.

As for the interface that is implemented by one class only: that's not enough information to decide. If there can plausibly be more implementations of the interface in the future, then it certainly does make sense (for example: an IHashFunction interface would make sense even if Sha1HashFunction were currently the only available implementation). Otherwise it doesn't offer anything.

What is the point of interfaces in a weakly-typed language like PHP?

Interfaces cause your program to fail earlier and more predictably when a subclass "forgets" to implement some abstract method in its parent class.

In PHP's traditional OOP, you had to rely on something like the following to issue a run-time error:

class Base_interface {
    function implement_me() { assert(false); }
}

class Child extends Base_interface {
}

With an interface, you get immediate feedback when one of your interface's subclasses doesn't implement such a method, at the time the subclass is declared rather than later during its use.

When are object interfaces useful in PHP?

Short answer: uniform interfaces and polymorphism.

Longer answer: you can obviously just create a class that does everything and indeed you'd know what methods to write. The problem you have with using just concrete classes, however, is your lack of ability to change. Say you have a class that stores your users into a MySQL database, let's call it a UserRepository. Imagine the following code:

<?php
class UserRepositoryMysql {
    public function save( User $user ) {
        // save the user.
    }
}

class Client {
    public function __construct( UserRepositoryMysql $repos ) {
        $this->repos = $repos;
    }

    public function save( User $user ) {
       $this->repos->save( $user );
    }
}

Now, this is all good, as it would actually work, and save the User to the database. But imagine your application will become populair, and soon, there is a question to support PostgreSQL as well. You'll have to write a UserRepositoryPostgresql class, and pass that along instead of UserRepositoryMysql. Now, you've typehinted on UserRepositoryMysql, plus you're not certain both repositories use the same methods. As an aside, there is little documentation for a potential new developer on how to implement his own storage.

When you rewrite the Client class to be dependent upon an interface, instead of a concrete class, you'll have an option to "swap them out". This is why interfaces are useful, obviously, when applied correctly.

---

Related Topics