OP v PHP

dneska uz snad skoro vsichni, ne?
a vyhody jako v jakemkoliv jinem jazyce - (zapouzdrenost, dedicnost, ...), prehednost kodu, snadnejsi uprava kodu, pouzitelnost ve vice projektech, ...

No hlavna vyhoda je, ze pracujem s MVC komponentami. Takze mam oddeleny kod pre renderovanie stranky od ziskavania/manipulacie s DB.

blaaablaaa
„dneska uz snad skoro vsichni, ne?“
Tak to jsem asi zastaral :( budu to muset dohnat.

„a vyhody jako v jakemkoliv jinem jazyce - (zapouzdrenost, dedicnost, ...), prehednost kodu, snadnejsi uprava kodu, pouzitelnost ve vice projektech, ...“

PHP nějak ještě neumím srovnávat třeba s Pascal/Delphi a důvod je, že php se mi při generaci stránky provede např. za desetinu sekundy ale program v Delphi může běžet třeba několik hodin.
Takže pokud mám něco udělat v delphi, hned šahám po objektech, protože se mi to zdá přehlednější, lépe se to zpravuje a hlavně to poskytuje skryté komponenty, eventy a podobně, které čekají na reakci uživatele, aby se vše jedním stiskem kaskádově odstartovalo.
Nějak jsem zatím nepochopil, proč bych ztrácet čas vytvářením toho všeho při generování stránky, které jen proběhne kódem a skončí.

A co se týče velikosti, program (obvykle) používá jeden člověk na jednom počítači, takže si mohu dovolit menší zvětšení velikosti a o trochu náročnější program tím, že použiju komponentu v jiném projektu, který ale nepoužije vše potřebné. PHP si ale může spustit třeba tisíc uživatelů během sekundy, plus si na stejném serveru spustí spousty dalších uživatelů další skripty a v tom případě je sebemenší zatížení nežádoucí.

nebo jsem úplně mimo v těch úvahách?

Je jasné, že v prostředí PHP, v podstatě ryze sychronního jazyka, některé objektové nástroje nejsou třeba a vlastně ani neexistují. Třeba zmíněné eventy.
Pořád ale zbývají přednosti zapouzdřenosti, přehlednosti, rozšířitelnosti, autoloadingu, víceúrovňového zachytávání vyjímek a podobně.

igamenir
Nějak jsem zatím nepochopil, proč bych ztrácet čas vytvářením toho všeho při generování stránky, které jen proběhne kódem a skončí.
Tak to zas nechápu jako důvod já :-)

Skript, který proběhne za několik sekund, ještě nemusí být nutně jednodušší na vývoj než program, který běží několik hodin :-)

Já vidím hlavně výhody při vývoji- zapouzdření, přehlednost, znovupoužitelnost.
Příklad na znovupoužitelnost: redakční systém mého webu a fotogalerie, kterou jsem napsal, používají šablonovací systém, který jsem udělal už předtím pro úplně jiný projekt. Stejným způsobem se dají používat třídy získané od úplně jiných lidí.
Příklad na zapouzdření a přehlednost:
Třeba zobrazení nějaké stránky na mém webu funguje tak, že vezmu z GETu název požadované stránky a přehodím ho objektu redakčního systému, ať si s tím poradí.
Takže pokud skript zjistí, že uživatel chce zobrazit stránku, prostě z GETu přečte název stránky a řekne redakčnímu systému, že chce kód pro ten název a pak zobrazí to, co dostane zpátky. Nestará se, jestli stránka existuje, kde je chybová stránka, atd. - to už je věc toho objektu pod ním.

Díky tomu má taky hlavní skript celkem 28 řádků, včetně "formátovacích" prázdných řádků a komentářů.

Joker
„Třeba zobrazení nějaké stránky na mém webu funguje tak, že vezmu z GETu název požadované stránky a přehodím ho objektu redakčního systému, ať si s tím poradí. “
To přece není věc OOP, stejně tak to mohu mít udělané procedurálně nebo třeba funkcionálně. I v procedurálně napsaném kódu můžu přece jen zavolat nějakou funkci start(), které předám GET parametr a o vše ostatní už se postarají funkce pod tím…

huf
„Kolik z vás ho používá a jaké má výhody?“
Já a výhody už byly řečeny. Zapouzdřenost, daleko vyšší přehlednost, než kdybych to psal nějakým procedurálně-bastl způsobem.

Timy
To přece není věc OOP, stejně tak to mohu mít udělané procedurálně nebo třeba funkcionálně.
Souhlasím. Jde o to, že nejen funkci start, ale veškeré další zpracování- včetně šablonovacího systému, práce s databází atd.
Samozřejmě i to by šlo "simulovat" strukturovaně nějakou sadou funkcí a globálních proměnných, ale pak už se mi začnou motat názvy funkcí a proměnných, nebudu vědět co už kde používám, co vlastně k čemu patří atd.

Já bych řekl, že strukturovaně sice jde dosáhnout podobného výsledku, ale bude to daleko méně přehledné a ve výsledku budou objekty lepší.

Joker
„Příklad na znovupoužitelnost: redakční systém mého webu a fotogalerie, kterou jsem napsal, používají šablonovací systém, který jsem udělal už předtím pro úplně jiný projekt. Stejným způsobem se dají používat třídy získané od úplně jiných lidí. “
To je vlastně dost podobné, jako to, co jsem zmiňoval předtím, napadá mě teď. Opět to není moc o OOP, ale spíše o tom, jestli člověk důsledně píše konstruktory/selektory nebo ne. Fotogalerie je moc velký příklad, zkusím to vysvětlit na něčem jiném, třeba stupidní příklad se souřadnicí.

Objektové řešení: budu mít jednu třídu Point, která bude mít dvě vlastnosti X a Y. Pokud budu chtít nový bod, jednoduše vytvořím instanci této třídy a mám reprezentaci bodu.

Funkcionální řešení: napíšu si konstruktor makePoint(X, Y), což bude funkce, která bude vracet dvouprvkové pole, kde na první místě bude X-ová hodnota, na druhém Y-ová. Dále si napíšu selektory getX(Point) a getY(Point), které mi budou vracet požadované hodnoty.

O co je druhý přístup méně znovupoužitelný? Není problém si ty funkce pojmenovat třeba Point_getX, aby v tom byl trochu větší pořádek. Zároveň si tyto funkce můžu i „zapouzdřit“, při nastavování hodnot mohu kontrolovat, jestli jsou to čísla. Tím se dostávám k tomu, co jsem tak nějak chtěl říct — OOP je především o lepší přehlednosti a lepší a jednodušší správě. Zde by byl ještě problém v tom, že zapoudřenost není úplná — případný uživatel si může měnit data přímo, nic ho vyloženě nenutí používat selektory, což by přes objekty nemohl.

„Já bych řekl, že strukturovaně sice jde dosáhnout podobného výsledku, ale bude to daleko méně přehledné a ve výsledku budou objekty lepší.“
Před odesláním jsem si ještě refreshl, takže vidím, že se asi shodujeme :-).