Jak je to vlastně s OOP?

Budulínku, doporučuji prostudovat toto

Budulinek
Prestuduj si Zend Framework Quick tutorial. Je tam kompletna web aplikacia (board) s OOP nad databazou.

srigi
ZF neni IMHO moc dobrá volba pro pochopení principů OOP aplikací

kajaman
No já nevím, jestli je dobré ten odkaz číst. Prohlašovat o kódu

že vypadá báječně?? Index.php ve wordpressu vypadá podobně a za obojí bych lískal ... třeba sNews si dlouho vystačily s jedním souborem.


Jednořádkové metody volající jiné metody jsou obecně ZLO. Hlavně Symphony toto dovádí ad absurdum.


Dependency injection není pro začátečníky vhodná.

Budulinek
co dál? Další třída na vkládání informací do DB, pak pro zobrazování?
OOP ve skutečnosti není o tom, aby se všechno přepsalo do tříd (i když bohužel existují jazyky, kde všechno musí být uvnitř tříd). Objekty by se měly používat tam, kde se uplatní jejich typické znaky a přednosti - 1. reprezentace uzavřených celků, které mají nějaké charakteristiky a mohou se určitým způsobem chovat, 2. reprezentace podobných entit, které jsou si dost příbuzné. Například automobily se dají hezky modelovat jako objekt - každé auto se umí rozjet, zastavit, každé auto má kola, karoserii, motor apod. Jednotlivá auta se paak od sebe liší značkou, modelem, barvou ...

Mastodont
„Například automobily se dají hezky modelovat jako objekt “
což mě napadá, že by si kolega Budulinek mohl zkusit robota Karla :-)

Určitě ano, Karel byl fajn!

Budulinek
„Co se týče Zend Framwoerku, tak na ten jsem koukal, ale radši bych na začátek něco jednoduššího.“

Z tvojej otazky som pochopil, ze by rad vedel ako v OOP abstrahovat pracu s databazou. Uznavam, ten tutorial je pomerne narocny. Nemusis ale studovat cely tutorial, zameraj sa na triedy MODEL a CONTROLLER, vsetko ostatne je vlastne iba podporny kod.

kajaman
„ZF neni IMHO moc dobrá volba pro pochopení principů OOP aplikací“

Praveze si myslim, ze ZF je vhodny pre pokrocilych PHP programatorov, lebo tento FW naplno vyuziva OOP moznosti PHP 5.1. Napr. to ako ZF implementuje pluginy je IMO velmi poucne (plugin_brooker, v ktorom su ulozene objekty jednotlivych pluginov a pod.).

Budulinek
Podle mě ten dotaz není ani tak na samotné objektové programování, jako spíš na objektový návrh.

Takže k otázce, jak postupvat v případě, ze si chci vytvořit web, kde budu dejme tomu vkládat do DB auta, k nim nějaký popisek (třeba závadu) a tyto údaje pak zobrazovat.
Takže, udělám si třídu na připojení k DB, to je jasné, ale co dál? Další třída na vkládání informací do DB, pak pro zobrazování? Nějak mi tady pořád uniká ta základní souvislost. Nemáte někdo tip, kde bych tohle mohl konečně pochopit? Popřípadě, jestli máte nějakou malinkou aplikaci, kterou bych mohl prozkoumat :)
To je jako s tou poučkou o kreslení: Chci-li nakreslit strom, nemůžu začít od nějakého místa kreslit lístečky, ale nejdřív načrtnout kmen, korunu, hlavní větve a pak postupovat k detailům.
Podobně analýza obvykle (jsou teda i výjimky) začíná obecnými věcmi a postupuje směrem k detailům.

