„Errare humanum est, in errore perseverare stultum.“ (Chybovat je lidské, trvat na omylu hloupé.)
Dlouho jsem se mýlil při psaní PHP, když jsem nechápat k čemu je dobrá možnost uložit si do proměnné název funkce/objektu a přes proměnnou pak provádět volání. Dlouho jsem se vyhýbal objektům, s poukazem na režii při jejich vytváření, a snažil se psát lineární kód s bezpočtem podmínek (ne, funkcím jsem se opravdu nevyhýbal).
Obojí byla chyba, zejména odmítání objektového přístupu.
Objekty
Nehodlám suplovat manuál, nebo některý z kurzů PHP, takže nevysvětlím co jsou objekty a jak se s nimi pracuje. Případně si mě můžete objednat na kurz PHP (s již notně předělanou osnovou) :-), kde práci s nimi vysvětluji, nicméně sám jsem se jim vyhýbal.
Používal jsem funkční kód, většina věcí fungovala, ale zádrhel nastal v momentě, kdy jsem se rozhodl pro důsledné rozdělení mého frameworku do nezávislých funkčních modulů a nechtěl jsem podle konfigurace webu manuálně stavět nástěnku (dashboard) se statistikami položek webu, každý modul se měl postarat o vygenerování a zobrazení své části sám. Dát si jednotný systém pojmenování modulů a vědět co projít je triviální, leč po načtení products.module.php a snaze načíst categories.module.php se potkají stejné názvy funkcí, což teoreticky lze ošetřit zapodmínkováním pomocí function_exists, leč prakticky pracují funkce jednotlivých modulů nad jinými množinami dat a poskytují jinak strukturovaná data na výstupu.
Když vytvořím instanci objektu, z něj zavolám metodu getStats, jež přiřadí statistická data do pole, tak při vytváření dalšího objektu (instance jiné třídy) mohu původní objekt zahodit, data z něj již mám v poli statistických dat.
Přestože objekty mají svou režii při vytváření a destrukci, dosáhl jsem menších paměťových a časových nároků, potřebných pro zpracování dat. Kód jako takový se stal mnohem přehlednější, udržitelnější a snadnější pro rozvíjení.
Svůj framework (fakticky CMS a malý e-shop) teď upravuji do objektů. Během několika dní by se měl dostat ke starším zákazníkům, společně s tímto přepsáním se zbavuji používání zastaralých (legacy/deprecated) postupů, mimo jiné třeba MySQL ve prospěch PDO, nebo POSIXových funkcí pro regulární výrazy, ve prospěch PCRE.
Přiznávám, moje odmítání objektového přístupu a snaha psát čistě funkcionální kód byla omylem, který mi práci činil obtížnější a nepříjemnější.
Proměnná jako funkce
Použít proměnnou pro volání funkce, tj. do proměnné uložit název funkce ($func = "foo") a přes tu proměnnou pak funkci volat ($func('param1', 2); mi připadalo jako poměrně úchylná myšlenka, ale při studiu kurzu interaktivního programování v Pythonu jsem jedno z možných použití pochopil.
Volání funkce v cyklu, kde je funkce nastavena podle nějakých počátečních podmínek. Lze to udělat tak, že cyklus prochází množinu dat a uvnitř cyklu jsou na základě jiných parametrů; tudíž pomocí podmínek if…elseif…else…, volány potřebné funkce/metody. Ale přehlednosti kódu určitě pomůže uložení názvu volané funkce do proměnné a její vyvolání uvnitř cyklu pomocí obsahu proměnné.
Neplánuji nyní testovat rychlost a paměťové nároky, ale myslím si, že kód poběží rychleji, jelikož se nebude testovat „balík“ podmínek při každém průchodu cyklu.
…?
Jak jsem uvedl v perexu, chybovat je lidské. Přestože si myslím, že nejsem začátečník, tak mám hodně prostoru k růstu.
Komentáře
2 komentáře: „PHP: Objekty a $funkce – mýliti se je lidské.“
Objekt v PHP je především prostor jmen.
PHP vytváří mnoho prostorů jmen, například při volání funkce, nebo při vytvoření proměnné typu pole, nebo při vytvoření objektu.
Pokud se nebojíte kvůli režii používat v PHP pole, nebo funkce, pak není důvod se bát vytvářet objekty.
Je třeba si uvědomit, že u dynamických jazyků, jako je PHP, nelze režii příliš odhadnout, závisí na implementaci interpretru.
Přímé použití názvu funkce a použití jména funkce v proměnné – to je jen důsledkem toho, že pracujete s prostorem jmen, v PHP nepracujete a ani nemůžete pracovat s pointery. Proměnná s názvem funkce je z nouze ctnost, která má nahradit funkcionalitu dosahovanou v jiných jazycích pointery na funkce.
Režie vytváření a rušení je méně důležitá, jestli jestli jde o objekt nebo něco jiného, protože čas zabírají především jiné věci, na prvním místě režie interpretace, která je podstatnější, než cokoli jiného.
Miloslav Ponkrác
[Miloslav Ponkrác]: Nemám důvod polemizovat. Já jsem se, (asi) bohužel, učil programovat v BASICu a Forthu na počítači Sinclair ZX-Spectrum a to bylo koncem 80. let 20. století, pak přišla Amiga a PC, leč tam už jsem experimentoval s Pascalem. Tak nějak mi čisté C nikdy k srdci nepřirostlo, přestoče C-based jazyky mě dneska živí a s OOP je to obdobné (umím, ale pokud jde psát čistě funcionálně, tak po něm nešáhnu). Prostě stará škola, které se nejvíce ze všech jazyků líbil Forth.