Interfejsy w OOP w PHP

Jak już wiesz, klasy abstrakcyjne reprezentują zestaw metod dla swoich potomków. Część tych metod może być zaimplementowana w samej klasie, a część metod może być zadeklarowana jako abstrakcyjne i wymagać implementacji w klasach potomnych.

Wyobraźmy sobie sytuację, gdy twoja klasa abstrakcyjna reprezentuje tylko zestaw abstrakcyjnych metod publicznych, nie dodając metod z implementacją.

Faktycznie twoja klasa nadrzędna opisuje interfejs potomków, to znaczy zestaw ich publicznych metod, obowiązkowych do zaimplementowania.

Po co nam to potrzebne: aby podczas programowania popełniać mniej błędów - opisując wszystkie niezbędne metody w klasie nadrzędnej, możemy być pewni tego, że wszystkie klasy potomne rzeczywiście je zaimplementują.

Kiedy to pomoże: załóżmy, że stworzymy naszą klasę nadrzędną i kilka klas potomnych do niej. Jeśli potem po jakimś czasie, na przykład, po miesiącu, zdecydujemy się stworzyć jeszcze jedną klasę potomną, na pewno już zapomnimy szczegóły naszego kodu i całkiem możemy zapomnieć napisać implementację jakiejś metody w nowej klasie potomnej. Jednak sam PHP nie pozwoli zgubić metody - i po prostu zwróci błąd.

To samo dotyczy innego programisty, pracującego z twoim projektem. Załóżmy, że kod klasy nadrzędnej napisałeś ty, a potem twój kolega zdecydował się stworzyć jeszcze jedną klasę potomną. Twój kolega również nie będzie mógł zgubić paru metod.

Jest jednak problem: faktycznie zrobiliśmy naszą klasę nadrzędną po to, aby pisać w niej abstrakcyjne metody publiczne, ale my sami lub nasz kolega mamy możliwość przypadkowo dodać do tej klasy metodę niepubliczną lub nieabstrakcyjną.

Załóżmy, że chcemy fizycznie zabronić robienia w klasie nadrzędnej innych metod, oprócz abstrakcyjnych publicznych. W PHP zamiast klas abstrakcyjnych można do tego użyć interfejsów.

Interfejsy reprezentują klasy, u których wszystkie metody są publiczne i nieposiadającymi implementacji. Kod metod muszą implementować klasy potomne interfejsów.

Interfejsy deklaruje się tak samo, jak zwykłe klasy, ale używając słowa kluczowego interface zamiast słowa class.

Dla dziedziczenia po interfejsach używa się nieco innej terminologii: mówi się, że klasy nie dziedziczą po interfejsach, a implementują je. Odpowiednio zamiast słowa extends należy używać słowa kluczowego implements.

Nie można stworzyć obiektu interfejsu. Wszystkie metody interfejsu muszą być zadeklarowane jako public i nie mogą mieć implementacji. Interfejs może mieć tylko metody, ale nie właściwości. Nie można również zrobić interfejsu i klasy z tą samą nazwą.