Witam,

Nawiązując do http://forum.php.pl/index.php?showtopic=64555&st=80 chciałem troszkę rozjaśnić swoje zdanie na temat obiektowości w programach. Rozumiem koncept OOP i dzielenia aplikacji na obiekty - logiczne, wszystko dzieli się według zastosowania. Ale OOP to nie tylko taki podział. Potem dochodzą do tego interfejsy oraz klasy abstrakcyjne. Rozumiem interfejs, ale czemu interfejs nie może być normalną klasą, przecież i tak nie ma być wykorzystywany w programie? To tak jakby sucha kromka chleba miała być niejadalna, bo jest tylko interfejsem do kromki z serem. A jest jadalna - tylko większość osób kładzie na nią dodatkowo ser czy cośtam. I teraz klasy abstrakcyjne. Rozumiem, że obiekty mają hierarchię, ale po co klasy abstrakcyjne? Jeżeli są to klasy, których nie nalaży używać, to wystarczy ich nie używać - na pewno są przecież bezużyteczne, inaczej nie byłyby abstrakcyjne.

Dlatego mam czasami wrażenie, że OOP to nie tylko standart projektowania, ale również inny troszkę tok myślenia. Rozumiem, że programista musi założyć, że użytkownicy to idioci. Bo oni mogą się nie znać. Ale jeżeli ktoś pisze jakąś obiektową bibliotekę, albo jeszcze gorzej strukturę programu dla siebie, to nie musi wychodzić z założenia, że jest idiotą. Jeżeli programista jest idiotą to jego sprawa, bo jego program i tak nie będzie działał - nie potrzeba do tego warningów/errorów kompilatora/interpretera. Tak samo metody prywatne. Jeżeli w dokumentacji będzie wspomniane nie używać, to mądry programista ich i tak nie użyje, a sprytny użyje i też będzie ok.

Dlatego nie rozumiem, po co w OOP ten cały mechanizm zabezpieczania programów przed... programistami, którzy je piszą?

Pozdrawiam

Moim zdaniem źle podszedłeś do sprawy. Zły przykład i nietrafne argumenty.

Jak już się przyczepiłeś tej kromki chleba... z czego ona powstała? Ze zboża, czy zbożem się najesz? nie, kromka chleba, bułka, rogalik itp dziedziczą po zbożu, który jest odpowiednio obrabiany. Załóż, że zboże to pewnien standard produkcji pieczywa, nie wyprodukujesz go z plastku. Teraz przykład w php.

Mamy abstrakcyjny kontroler z pewnymi metodami, np api __get(), __set(), itp. Wśród nich jest także metoda index() uwględniona w interfejsie, jaki ten abstrakcyjny obiet implementuje. Index to swego rodzaju przymus (standard pieczywa) działania kontorlera, gdyż bez niego (w wypatku braku akcji) zostanie on ewentualnie odpalony. Czym jest dla porównania metoda abstrakcyjna? Może w niej zostać zaprojektowane zupełnie co innego dla dziecka niż dla rodzica, z tym że dziecko potrzebuje metody rodzica. Przykład? obróbka danych:

[PHP] pobierz, plaintext 
<?php
 
interface ObrabiarkaTablic
{
  function obrobka($aTablica);
}
 
class Rodzic
{
  abstract function obrobka($aTablica)
  {
	// wykonanie jakis operacji
	return $aTablica;
  }
}
 
