PHP/Interfejsy: Różnice pomiędzy wersjami

Usunięta treść Dodana treść
Zyx (dyskusja | edycje)
dokończenie
zapomniany szablon, WP:SK
Linia 1:
{{SdU}}
<div class="noprint">{{prognaw|PHP|[[../Dziedziczenie|Dziedziczenie]]|[[../Wyjątki|Wyjątki]]}}</div>
 
Linia 20 ⟶ 21:
 
=== Przykładowe użycie ===
 
Rozpatrzmy prosty system uprawnień. Główna klasa stanowi interfejs dostępu, który potrafi odpowiadać na pytania, czy użytkownik powinien mieć dostęp do wskazanego zasobu. Oprócz tego chcemy mieć zestaw innych klas, które potrafiłyby generować listę uprawnień dla naszego systemu. Nie chcemy ograniczać możliwości ich dziedziczenia, dlatego zamiast tego utworzymy interfejs opisujący, czego system uprawnień wymaga od twórcy generatora uprawnień, aby mógł on poprawnie działać.
 
Linia 149:
 
=== Dziedziczenie interfejsów ===
 
Interfejsy można również dziedziczyć dokładnie tak samo, jak klasy, przy pomocy słowa kluczowego '''extends'''. Tutaj jednak wielokrotne dziedziczenie jest jak najbardziej dozwolone pod warunkiem, że nie ma konfliktów metod. Dziedziczenie interfejsów jest rzadko spotykane w rzeczywistych skryptach, lecz warto wiedzieć, że ono istnieje. Poniżej przedstawiony jest przykładowy skrypt pokazujący sposób wykorzystania i działanie:
 
Linia 204 ⟶ 203:
 
=== Interfejsy wbudowane ===
 
Język PHP posiada kilkanaście specjalnych interfejsów rozpoznawanych przez interpreter i przeznaczonych do dodatkowych zastosowań. Wchodzą one w skład tzw. ''Standard PHP Library'', czyli nowej standardowej biblioteki PHP zbudowanej w całości w oparciu o programowanie obiektowe. Będziemy się z nią zapoznawać po kawałku również w dalszej części podręcznika.
 
Linia 277 ⟶ 275:
 
=== Kiedy stosować? ===
 
Nie ma jednej, uniwersalnej reguły mówiącej, kiedy należy stosować interfejsy, a kiedy dziedziczenie klas. Zasadniczo gdy chcemy dostarczyć klasie użytkownika pewną, gotową część implementacji, jesteśmy skazani na dziedziczenie, gdyż PHP nie udostępnia żadnych innych mechanizmów jej wstrzykiwania. Jednak gdy pragniemy jedynie zdefiniować listę zachowań, których oczekujemy, bez wnikania w szczegóły ich działania, interfejsy są o wiele lepszym pomysłem, gdyż mogą być implementowane niezależnie oraz nie zamykają drogi do dziedziczenia. To do nas, jako projektantów architektury aplikacji, należy odpowiedź na jakiej funkcjonalności najbardziej nam zależy i odpowiednio wybrać dostępne środki. Polecamy analizować obiektowo napisane skrypty i biblioteki, aby zapoznać się z ich budową. Naśladowanie dobrych wzorców to jedna z najlepszych szkół.
 
Linia 283 ⟶ 280:
 
== Zakończenie ==
 
Poznaliśmy już prawie wszystkie główne mechanizmy obiektowe, które dostarcza nam PHP. Interfejsy znacząco poszerzyły nasze możliwości wyrażania zależności między klasami. Kolejny rozdział poświęcony będzie profesjonalnym mechanizmom raportowania błędów przy pomocy ''wyjątków''. Od strony technicznej nie są one częścią programowania obiektowego, lecz w PHP silnie na nim bazują i dlatego ich omówienie znajduje się właśnie tutaj.