How and when should we use Interface to document systems in PHP?

Question

I always wondered exactly, if it is a good practice, to make a system always making use of Interfaces, or this is not necessary?

Interface People {
  public function getName();
  public function setName($string);
  public function getAge();
  public function setAge($string);
}

class User implements People {

  private $name;
  private $age;

  public function __construct()
  {
   return $this; 
  }

  public function setName($string)
  {
     $this->name = $string;
     return $this;
  }

  public function getName()
  {
    return $this->name;
  }

  public function setAge($number)
  {
    $this->age = $number;
    return $this;
  }

  public function getAge()
  {
    return $this->age;
  }

}

Answer 1

Necessary is not, but it is good for several reasons, documenting really is one of them, give more robustness in the code is another.

I just don’t quite understand how dynamic typing languages invest so much in this, it seems to go against their own philosophy of letting the programmer’s tests or intuition detect errors. Even worse when the language is weak.

The interface is a contract which should be followed when making an implementation. Data typing is also a contract. I don’t know why they ignore one form and follow another. Perhaps the languages themselves are gradually admitting that they used a wrong typing philosophy, at least for the most important purposes.

There are languages of script and languages Nterprise, among others, PHP was a language of script who now wants to be a language Nterprise, but the legacy does not allow to make this transition.

Then on a higher level one should ask: why will you use a protective measure in a language that leaves aside other more important protective measures? Few ask this question, and many who do it seriously and can answer it, will decide to change their language.

Of course some protective measure is better than nothing, it is advantageous in itself, not only for this.

It also generalizes (abstract) what it is intended to do, and that’s good. This is an even better reason to use interface. I won’t explain in detail here because already there’s an answer on that.

In short, when we have the interface implemented we can use it to indicate that only what is present in it is what we need. And that any class that implements it can be used concretely to satisfy a specific algorithm. This makes it easy to maintain and configure the application. You don’t stick to the concrete implementation. The advantages are described in the question linked above.

Other languages of script more coherent prefer the Duck Typing.

See more in What is typing style?.

Answer 2

The main advantage I see of this in PHP is the question of providing flexibility to the programmer in the case of using a library where he implements his own resource.

In this case, the programmer could simply use his own class, provided that he implements the interface required to perform such an operation.

An example: These days, I was having trouble with the Facebook library, because I use the Laravel, and the Laravel does not use the native PHP session. Facebook uses the native PHP session. The result is that it was having trouble.

The class of Facebook implements an interface called PersistentDataInterface. This interface had the methods set and get, needed to determine how the data would be saved in the session.

How data typing is done through PersistentDataInterface, I implemented it, causing the methods to save and obtain data directly from the Laravel.

So everything worked out correctly.

So here’s an example:

interface PersistentData {
    public function set($key, $value);
    public function get($key);
}

class Library{
      public function __construct(PersistentData $persist)
      {
            $this->persist = $persist;
      } 
}

class ClasseQueNaoAtendeMeuSistema implements PersistentData
{
     public function set($key, $value) { ... }
     public function get($key);
}

In this case, the construtor class Library requires typing to be the implementation of interface, and not of classe in itself. Therefore, this gives greater flexibility for me to create another class with the interface methods, but that make the data persistence differently!

I believe that using the interface is a good practice when you want to offer more ways your library can interact with other classes. As you "force" the third class to use the methods through the interface, you can call an object method passed by parameter without "being afraid" that the method does not exist and have to keep making thousands of ifs with method_exists.

THE FUTURE

In the PHP7 it will be wonderful to join the resource of the interfaces with the classes anônimas, as this gives even more flexibility. See for example, in the above case, what could be done.

$tempPersist = new class(Database::connection()) implements PersistentData
{
    public function __construct(Database $database)
    {
         $this->database = $database;
    }
    public function set($key, $value)
    {
       $this->database->table('session')->save([$key=>$value]);
    }  

    public function get($key)
    {
         return $this->database->table('session')->get($key);
    }
   
}


 $lib = new Library($tempPersist);