Tj.:
1. Začnu systémem jako celkem- co má dělat, s kým komunikuje ("odborně" se tomu říká use-case). Tzn. "co vlastně chci vytvořit" (tj. řeším věci typu že budu zpracovávat údaje o autech, bude se komunikvat s uživateli, všichni uživatelé budou moci prohlížet všechny záznamy, ale upravovat a mazat jen svoje, krom administrátora => různé role uživatelů).
2. Najdu si základní prvky-objekty v systému a vazby mezi nimi
3. Podle potřeby se složité prvky dále rozloží na více jednodušších
4. Zjistím, že mi z toho pěkně vyplynula struktura tříd v systému :-)

U tohohle jednoduchého příkladu by to asi nemělo cenu, ale u složitějšího by se nejdřív dělal "funkční" návrh systému, který by obsahoval "business" objekty a procesy, a až na jeho základě "technický" návrh, který už obsahuje "programovací".

Shrnutí: Podle mě je nejlepší při návrhu začít od systému jako celku a postupně ho rozkládat na základní prvky, ty na jednodušší prvky atd. Pak je celkem jasné, proč tam který objekt je a jak spolu souvisí.

Přitom ale není univerzální návod, jak moc složité nebo dekomponované objekty dělat, tj. třeba kolik tříd se má použít pro komunikaci s databází apod.

Mastodont
„Například automobily se dají hezky modelovat jako objekt - každé auto se umí rozjet, zastavit, každé auto má kola, karoserii, motor apod. Jednotlivá auta se paak od sebe liší značkou, modelem, barvou ...“
Pro databazi automobilu je to ale naprosto nepouzitelne.

Joker
„2. Najdu si základní prvky-objekty v systému a vazby mezi nimi “
Lehce se rekne ;)

„U tohohle jednoduchého příkladu by to asi nemělo cenu“
Presne tak.

Budulinek
OOP by pro tvou aplikaci nemelo smysl. Musis rozdelovat OOP od frameworku. Frameworky jsou sice psane objektove, ale pokud v nich napiseme jednoduchou aplikaci pro spravu databaze aut, urcite jsme nenapsali aplikaci s kvalitni objektove orientovanou architekturou. Mezi frameworkovymi objekty se musi nachazet jeste nase objekty, ktere tvori entity nasi problemove domeny, ktera by mela obsahovat rozhodne vice objektu. V tvem prikladu bych nasel tak akorat Auto a Uživatel, ktereho si musim jeste domyslet ;) To je malo.

„asi si zkusím cvičně napsat něco menšího. Uvidíme, jak to půjde a asi to bude nejlepší způsob, jak začít uvažovat objektově“
Tak s tim nesouhlasim. Pokud si neco napises cvicne, preskakujes:

- pozadavky na system (ty lze utvorit v hlave)
- analyzu = hledani entit problemove domeny a jejich vztahy
- navrh = dotazeni trid do "konce"

a vrhas se rovnou na implementaci. Pochop, ze OOP je abstraktni rovina, ktera sice lze tak trochu vyjadrit kodem, ale naucit se objektove premyslet lze nad kodem jen tezko.

suky
Tak s tim nesouhlasim. Pokud si neco napises cvicne, preskakujes
Nemusí. Může si udělat "cvičně" i analýzu jednoduchého problému :-)

Spíš jde o přístup- je potřeba jít "shora dolů"- tj. začít problémem jako celkem, identifikovat hlavní prvky a vztahy mezi nimi... no jak jsem psal výše.
Udělat to "zdola nahoru", tj. vzít strukturovaný program, přepsat ho do objektů a pak v tom hledat nějaký "vyšší smysl", vede právě k tomu, že není jasné, proč tam který objekt je... v horším případě dokonce objekty v programu ani neodrážejí reálné objekty, které se za nimi mají skrývat.

Joker
A myslis ze jen tak cvicne zvladne rozkladat velky problem na mensi?

„ v horším případě dokonce objekty v programu ani neodrážejí reálné objekty, které se za nimi mají skrývat.“
No prave, jen tak cvicne si to zkusit muze, ale ten vyssi smysl se mu podle me bude hledat tezce.

