Autor Zpráva
Marenek
Profil *
Dokázal by mi někdo říct hlavní důvody a výhody, proč je dobré používat v php OOP a třídy ?
Eddie
Profil
Marenek
To sa tu uz pytalo mnoho ludi. Skus trochu hladat...
Zp_
Profil
Výhody OOP: abstrakcia - abstraktné dátové typy, lepšia rozšíriteľnosť, modulárnosť, flexibilita, prehľadnosť, znovupuužiteľnosť kódu.

v PHP je ale zbytočné používať OOP pretože je to procedurálny jazyk so slabou typovou kontrolou, kvalitný OO jazyk je napr. C#
koudi
Profil
v PHP je ale zbytočné používať OOP pretože je to procedurálny jazyk so slabou typovou kontrolou
To sice pravda, ale výhody jako lepšia rozšíriteľnosť, modulárnosť, flexibilita, prehľadnosť, znovupuužiteľnosť kódu zůstávají.
RiZe
Profil
Mě by zajímalo, jak je to pak s používáním takových tříd. Vždyť jejich metody poté stejně používám v procedurálním kódu ne? Nebo snad lze napsat čistě OOP aplikaci? V této oblasti se zatím příliš neorientuji, takže pls noflame
WanTo
Profil
RiZe
Ano, jde napsat čisotu OOP aplikaci. Celý soubor index.php může vypadat třeba takto:

<?php
Application::getInstance()->run();
?>
WanTo
Profil
Zajímala by mne spíše jiná věc: kolik tříd PHP přibližně zvládne, než se dosáhne nějakého výrazného overheadu aplikace? (příliš dlouhé zpracování skriptu, velká paměťová náročnost...)
RiZe
Profil
WanTo
1) To už jsme někde viděl... už vím PRADO Framework
2) Zmiňovaný PRADO, nebo třeba PEAR, nebo Zend Framework používají dozajista mnoho tříd, a funguje to taky. Myslím, že tento limit bude dost velký na to, aby se daly napsat velké a složité aplikace, ale ruku do ohně za to nedám :)

EDIT
3) Jen si rýpnu :), neměl by v tom index.php být ještě nějaký include právě s tím FW? :)
WanTo
Profil
RiZe
Neměl.

V PHP 5 existuje funkce __autoload($class_name), která se zavolá jako poslední šance pro načtení třídy nebo rozhraní, když ona třída (rozhraní) není nalezena. Takovou funkci si musíš napsat sám a může vypadat třeba takto:


function __autoload($class_name) {
require_once "tridy/" . $class_name . ".php";
}
WanTo
Profil
Tak se omlouvám, něco by tam mělo být :-) Buď ten include, nebo definice funkce __autoload. Takhle by to fakt nešlo.
Joker
Profil
Asi největší výhody objektů v PHP jsou to, čemu se v OOP terminologii říká "zapouzdření" a "znovupoužitelnost".
Například chci poslat dotaz do databáze a tak zavolám (po vytvoření příslušného objektu):
$db->query($sql);
...a nezajímá mě, co je to za databázi nebo jestli vůbec nějaká databáze existuje. Stačí mi vědět například že třída Database má metodu query(), jejímž parametrem je SQL dotaz a vrací při úspěchu true, jinak false (tomu se říká protokol objektu).
A zároveň na druhé straně mi stačí akorát dodržet ten protokol a můžu klidně napsat svou třídu Database, která bude data číst třeba z XML souboru. Zaměnil jsem databázi za XML soubor a přitom v kódu hlavního skriptu se nemusela změnit ani čárka.
Z toho plyne ta znovupoužitelnost, tu třídu stačí napsat jednou a můžu jí použít všude, takže jakmile jí jednou mám, znamená migrace jakékoliv mojí aplikace třeba z MySQL na MS-SQL nebo na XML soubory jen nakopírování správné třídy.

Teoreticky by se toho dalo dosáhnout i pomocí knihovny funkcí, ale u objektů mám výhodu, že ty funkce jsou rozdělené do nějakých logických bloků a taky skládání, tj. že objekt může být součástí jiného objektu. U knihovny funkcí v tom rychle vzniká chaos.

