Witaj, Gościu O nas | Kontakt | Mapa
Wortal Forum PHPEdia.pl Planeta Kubek IRC Przetestuj się!

Programowanie obiektowe dla początkujących

Kontrola typów

Język php na typy danych "patrzy przez palce". Niektórzy uważają, że bardzo słaba kontrola typów jest plusem (daje dosyć dużą elastyczność). Niektórzy zaś twierdzą, że poprzez bardzo słabą kontrolę typów łatwiej o błąd, kod jest mniej czytelny, programista musi bardziej siebie kontrolować. Ja należę do tej drugiej grupy. W php 5 wprowadzono możliwość kontroli typów klasowych.

class Article{
	//ciach
	public function setArrayBox(ArrayBox $a){
		$this->data = $a;
	}
	//ciach
}

Taka definicja metody Article::setArrayBox() wymusza to, aby argumentem był obiekt typu ArrayBox (czyli obiekt klasy ArrayBox lub klas dziedziczących po ArrayBox). Wprowadzając takie ograniczenie, mamy pewność że w składowej $this->data zawsze będzie referencja do obiektu o odpowiednim typie, który obsługuje jakieś określone metody. Dzięki temu nie popełnimy błędu podając np. ciąg znaków, obiektu innego typu, gdyż parser wyrzuci fatal error. Nie jest istotne, czy w tym przypadku ArrayBox to klasa abstrakcyjna, zwykła klasa, czy też interfejs, gdyż w metodach można wymuszać typ argumentów poprzez nazwę dowolnej klasy lub interfejsu.

Innym sposobem na sprawdzenie typu obiektu to operator instanceof. Wyrażenie z instanceof zwraca true jeśli obiekt należy do typu podanego po prawej stronie operatora .

$reksio = new Basset('Reksio');
if($reksio instanceof iAnimal){//iAnimal – interfejs który jest implementowany przez Animal
	echo 'ten tekst zostanie wyświetlony, bo iAnimal jest implementowane przez Animal';
}
if($reksio instanceof Dog){//Dog rozszerza klasę Animal
	echo 'ten tekst zostanie wyświetlony, bo Basset dziedziczy po Dog';
}
if($reksio instanceof Basset){//Basset rozszerza klasę Dog
	echo 'ten tekst zostanie wyświetlony';
}
if($reksio instanceof Cat){//Cat nie leży w tej gałęzi hierarchi klas co Basset
	echo 'ten tekst nie zostanie wyświetlony';
}

Jak się ma przysłanianie metod, która przyjmuje jako parametry określony typ? Jeśli przysłaniana metoda nie została oznaczona jako abstrakcyjna w jednej z nadklas i nie została zdeklarowana w implementowanym interfejsie, to ma się nijak. Można zmieniać całkowicie typowanie parametrów na typy, które nie mają nic ze sobą wspólnego lub też w ogóle pominąć typowanie parametru, czy też pominąć przyjmowanie parametrów.

Jednak inaczej ten aspekt wygląda w przysłanianiu metod abstrakcyjnych lub zdeklarowanych w interfejsie. W takim przypadku, metoda którą przysłaniamy musi jako parametry przyjmować dokładnie takie same typy.

class C{}
class D extends C{}

interface iA{
	public function method(C $obj);
}

class A implements iA{
	public function method(C $obj);//tak można
}

class B implements iA{
	public function method(D $obj);//tak nie można, mimo iż D dziedziczy po C
}

Może wydaje się to mało logiczne, ale nie można w klasie pochodnej w takim przypadku typu parametru metody zdeklarowanej w interfejsie zamienić na podtyp tego typu. Kiedyś dużo czasu spędziłem nad tym problemem i znalazłem raport tego "błędu", gdzie projektanci Zenda napisali, że to nie jest błąd, a zamierzony zabieg. Jeśli chcemy w nadklasie ograniczyć przyjmowanie obiektów w jednej z metod interfejsu na podtyp typu zdeklarowanego w tym interfejsie, to pozostaje nam jedynie nieelegancki operator instanceof.

class B implements iA{
	public function method(C $obj){
		if($obj instanceof D){
			//operacje główne metody
		}else{
			//np. wyrzucenie wyjątku
		}
	}
}
Informacje na podobny temat:
Wasze opinie
Wszystkie opinie użytkowników: (3)
Błąd w przykładowym kodzie
Wtorek 16 Luty 2010 2:33:32 pm - mateo84 <mateo84_at_o2.pl>

Witam, próbowałem się zaznajomić z projektowaniem obiektowym w php i pozytywnie odbieram fakt, że komuś chce się pisać te wszystkie poradniki i tutoriale, tak jak ten. Ale niestety mam uwagę. 3. Modyfikacja dostępu w kodzie 4 (licząc od góry) metoda getName() nie wyświetla ani Reksio ani też Jamnik Reksio. Zapewne dlatego że gdzieś wypadałoby wpisać "echo". Jeżeli jest to zależne od konfiguracji serwera to przepraszam ja, ale jeżeli autor nie przetestował działania skryptu to coś tu jest nie "helloł".
Pozdrawiam :)

Za malo o istocie OOP
Niedziela 29 Marzec 2009 7:22:56 pm - seth

Brakuje mi w tym artykule opisu filozofii pisania obiektowego. To co w nim jest to tylko opis narzedzi ktore udostepnia PHP 5, a przeciez programowanie obiektowe to cos wiecej niz uzywanie slowek class, extend itp.

Jako, ze jest to tekst dla poczatkujacych brak wprowadzenia w istote OOP jest dla mnie bardzo duzym minusem.

Jezeli juz kogos chcemy uczyc obiektowki to zadbajmy o to aby wiedzial po co mu to do szczescia i jakie problemy rozwiazuje. W przeciwnym razie osoba taka dostaje do reki mlotek z instrukcja obslugi ale nie wie po co w ogole ma wbijac te gwozdzie.

Nie dla początkujących
Piątek 27 Marzec 2009 9:36:11 pm - orglee

Panie Piotrze posługuje się Pan bardzo hermetycznym językiem, opisując podstawy obiektówki. Nie wiem czy będąc początkującym zrozumiałbym więcej niż połowę z tego artykułu. Oprócz tego czasami wyprzedza Pana, Pańskie myślenie. Przykładem może być, użycie słów opisujących proces dziedziczenia, przed wytłumaczeniem istoty tego zagadnienia.

Mentax.pl    NQ.pl- serwery z dodatkiem świętego spokoju...   
O nas | Kontakt | Mapa serwisu
Copyright (c) 2003-2017 php.pl    Wszystkie prawa zastrzeżone    Powered by eZ publish Content Management System eZ publish Content Management System