suky
A myslis ze jen tak cvicne zvladne rozkladat velky problem na mensi?
Já psal o tom, že nevidím problém začít na "malých" příkladech. Nás to třeba na vejšce učili taky na věcech jako zjednodušená autopůjčovna a zjednodušená knihovna... a ne že bychom se hned pustili třeba do modelování ČEZu nebo Škoda Auto :-)

A jestli to zvládne... podle mě ano. Otázka je, jestli to zvládne "správně". To ale leckdy nezvládají ani mnozí z těch, kteří to mají jako náplň své práce :-)

Joker
„jestli to zvládne "správně".“
O to mi slo, spis bych mu doporucil nejakou literaturu, ktera mu nejaky priklad autopujcovny predvede... nez zacinat z niceho.

Budulinek
zkus si navrhnout zakladni kostru objektu treba toho autoservisu - proste jenom nazvy objektu a zakladni metody ... napis to sem a nekdo ti urcite poradi, opravi, ...

Budulinek
Literatura je, ale ne specificky pro PHP:
http://www.grada.cz/katalog/seznam/myslime-objektove-v-jazyku-java_5401/
http://knihy.cpress.cz/knihy/pocitacova-literatura/programovani/oop-objektove-orientovane-programovani-bez-predchozich-znalosti-pruvodce-pro-samouky/

Budulinek
Pro PHP knihy jsou, ale jen v angličtině. Slušné jsou třeba
http://www.apress.com/book/view/9781590599099
http://www.packtpub.com/oop-php-5/book
U českých překladů ti neporadím, čtu originály, protože kvalita překladů je mnohdy velmi mizerná.

Budulinek
trochu vlastni snahy, vsak nerikam, at to hned pise, jenom napis jak bys to udelal a my te treba nasmerujeme spravnou cestou.

Budulinek
Kdysi jsem napsal pár článků o OOP, třeba z toho něco pochopíš. Přečti si spíš tu praktickou část, ta teoretická snad ani není dokončena, ani opravena. Příklady jsou tam psané v C#, ale to není moc podstatné, lze to jednoduše a ekvivalentně přepsat do PHP.

Pro PHP toho je málo, protože PHP historicky není objektově orientovaný jazyk. Vpodstatě na objekty tak zvolna přechází a výrazněji "objektová" je až verze 5.
Takže co jsem viděl učebnice PHP, obvykle to je stylem jako že se všechno vysvětlí pomocí strukturovaného programování a pak je jedna kapitola o tom, že v PHP jsou taky objekty.

Navíc pro výklad a pochopení objektově orientovaného přístupu není PHP zrovna ideální "demonstrační" jazyk, právě kvůli výše uvedenému- PHP není "čistě" objektově orientované a spousta objektových "vychytávek" v něm (zatím?) není.
(Což ale neznamená, že by PHP bylo nějak horší, "čistě objektově orientované" nejsou ani jazyky jako C++, dokonce ani Java. Vím snad jen o jednom opravdu "hardcore" objektovém jazyku- Smalltalk)

Joker
Co znamená "čistě objektové"? IMHO takový C# je dost čistě objektový :-).

[#1] more, bracho neuc sa OOP v PHP,, PHP neni objektovy jazyk, PHP je cista stoka, ano aj v PHP mozes spravit triedu more mozes dedit mozes zapuzdrit data, ale ta OO cast tam bola dorobena nasilu a PHP ta nuti pouzivat funkcie... a mysliet proceduralne...

napr. uz len take keketiny ze zistenie dlzky retazca musis riesit cez funkciu:

$stringVar = "Textova hodnota";
$len = strlen($stringVar);

v normalnom OO jazyku je vsetko objekt aj retazec sa sprava ako objekt

string stringVar = "Textova hodnota";
int length = stringVar.Length;

Před pár dny jsem viděl na nějaké stránce benchmark, ze kterého vyplývalo, že objekty jsou v PHP několikanásobně náročnější než klasický přístup. Skript pak zabírá víc paměti a dělá to samé dýl. Už si nepamatuju, kde to bylo, teď mi google dává jenom takové výsledky.