class Dziecko extends Rodzic implements ObrabiarkaTablic
{
  public function obrobka($aTablica)
  {
	// poprzednia filtracja danych:
	$aTablica = parent::obrobka($aTablica);
	// inna przerobka danych
}
 
?>
[PHP] pobierz, plaintext 

To są mechanizmy języka. Skoro powstało pojęcie klasy abstrakcyjnej, to dla mnie jak najbardziej w porządku jest włączenie tego do języka (czyli wyskakujące błędy, gdy taki obiekt stworzę).



Zapewne nigdy nie rozwijałeś kodu po innym programiście, albo nie wracałeś do swojego projektu po długiej przerwie. Spróbuj kiedyś.



Widzisz, naprawdę tu powinno sie przytoczyć jakieś cytaty z mądrych książek i najlepiej kilka real life examples. Istnieją metody prywatne i metody publiczne, do jednych jest dostęp z zewnątrz obiektu, do innych nie ma - koniec i kropka. Jeżeli uzywam tego przy programowaniu, używam tego nie bez kozery.



Sam sobie odpowiedziałeś, to zabezpiecza programistę - sprawia, że mozliwości popełnienia błędu maleją.



No, cześć, cześć smilingsmiley.gif

Dzieki za wyjaśnienie, rozumiem w czym rzecz.

Czyli jak widzę OOP to rzeczywiście bardziej dziecko inżynieri programowania niż np. algorytmiki. Może dlatego nie całkiem mogę to pojąć, choć widzę zalety.

Pozdrawiam

Tylko w opisie pojawił się pewien bug, bo bułki/chleb agregują zboże (czy raczej pieczywo to robi, i dodatkowo inne składniki), a nie dziedziczą... a bułki i chlew dziedziczą po pieczywo (mniej więcej, zleży jak to dokładnie rozpisywać)

To już bardziej dziedziczenie wielopoziomowe, nie chciałem tutaj wprowadzać kogoś w obszar głębszego rozmyślania, tylko podac jakis przykład, ale słuszna uwaga



Z czasem, jak nabierzesz więcej doświadczenia, będziesz całował interfejsy i abstrakty po nogach - gwarantuję. Teraz póki co dostałeś suche przykłady, postaraj się je wykorzysać we wzorcach projektowych, zobaczysz, że naprawdę się przydają i coś z tego de facto jest.

To w sumie pokazuje jeszcze jedno, gdyż pieczywo jest interfejsem (lub abstrakcją, zależy jak zdefiniujemy) to chyba logiczne jest, że nie można tworzyć obiektu tego typu, bo takie coś nie może istnieć, dlatego kompilator/interpreter powinien wyrzucić błąd.

Ja się jeszcze dorzucę.

Interfejsy w językach skryptowych odgrywają trochę inną rolę niż w językach kompilowanych.

Interfejsy w językach kompilowanych:
W językach kompilowanych interfejs daje możliwość symulowania dziedziczenia wielobazowego przy językach, które jako takiego dziedziczenia wielobazowego klas nie mają. Poza tym, interfejsy narzucają specyfikację i jakby karzą bezwzględnie tej specyfikacji się trzymać, znaczy się dla autorów klas które będą implementować dany interfejs. Następną i chyba główną cechą interfejsów w językach kompilowanych jest możliwość sterowania obiektem zdalnie, znaczy się jedna aplikacja może sterować obiektem który istnieje w innej aplikacji (programowanie rozproszone).


W językach skryptowych:
Tutaj interfejs jakby traci swoją moc dawania możliwości symulowania dziedziczenia wielobazowego, ponieważ język skryptowy metody wywołuje i tak po nazwach (tzw. późne wiązania). Narzucanie pewnej specyfikacji pozostaje tj dla języków kompilowalnych, natomiast jeśli chodzi o programowanie rozproszone to szczerze mówiąc nie wiem jak to jest w PHP, nic mi nie wiadomo żeby interfejsy w tym pomagały, zresztą cieżko mi sobie wyobrazić programowanie rozproszone w PHP No, chyba że tylko jako aplikacja kliencka.


Pozwiodronka,
Zeman.


Aha, co do klas abstrakcyjnych, to jest takie narzucanie pewnej specyfikacji autorom klas chcącym dziedziczyć po danej klasie abstrakcyjnej.

Co do metod prywatnych (private), chronionych (protected) i publicznych (public), to jest to swego rodzaju umożliwienie pisania metod na wewnętrzny użytek klasy i eśli ktoś chciałby dziedziczyć po klasie i używać tych metod, to już nie może, wtedy metoda musi być conajmniej protected. Prosze mi uwierzyć że chowanie metod ma sens - niekiedy metoda niespecjalnie się nadaje do użytku z zewnątrz, a programista nie będący autorem danej klasy może popsuć skrypt jak jej nieumiejętnie użyje. Poza tym, utrzymuje porządek, nie kusi żeby kombinować (choć może i bardziej kusić).

Osobiście w PHP zwykłem często używać private, protected i public dla metod i pól, oraz często static. Interfejsów w PHP osobiście nie używam, ale w Delphi niemalże wszędzie.

Chyba coś Ci się pomieszało, bo protected nie pozwala na uruchomienie metody z zewnątrz ale jest dziedziczone, aby nie można było dziedziczyć to private aby nie można było nadpisać final.

Nie nie pomieszało mi się nic, bo napisałem jeśli ktoś chciałby dziedziczyć po klasie i używać jej metod, może tylko dla jasności nie dopisałem że w klasie dziedziczonej.

Ale przy protected w klasie dziedziczącej jest widoczna, właśnie po to się ustawia tą widoczność aby nie można było jej z zewnątrz wywołać, ale w klasie dziedziczącej jak najbardziej.
Zacytuję, bo chyba tego nie widzisz:

wtedy musi być private

No to sie chyba faktycznie nie rozumiemy, bo poprawiasz mnie tak samo ja ja piszę.
Podsumowywując krótko i jednoznacznie:
private - metoda widoczna tylko w klasie w ktorej jest definicja tej metody, niewidoczna w klasach potomnych ani poza klasą
protected - tj private a dodatkowo widoczna w klasach potomnych
public - tj protected a dodatkowo poza klasą

Dziwisz się później, że nikt Cię nie rozumie. Napisz to jak po ludzku a nie się bawisz
Jak protected to protected a nie jakieś "ale".

private - składowe klasy (pola, funkcje) widoczne (czyli dostęp do niech) tylko i wyłącznie wewnątrz klasy;
protected - składowe klasy, do których dostęp jest z wewnątrz klasy oraz wewnątrz klas dziedziczących.
public - składowe klasy do których dostęp można uzyskać w dowolnym miejscu aplikacji.

W mojej skromnej opinii, klasy abstrakcyjne, finale i interfejsy, to błogosławieństwo. Wiem to z doświadczenia, bo kod którego używam rozwijałem przez ponad rok w różnych odstępach czasu. Z dużą ilość modyfikacji, różnymi stylami programowania, ale zgodnie z OOP i teraz poprawia oraz używa się to cudownie.

Specjalnie dla niedomyślnego pana Athlana uzasadnienie:
Mam ok. 50 klas, które były pisane na przestrzeni 1 roku i gdyby nie jasno zdefiniowane interfejsy itp. , miałbym spore problemy, z powrotem do programowania, po przerwie jaką sobie ostatnio zrobiłem (2 miesiące).

dołączę się do tematu klasa Rodzic musi być abstrakcyjna chyba, tak

kurde czegoś tu nie rozumiem, no po co tak robić
class Dziecko extends Rodzic implements ObrabiarkaTablic
nie można by tylko
class Dziecko extends Rodzic
bo jakoś oprócz tego że wymuszają w klasie która dziedziczy zaimplementowanie odpowiednch funkcji nie widzę idei proszę o jaśniejsze wytłumaczenie po co to używamy

Interfejsy zostaly wziete z Javy, gdzie zmienna musi miec typ:

a to wszystko po to zeby mozna bylo wykonac

bo kompilator musi wiedziec czy na obiekcie 'ot mozna wywolac obrobka().

W PHP nie ma typowania zmiennych i mamy duck-typing, tzn. jesli na obiekcie wywolamy metode a on ja posiada to jest OK, czyli -> interfejsy sa niepotrzebne od strony wykonania, 'kompilacji' a bardziej do dokumentacji kodu, ogarniecia jego struktury

Tu po prostu Rodzic powinien implementować ObrabiarkaTablic, a wtedy nie trzeba dzieciom tego pisać, bo to jest z rodzica (jeśli się nie mylę przy takiej składni w Java też by nie było problemu)
A dodanie interfejsu to raczej kiedy rozszerzany jest rodzica, np. amfibia dziedziczy po samochodach, ale też implementuje łodzie, bo może pływać

czyli przy każtym projekcie robić sobie klasy abstrakcyjne i interfejsy


czyli wielodziedziczenie

oprócz tych dwóch, są jeszcze jakieś zastosowania ?

--EDIT
przeczytałem wszystkie topiki na forum o interfejsach i klasach abstrakcyjnych ale jeszcze czegoś mi brakuje musze się z tym przespać

w jednej ksiżące znalazłem fajny przykład dla kals abstrakcyjnych
mamy klasę ssak no co to jest, nic konkretnego, nie można mieć obirektu klasy ssak, to byłoby bez sensu, więc robimy abstrakcję i dziedziczymy po niej
chyba dobre jeszcze żeby tak ładnie były interfejsy wytłumaczone

Ale interfejsy sa bardzo proste do zrozumienia. Stosuje sie je najczęściej kiedy jakaś klasa moze byc wymieniona na inna. Np. handler sesji, Router. Wtedy w interefejsie zawierasz które metody są wymagane do poprawnego działania nowej klasy z pozostałymi i jazda

A co do przykladów... Ja nie wiem po co ludzie w tych wszstkich książkach dają te durne odniesienia do samochodów, zwierząt. Jak czytałem ksiązki to nigdy tego nie mogłem poją. Dopiero jak pracowałem z kodem to wszystko sie wyjasniło. Takie przykłady wprowadzają tylko bezsensowne zamieszanie.

Interfejsy to dla mnie głównie nowe typy, które można wymusić.
Proszę pominąć niedociągnięcia w implementacji

[PHP] pobierz, plaintext 
<?php
interface inteligencjaNaPewenymPoziomie{}
abstract class Ssaki{}
 
class Czlowiek extends Ssaki implements inteligencjaNaPewenymPoziomie{}
class Orangutan extends Ssaki{}
 
// 2  podobne, ale jakże różne klasy Budowniczy
 
class Budowniczy{
 
function budujSamolot(Ssaki $object){}
function budujSamolot(Ssaki $object); //orangutan z powodzeniem wybuduje na samolot : )
function malujWPaincie(Ssaki $object){} // orangutan i czlowiek mogą używać Painta(TM)
}
 
 
class Budowniczy{
 
function __construct(Ssaki $object){}
function budujSamolot(inteligencjaNaPewenymPoziomie $object){} // tutaj tylko obiekt typu inteligencjaNaPewenymPoziomie bedzie mógł wykonać zadanie
function malujWPaincie(Ssaki $object){} // orangutan zawsze może pomalować : P
}
?>
[PHP] pobierz, plaintext 

Pozdrawiam.

menic stosowane są takie przykłady, aby każdy czytający je zrozumiał, bo pamiętaj że programiści zajmują się różnymi sprawami i nie zrozumiał byś pewnych przykładów.
Dlatego się tworzy takie abstrakcyjne przykłady, a powinieneś je znajdywać w swoim projekcie.

Cysiaczek, a jakże dobry i prosty przykład. Tutaj warto stosować zasadę "Filtrowuj wszystko co się da". Dlatego na pewno nikt nie wrzuci nam np. do rejestru kolekcji obiektu routera

Troszkę inny przykład ...

[PHP] pobierz, plaintext 
<?php
// Definicje wspólne dla wielu obiektów
interface ILiveSchoolElement {} // na codzień w szkole
interface IPeople {} // jakaś osoba
interface ITeacher extends IPeople {} // nauczyciel
interface ILearner extends IPeople {} // uczeń
 
// Implementacja metod wspólnych
abstract class AbstractPeople implements IPeople {}
abstract class AbstractPeopleLiveSchoolElement extends AbstractPeople implements ILiveSchoolElement {}
 
// Specjalizacja, implementacja metod specyficznych
class Teacher extends AbstractPeopleLiveSchoolElement implements ITeacher {}
class Learner extends AbstractPeopleLiveSchoolElement implements ILearner {}
 
// i może na końcu ..
class Jacek extends Learner {}
?>
[PHP] pobierz, plaintext 

JA bym się przyczepił do jacka, bo:

[PHP] pobierz, plaintext 
<?php
$jacek = new Learner();
?>
[PHP] pobierz, plaintext 

Hehehe, pozdrawiam, ładny przykład.

Korzystanie z interfejsów pokazuje swoje zalety w PHP szczególnie dzięki zastosowaniu SPL.
Wykorzystanie iteratora (czyli użycie foreach) lub zliczania elementów (count()) na obiekcie nie byłoby nigdy możliwe, gdyby nie odpowiednie interfejsy, wbudowane i wymagane przez te konstrukcje językowe lub funkcje.

Mi natomiast zasadność użycia interfejsów świetnie pokazała jeszcze inna sytuacja.

Mam różne rodzaje list pobieranych z baz danych. Niektóre z nich można sortować, inne stronnicować, jeszcze inne - filtrować. Niektóre mogą wszystko
Do każdego z tych zastosowań mam inną klasę, w stylu Pager, SorPanel, SearchPanel itp.

Oczywiste jest jednak, że do Pagera może trafić tylko lista, która potrafi być stronnicowana, więc Pager wymaga od otrzymywanego obiektu implementacji interfejsu Pageble.
Tak samo SortPanel itd. Dzięki temu bardzo łatwo, już na poziomie najprostszych testów sprawdzić, czy dana lista została poprawnie obsłużona.
W końcu nie tylko może mieć kilka interfejsów, które wymuszą na niej utworzenie odpowiednich metod, to jeszcze ewentualne błędy zostaną wykazane od razu po pierwszym odpaleniu testu (nie muszę fizycznie kliknąć w żaden link do stronnicowania )

Przepraszam, że odgrzewam temat. Chciałbym poruszyć problem związany z interfejsami i myślę, że kontynuacja w tym wątku będzie odpowiednia.
Postanowiłem wykorzystać wzorzec kompozycji do zebrania kilku podobnych elementów, lecz z niewielkimi różnicami. Poniższy kod uprościłem do dwóch różnic. Do plecaka mogę włożyć element będący dzieckiem klasy abstrakcyjnej Item. Ale w zależności od materiału z jakiego jest wykonany dany element implementuje odpowiedni interfejs(szkło i drewno). Poniżej przedstawiam kod oraz proszę o podanie w jaki sposób w klasie Bag rozróżniać z jakiego materiału jest dany element aby wydać odpowiedni dźwięk.

[PHP] pobierz, plaintext 
<?php
class ItemExeption extends Exception {}
 
interface szklo{
	function brzdek();
}
interface drewno{
	function pukpuk();
}
 
abstract class Item {
	abstract function weigth();
 
