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

Question

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

Navigation

#1 by (13 votes)
#2 by (6 votes)

14

I've always wanted to know exactly, if it's a good practice, to make a system always using Interfaces, or is it 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;
  }

}

php interface polimorfismo psr-4

asked by anonymous 26.11.2015 / 12:45

2 answers

6

The main advantage I see of this in PHP is the issue of providing programmer flexibility in the case of using a library where it implements its own feature.

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

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

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

As the typing of the data is done through PersistentDataInterface , I implemented it, causing the methods to save and retrieve data from the session of Laravel .

So, everything worked correctly.

Then look at 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 of class Library requires typing to be the implementation of interface , and not classe itself. So, this gives me more flexibility so that I create another class with the interface methods, but they persist the data differently!

I think using the interface is good practice when you want to offer more ways for your library to interact with other classes. Because you "force" the third class to use the methods through the interface, you can call a method of the object passed by parameter without "being afraid" that the method does not exist and have to be doing thousands of ifs with% / p>

THE FUTURE

In method_exists it will be wonderful to combine the interfaces feature with PHP7 , as this gives you even more flexibility. See for example, in the case above, 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);

26.11.2015 / 12:59

How to list methods of a class in C #? What is FastExpando / FastExpandoObject?

score 13 · Accepted Answer

Necessary is not, but is good for several reasons. Documenting really is one of them.

Giving more robustness to the code is another.

I just do not quite understand how dynamic typing languages invest so much in this, it seems to go against your own philosophy of letting the tests or programmer's intuition detect errors.

The interface is a contract that should be followed when implementing.

The data typing as well. I do not know why they ignore one form and follow another. Perhaps the languages themselves are admitting gradually that they used a wrong typing philosophy.

So at a higher level you have to ask yourself this: why will you use a protective measure in a language that ignores other, more important protective measures? Few ask themselves this question. And many who do it seriously and be able to respond, will decide to change language.

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

It also generalizes (abstracts) what it is intended to do. And that's good. This is an even better reason to use interface. I will not explain in detail here because I already have an answer about this .

In summary, 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 implementing it can be used in a concrete way to satisfy a specific algorithm. This makes it easy to maintain and configure the application. You do not get caught up in the concrete implementation. The advantages are described in the linked question above.