Zajímala by mne spíše jiná věc: kolik tříd PHP přibližně zvládne, než se dosáhne nějakého výrazného overheadu aplikace?
To asi dost záleží na jejich složitosti a tak, ale asi hodně :-)
Ale kdysi na univerzitě nám na OOP říkali jednu zajímavost - sice se to týkalo "klasických" programovacích jazyků a ne přímo PHP, ale: v té době se udávalo, že rychlost zpracování objektového programu je asi 80% rychlosti zpracování strukturovaného programu. Ovšem jak roste složitost aplikace, objektově ve strukturovaném programu vzniká větší množství chyb a neefektivních míst, takže u složitých aplikací může být objektově napsaný program i rychlejší, než strukturovaný.
Potom by tedy "overhead" objektového programu byl vlastně záporný :-)
llook
Profil
OOP má v PHP stejné výhody, jako kdekoli jinde. Pokud ale někdo chcete "přejít" z procedurálního na objektový přístup, nespěchejte a používejte OOP pouze tam, kde vidíte nějaký přínos, jinak si to znechutíte. Zajímejte se taky o OOP obecně a o nápady ze světa Javy.

Zp_ Kvalitními OO jazyky jsou například Python a Javascript. Oba mají slabou typovou kontrolu.
Tím nechci říct, že je PHP nějak kvalitní, jenom říkám, že daný argument je na palici a závěr taky - používat OOP v PHP rozhodně není zbytečné.
WanTo
Profil
llook
U toho JavaScriptu bych si nebyl tak jistý, je-li to kvalitní objektový jazyk. Jestli se od doby, kdy jsem se ho učil a používal, nic nezměnilo, tak tam ani nejde nadefinovat třída a o dědičnosti radši nebudu mluvit. Pokud vím, tak se tato absence obchází použitím funkcí a skutečností, že skoro všechno je v JavaScriptu objekt (nebo asociativní pole? :-) ).
llook
Profil
WanTo
Kvalitní OOP se nemusí podobat Javě.
Javascript nepoužívá třídy, ale prototypy. Je to zase jiný přístup, těžko říct jestli lepší nebo horší.
Marenek
Profil *
Asi největší výhody objektů v PHP jsou to, čemu se v OOP terminologii říká "zapouzdření" a "znovupoužitelnost".
Například chci poslat dotaz do databáze a tak zavolám (po vytvoření příslušného objektu):
$db->query($sql);
...a nezajímá mě, co je to za databázi nebo jestli vůbec nějaká databáze existuje. Stačí mi vědět například že třída Database má metodu query(), jejímž parametrem je SQL dotaz a vrací při úspěchu true, jinak false (tomu se říká protokol objektu).
A zároveň na druhé straně mi stačí akorát dodržet ten protokol a můžu klidně napsat svou třídu Database, která bude data číst třeba z XML souboru. Zaměnil jsem databázi za XML soubor a přitom v kódu hlavního skriptu se nemusela změnit ani čárka.
Z toho plyne ta znovupoužitelnost, tu třídu stačí napsat jednou a můžu jí použít všude, takže jakmile jí jednou mám, znamená migrace jakékoliv mojí aplikace třeba z MySQL na MS-SQL nebo na XML soubory jen nakopírování správné třídy.

Teoreticky by se toho dalo dosáhnout i pomocí knihovny funkcí, ale u objektů mám výhodu, že ty funkce jsou rozdělené do nějakých logických bloků a taky skládání, tj. že objekt může být součástí jiného objektu. U knihovny funkcí v tom rychle vzniká chaos.


To jsem přesně potřeboval vědět.:-)

Jinak díky i ostatním, je to zajímavé téma.
WanTo
Profil
llook
Kvalitní OOP se nemusí podobat Javě.
Javascript nepoužívá třídy, ale prototypy. Je to zase jiný přístup, těžko říct jestli lepší nebo horší.


V tom máš taky pravdu. Nicméně mně se vždycky s třídama pracovalo líp :-)
Toto téma je uzamčeno. Odpověď nelze zaslat.