Co je nového v PHP 5 (díl 1/5)
PHP 5 přináší spoustu výborných změn. Jedná se hlavně o změnu jeho objektové koncepce. Většině "taky-programátorů" to bude jedno, nevyužívají ani potenciálu PHP 4, nicméně, lidem jako já, co znají výborně C++, sedne PHP 5 mnohem lépe. Jeho implementace objektů se totiž zjevně nechala inspirovat C++ a Javou.
Třída bude mít konsktruktory (což má nakonec částečně již teď) a desktruktory:
class _metodaA { var $x; function __construct($x) { $this->x = $x; } function display() { print($this->x); } function __destruct() { print("bye bye"); } } $o1 = new _metodaA(4); $o1->display();
Třída bude mít protected (je k nim umožněn přístup i přímým potomkům) a private (přístup k nim mají jen třídy samotné, v nichž jsou definovány) proměnné a rovněž metody. Dosavadní kód (PHP 4) je považován, jako by všechny metody byly typu public.
class Foo { private function aPrivateMethod() { echo "Foo::aPrivateMethod() called\n"; } protected function aProtectedMethod() { echo "Foo::aProtectedMethod() called\n"; $this->aPrivateMethod(); } } class Bar extends Foo { public function aPublicMethod() { echo "Bar::aPublicMethod() called\n"; $this->aProtectedMethod(); } } $o = new Bar; $o->aPublicMethod();
Muze mi nekdo vysvetlit, proc v tak tenke transformacni vrstve (db->html, uzivatel->db) jsou potreba objekty?
Jiste, krasne se to cele parsuje, alokuje v pameti, plni daty.
Pak se provede 1+1 (metafora) a vysledek - 2 - se posle na vystup.
nasledne se pamet hezky zase uvolni.
A dalsi dotaz na skript a cele znovu...
...za ta leta co programuji v PHP jsem narazil na JEDEN skript, kde se vyplatilo pouziti objektu.
Jinak? Ano, vypada to hezky, ale krome vetsi zateze na server to nic neprinasi.
Zduraznuji - v internetovych aplikacich psanych v PHP. Pri tom prezvykavani dat objekty pouze zbytecne zpomaluji vykonavani skriptu.
Zkuste si par benchmarku, nez budete v interpretovanem jazyku oslavovat objekty.
[1] v moderních programovacích jazycích jde mnohem více než o rychlost o znovupoužitelnost kódu, jeho přenositelnost a řadu dalších věcí. Kdyby to tak nebylo, děláme stále v assembleru.. ;)
Příkladem neefeektivity budiž i taková mimořádně populární Java ;)
je to tak čím lepší a pro programátory přitažlivější psaní kódu, tím vyšší nároky na výpočetní kapacitu počítače.
pokud by se dnes psalo v Asembleru ? zajímavá myšlenka, ale nereálná.
jo když se podíváš zpátky na to co a jak se programovalo před několika lety. Co nejmíň nároku na výpočetní kapacitu na paměť ,ale dnes ?
[2] o Javě mi ani nemluv měl jsem v rukou několik programu napsaných od "programátorů Javy" a ... počítač -> restart , program -> koš
Empy
[1] Víš, Pavle, OOP je prostě velmi přirozené.
Objevíš objekt. Nejprve jej krásně parsuješ očima, poté si zjistíš jeho adresu, a pokoušíš se jej přilinkovat.
Objekt zavoláš, pozveš do podniku, a tam jej pozvolna plníš daty. Jistě, musíš si předtím v peněžence naalokovat dostatečnou hotovost.
Pak se přesunete k Tobě domů a tam se provede 1+1 (metafora), výsledek je 2 (je-li 3, nastal fatal error). Následně se hezky uvolníš.
A to je vše. Stálo to celé OOP za to???
Mně to třeba vyhovuje. Ale nikomu OOP nenutím. Klidně si to dál dělej bez objektů :-)
Víc než na lepší objekty se ale těším na zlepšení v rozšířeních. Třeba na poli XML je toho víc než dost. Ale třeba u socketů to už jde skoro do absurdna - k čemu proboha potřebujeme v PHP vytvářet serverové sockety?
[2] pokud používáte rozumný překladač, tak je lepší psát v c++ než v asembleru, protože ten si to do toho asembleru stejně přechroustá a optimalizuje lépe než leckterý asm odborník.
Problém je ale v tom, že v php si to ten překladač(zend) překládá při každém požadavku.
Ale souhlasím s tím, že přehlednost je nade vše. Proto jsem také příznivcem phpdoc komentářů, přestože dost natahují kód. Měly by imho být stejnou samozřejmostí jako javadoc komentáře v javě.
[5] Tedka tu mam nejakou 2N tel ustrednu, ktera ma u sebe XAPI server, umoznujici tahani ruznych zajimavych dat ohledne volani lidi po firme a ven.
Nez bych psal v nejakem rozumnem jazyce dalsi vrstvu, ktera by komunikovala s XAPI serverem a (treba) databazi, toz to si radsi napisu jednoduche rozhrani v php, prave pres sockety. On totiz dalsi pozadavek je aby to bylo platformne nezavisle.
Je fakt, ze za ty roky co delam server side, je to jediny pripad kdy maji sockety nejaky smysl, ale rozhodne bych je nevyhazoval ven :-).
PS. Teda jeste jednou jsem se setkal s pouzitim socketu: kolega si primo ve strance potreboval v urcite fazi vytahout informace z jine stranky, na tom samem webu a buhvi proc to udelal prave socketem.
Do lejna a podobnych veci radsi nestouram, takze jsem to presel jenom zvednutym obocim...
[6] to ale obhajujete klientské sockety. Funkce fsockopen je i podle mě více než užitečná. Já jsem se podivoval spíše nad přibyvší funkcí stream_socket_server, která vytvoří serverový socket. I když i u toho se možná nějaké to smysluplné využití najde.
Ačkoliv PHP 5 je při definici tříd zpětně kompatibilní s PHP 4,
začal jsem pro používat tuto konstrukci:
class metodaA {
function __construct($x) {
// konstruktor pro verze >= 5
}
function metodaA($x) {
// konstruktor pro zpětnou kompatibilitu s verzi 4
$this->__construct($x);
}
}
Co myslíte, není to vzhledem k 'dopředné kompatibilitě' lepší?
[8] v zásadě dobrej nápad :)
[1]
Neco ti reknu: podivej se na jakykoli vetsi internetovy projek na kterym spolupracuje vic lidi. (napr http://www.webgame.cz ) - neni psany objektove, nepouziva tedy ani tridy... mozna je to "rychle", ale tim ze pustis nekolik testu na jednu stranku nezistis opravdovou rychlost. kdyby napr webgame byl delany objektove, mohly by se napr jednotky pridavat pouhou zmenou v jednom souboru (pridani cca 10-50 radku!). ted by to znamenalo kompletni prekopani cca 260 souboru (2.482Mb bez obrazku). A dasli vec - pokud do vyvojoveho tymu prijde novy clovek (sam sem si to vyzkousel cca 4-5mesicu zpet), a neni nic psano objekty a nejsou dodrzeny urcite standarty, NENI VUBEC jednoduche se zorientovat (pokud pripocitas mysql databazi o cca 110 tabulkach a nektere o +-100 sloupcich je to zalezitost mesicu). Kdyby to cele bylo napsano v objektech - nehlede na benchmarky (ktere by byly spomaleny radove v ms [coz je asi jako jedna zbytecna podminka navic nebo nespravne pouzite include a require]) - tak zorientovani a nasledne upravy budou 10x rychlejsi - nemluve o tom ze pokud mas napsane spravne objekty programovani je taky min 5x rychlejsi.
Muzes si o tomhle nazoru myslet co xes (muzete si to myslet vsichni), ale skus si nekdy vytvorit velky php projekt a ne jen stranky typu PHP (zkratka PHP je puvodne "perfect home pages" -> homepages...)
[1] Kdyz jsem začal programovat v PHPku konstrukt class mě učinil nevísostně šťastným :-)
Nedokážu si představit, že bych měl programovat bez objektů. To bych nezvládl.
O té alokaci paměti spíše záleží jak jste/nejste šikovný. Je to jen na vás.