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
		}
	}
}