	function addItem(Item $item){
		throw new ItemExeption(get_class($this)." to liść");
	}
 
	function removeItem(Item $item){
		throw new ItemExeption(get_class($this)." to liść");
	}
 
}
 
class butelka extends Item implements szklo {
	function weigth(){
		return 2;
	}
 
	function brzdek(){
		return 'Brzdek! Brzdek! ';
	}
}
 
class patyk extends Item implements drewno {
	function weigth(){
		return 4;
	}
 
	function pukpuk(){
		return 'Puk! Puk! ';
	}
}
 
class drewniane_luterko extends Item implements drewno, szklo {
	function weigth(){
		return 3;
	}
	function pukpuk(){
		return 'Puk! Puk! ';
	}
	function brzdek(){
		return 'Brzdek! Brzdek! ';
	}
}
 
class Bag extends Item {
	private $items = array();
 
	function addItem(Item $item) {
		foreach($this->items as $thisItem){
			if($item === $thisItem){
				return;
			}
		}
		$this->items[] = $item;
				//gdzieś tutaj chciałbym móc użyć czegoś takiego 
				if($item == 'szklo'){
					 $item->brzdek();
	}
	function removeItem(Item $item){
		$items = array();
		foreach($this->items as $thisItem){
			if($item !== $thisItem){
				$items[] = $thisItem; 
			}
		}
		$this->items = $items;
	}
	function weigth(){
		$ret = 0;
		foreach($this->items as $item){
			$ret += $item->weigth();
		}
		return $ret;
	}
}
 
$plecak = new Bag();
//wkladamy do plecaka butelke i sluszymy brzdek
$plecak->addItem(new butelka());
//wkladamy patyk i slyszymy pukpuk
$plecak->addItem(new patyk());
//sprawdzamy ciezar wlorzonych przedmiotow
print 'Plecak waży: '. $plecak->weigth() . ' kg.<br>';//wynik: Plecak waży: 6 kg.
 
?>
[PHP] pobierz, plaintext 

Jest do tego gotowy operator: instanceof

A ja, jeśli można, chciałbym prosić o wytłumaczenie jak krowie na granicy po co w ogóle stosuje się klasy abstrakcyjne? Przeczytałem cały temat i niestety nie mogę tego zrozumieć.

@Virti
Aby ułatwić sobie implementację Mały przykład kodu.

[PHP] pobierz, plaintext 
<?php
abstract class HeniuTreeNode 
{
	/**
	 * Ustawienie ID gałęzi
	 *
	 * @param int $id
	 */
	public function setId($id)
	{
		$this->id = $id;
	}
	public function getId()
	{
		return $this->id;
	}
 
