Interface'y - kiedy stosować?

Question

Zastanawiałem się nad zastosowaniem interface'ów w php i natrafiłem na coś takiego :

PRIMARY PURPOSES OF AN INTERFACE:

• Interfaces allow you to define/create a common structure for your classes – to set a standard for objects.
• Interfaces solves the problem of single inheritance – they allow you to inject ‘qualities’ from multiple sources.
• Interfaces provide a flexible base/root structure that you don’t get with classes.
• Interfaces are great when you have multiple coders working on a project – you can set up a loose structure for programmers to follow and let them worry about the details.

WHEN SHOULD YOU MAKE A CLASS AND WHEN SHOULD YOU MAKE AN INTEFACE?

• If you have a class that is never directly instantiated in your program, this is a good candidate for an interface. In other words, if you are creating a class to only serve as the parent to other classes, it should probably be made into an interface.
• When you know what methods a class should have but you are not sure what the details will be.
• When you want to quickly map out the basic structures of your classes to serve as a template for others to follow – keeps the code-base predictable and consistent. 

https://www.killerphp.com/articles/php-interfaces/

Co o tym sądzicie? Coś dodać, coś ująć?

Answer 1

Interfejsy warto stosować jako type-hint parametru metody, która oczekuje pewnych zależności płynących z tego parametru. Jest to wymuszenie i pewien kontrakt między programistami pracującymi w danym projekcie. A nawet i sobą samym, ponieważ po jakimś czasie możesz zapomnieć o tym, że musisz dostarczyć funkcji jakieś zależności. W momencie testowania gdy zapomnisz uwzględnić danego przypadku, to na produkcji może dojść do błędów. Jeżeli oczekujesz interfejsu a go nie dostaniesz, to po odświeżeniu strony od razu się dowiesz o tym że tego nie zrobiłeś i po prostu podepniesz interfejs pod klasę i zaimplementujesz metody.

Teraz przykład. Załóżmy, że chcesz napisać program, w którym będziesz sterował pojazdem. Implementacja mogłaby wyglądać w ten sposób.

class Car
{
    public function turnLeft(): void
    {
        // code  
    }
}

class Program
{
    public function main($car): void
    {
           $car->turnLeft();
    }
}

Ale nie mamy pewności czy aby na pewno zmienna car w metodzie main() posiada taką funkcje jak turnLeft(). Może to prowadzić do błędów. Aby się upewnić że możemy takiej metody użyć, moglibyśmy zapisać to w ten sposób.

class Car
{
    public function turnLeft(): void
    {
        // code  
    }
}

class Program
{
    public function main(Car $car): void
    {
           $car->turnLeft();
    }
}

Teraz jest już lepiej, ale i tak nie jest to dobrze zbudowana aplikacja. Co jeżeli chcielibyśmy dodać sterowanie innym pojazdem do naszej funkcji main() ? Może zamiast typowania parametru jako Car, powinniśmy pomyśleć o czymś czego dana metoda wymaga do działania, a niekoniecznie martwić się o mechanizmy, które potrzebuje aby była wykonana? W myśl 5 zasady SOLID, parametry powinniśmy uzależniać od abstrakcji.

interface Vehicle
{
    public function turnLeft(): void
}

class Car implements Vehicle
{
    public function turnLeft(): void
    {
        // code  
    }
}

class Motocycle implements Vehicle
{
    public function turnLeft(): void
    {
        // code  
        $this->cośTuMuszęPoliczyć();
    }

    private function cośTuMuszęPoliczyć()
    {
        // code
    }
}

class Program
{
    public function main(Vehicle $vehicle): void
    {
           $vehicle->turnLeft();
    }
}

Tutaj abstrakcja jest dosyć powiązana i zamiast interfejsu Vehicle moglibyśmy zrobić klasę abstrakcyjną z abstrakcyjną metodą turnLeft()

 

Jeżeli używasz IDE np PHPStorm, to dodatkowo zyskasz podpowiedzi co dana zmienna zawiera.

Comments

Nie do końca obczaiłem SOLIDne zasady jeszcze, ale na pewno to zrobię i przeczytam jeszcze raz Twój post. Dzięki za obszerną wypowiedź.

Answer 2

Zawsze każdą zależność typu serwis-serwis pokrywam interfejsem. Zmniejsza to zależność, serwisy nie są zależne od siebie, istnieje tylko kontrakt wykonania czegoś.

Taki kod o wiele łatwiej się również testuje. Poza tym mając wzorzec DI wymiana implementacji jest prosta.