Jepičí život objektů

Programátoři, kteří se k PHP dostanou od jiných jazyků, se snaží předchozí zkušenosti adaptovat na PHP a tak někdy vznikají zlozvyky. Typickým příkladem je chápání referencí jakožto ukazatelů. Programátor se snaží optimalizovat výkon aplikace tím, že proměnné předává funkcím přes reference. Jenže, PHP nemá ukazatele a ve skutečnosti tím může aplikaci naopak zpomalit. Tyhle chyby jsem samozřejmě dělal také. Zkušenosti z jiných jazyků se mohou v novém prostředí vymstít.

Další věc, na kterou se hledí s nedůvěrou, je vytváření „jepičích objektů“, tedy objektů, které jen splní drobnou funkci nebo předají data a hned zase zaniknou. Programátoři uvažují, zda-li není možné objekt nahradit polem. Mají totiž zažitou představu, že vytvoření objektu je zatíženou velkou režií.

Ve skriptovacích jazycích tomu tak nebývá. Kdyby už PHP 4 bylo koncipované jako objektové, výkonnostní rozdíl mezi objektovým a neobjektovým přístupem by neexistoval. Leč z historických důvodů tu rozdíl je, objektovost je o něco pomalejší. S každou další verzí mám pocit, že je zanedbatelnější. Za zanedbatelný se dá považovat i rozdíl mezi vytvořením objektu a pole:

$obj = new Object(10);
$obj->val = 10;

// versus ekvivalent

$arr = array('__class' => 'Object');
__construct($arr, 10);
$arr['val'] = 10;

Zkusil jsem změřit obě operace a výsledek je 2.0E-6 sec : 1.8E-6 sec. Nemá pak smysl pozdvihnout obočí nad tím, že nějaká operace „zbytečně“ vytvoří objekt, jen aby předala data. Je to totiž totéž, jako když se vytváří jepičí pole:

$s = preg_replace_callback($pattern, array($obj, 'method'), $s);

Můžete namítnout, že výše uvedené konstrukce nejsou pro pole vůbec typické. Jistě, použil jsem je jen proto, abychom srovnávali funkčně podobný kód. V praxi je na rozhodnutí programátora zvolit, kdy použít pole a kdy objekt. Já se jen snažím ukázat, že do volby by neměly zasahovat mylné představy o (ne)výkonnosti.