	/**
	 * Ustawienie nazwy elementu
	 *
	 * @param string $name
	 */
	public function setName($name)
	{
		$this->name = $name;
	}
	public function getName()
	{
		return $this->name;
	}
 
	private $id	  = null;
	private $name = null;
}
?>
[PHP] pobierz, plaintext 

Oraz klasa dziedzicząca po niej

[PHP] pobierz, plaintext 
<?php
class HeniuTreeNodeNested extends HeniuTreeNode
{
// Tutaj cały kod
// Mamy dostęp do metod set/getId oraz set/getName
)
?>
[PHP] pobierz, plaintext 

I teraz wiesz że każda z klas odpowiadających za pojedyńczą gałąź będzie miała takie metody jak set/getId set/getName implementujesz je w klasie abstrakcyjnej po której będą dziedziczyć Twoje klasy i wtedy nie musisz już "przepisywać" ich na nowo (jeśli nie chcesz) w każej klasie z osobna.
Dzięki temu uzysujesz już wstępną implementację, a nic nie stoi na przeszkodzie aby w danej klasie nadpisać(jeśli jest taka potrzeba) te metody(set/getId czy set/getName)
Może to trochę zamotane ale ogólnie rzecz biorąc dużej polityki tutaj nie ma

Ok, czyli rozumiem, że abstrakcja dostarcza funkcji, które są używane przez kilka(naście) pochodnych klas, tak aby nie trzebabyło w każdej z osobna ich deklarować? W takim razie dlaczego nie stosować normalnych klas (nie-abstrakcyjnych) jako rodziców? Żeby zabezpieczyć się przed wywołaniem bezpośrednio tej funkcji?

@virti: żeby wymusic dziedziczenie po tej klase. Klasa abstrakcyjna to prototyp, szkielet, nie moze byc uzyta bezposrednio.

@vegelus
Wyjaśnij mi czym się różni "brzdek"/"pukpuk" od "dzwiek"?

Ja się zawsze staram robić klasy abstrakcyjne. Nazwa tego typu klas odzwierciedla to, czym ona jest. Widząc słówko abstract, natychmiast uzyskujemy informacje o tym, że implementacja jest w pochodnych, które tworzą jakąś rodzinę klas wyspecjalizowanych klas. Jak rozejrzymy sie po metodach tej klasy, będziemy wiedzieli, jakie operacje są wspólne, a jakie klasa wymusza w swoich pochodnych.
Stosując zwykła klasę bazową, te informacje będziemy musieli zdobyć sami przeszukując kod podklas.
To jest jedna z cech oop - ułatwienie zrozumienia logiki systemu.

Pozdrawiam.

Witam, może powinienem założyć nowy temat, ale wolę nie zaśmiecać forum Napotkałem problem, oto kod który wg mnie powinien działać:

[PHP] pobierz, plaintext 
<?php
interface A{}
 
interface B extends A{}
 
interface C{
   public function metoda(A $obiekt);
}
 
abstract class D implements C{
   public function metoda(A $obiekt){
	  //jakas implementacja
   }
}
 
class E extends D{
   public function metoda(B $obiekt){
	  parent::metoda($obiekt);
   }
}
?>
[PHP] pobierz, plaintext 

Problem jest taki, że wywala błąd że metoda E::metoda nie jest kompatibilna z interfejsem C::metoda... (Declaration of E::metoda() must be compatible with that of C::metoda()). Tak, jest inne wymuszenie typu w klasie D, ale podany typ jest dziedziczony po interfejsie który jest wymuszony w interfejsie C...

Czyli podsumowywując, jeśli chcemy wymusić typ w interfejsie to już nie da się później w klasach implementujących ten interfejs, w tej metodzie wymusić typ, który dziedziczy po typie wymuszonym pierwotnie w interfejsie? (mam nadzieje, że zrozumiecie o co mi chodzi ) Jak w takim razie to "obejść"? Czy może jest to jakiś bug w php5, albo dziwne i świadome ograniczenie? Bo na "chłopski rozum" powinno to działać.

EDIT: pytanie jak to "obejść" raczej jest nie na miejscu, bo wiem jak to obejść, tylko trochę to jest niewygodne

EDIT2: znalazłem już odpowiedź wg twórców php, nie jest to błąd. PHP nie sprawdza, czy rzutowany typ jest dziedziczony po tym, który został zrzutowany w interfejsie/klasie po której dana klasa jest dziedziczona. Wg mnie to trochę dziwne, no ale cóż poradzić...

Wracająć do tematu to jak dobrze zrozumialem, interfejsy tylko i wyłacznie wymuszają utworzenie danych metod w klasie która implementuje dany interfejs

Interfejsy nie tylko wymuszają istnienie danych metod, ale także ustalają jaką deklarację ma mieć ta metoda (ile i jakiego typu ma mieć argumenty). W interfejsie możemy tylko wymusić istnienie publicznych metod, jest to z jednej strony logiczne, gdyż interfejs gwarantuje że dana rodzina klas będzie miała ten sam "protokół" do korzystania z nich, a z prywatnych czy chronionych metod nie skorzystamy z poza danej klasy.