« 1 2 »
Autor Zpráva
Icepoint
Profil
nevite nekdo o nejaky elektronicky prirucce PHP OOP snadno a rychle ??? Vsude chtej totiz OOP, vsichni rikaj jak to je super a jak to zjednodusuje praci ... ja to ale vubec nechapu ...
ah01
Profil
Ono základní problém není pochopit syntaxi (jak co zapsat), ale pochopit a zažít si "objektové myšlení" nad problémem.

Na Intervalu je http://php.interval.cz/objektove-orientovane-programovani-oop-v-php/ , ale nejdřív bych si přečet http://cs.wikipedia.org/wiki/Objektov%C4%9B_orientovan%C3%A9_programov %C3%A1n%C3%AD , což je takový přehled o co vlastně jde, a pak si prošel http://objekty.vse.cz/Main/HomePage (hlavně kapitolu o objektovém myšlení).

No, snadno a rychle to asi nepůjde, ale vydržte, stojí to za to ...
llook
Profil
Snadno a rychle? To bych taky rád viděl.
jonge
Profil
Icepoint
Ty jsi úplně stejný jako já... taky jsem se to chtěl naučit, ale po několika větách, které jsem vůbec nepochopil (typu: Jednotlivé prvky modelované reality jsou v programu seskupeny do entit, nazývaných objekty) jsem toho nechal... Já být tebou bych s tím ani nezačínal... ale jak chceš...
WertriK
Profil
ah01

To utrefil naprosto přesně zažít si "objektové myšlení" nad problémem.

Taky jsem se to chtěl naučil a chci, ale prostě nevím co v tom mám udělat. Vůbec netuším, něco praktického a něco z čeho bych se odrazil - ale bohužel dochází fantazie :(
Hugo
Profil
WertriK

Tady bohužel potřebuješ na začátek spíš nastudovat teorii, praxi až později. Protože jde o samotný přístup k programování, ne o programování.

Teda IMHO.
Anonymní
Profil *
tam toho je, vcelku ide len o to ze nejake funkcie su zoskupene spolu s premennymi a ostatne je len omacka
Hugo
Profil
Anonymní

To je právě velmi rozšířený omyl.
Anonymní
Profil *
hehe, no hej.. ale tak nasurovo podane niekomu kto vobec nevie o com je OOP
Hugo
Profil
To je právě IMHO to nejhorší, co můžeš pro laika udělat. Protože tak získá špatný pohled na věc. OOP je úplně jiná filozofie programování oproti procedurálnímu programování. Není to jen o tom, že obalíš procedurální kód třídou.
Anonymní
Profil *
mas pravdu ale taktiez laikovi nepomoze ked mu podas hned pojmy o ktorych pocuje prvykrat v zivote (objekt, trieda, metoda, vlastnost, pseudopremenna, atd..) hned naraz. to sa potom racej na to vyprdne (s prepacenim)
akonahle bude vediet o com je to zhruba rec, po nejakom case si to sam vyskusa a zacne to chapat z nadhladu
thingwath
Profil
Nezdá se mi, že bychom nutně potřebovali zavést milión pojmů a hned se měli pustit do řešení teoretických problémů typu dědičnost porušuje zapouzdření. Podle mě k tomu lze přistoupit intuitivně. Přijde mi jenom přirozené, že aplikaci budeme navrhovat tak, že se pokusíme identifikovat objekty, které jsou součástí systému, jejich vlastnosti, činnosti které provádějí a vzájemné vztahy. A pokud to není krokem k OOP, tak už nevím :-)
Icepoint
Profil
Csem diky :) snad z toho neco bude .... ja cet o OOP jen v knizce prohramujemev PHP profesionalne (takova velka cervena bychle) a nejak jsem to z toho nepobral, ale thx
WertriK
Profil
Tak třeba mi řekněte jak by jste řešili knihu návštěv [příklad] v OOP, tak nějak abych z toho pochopil tuhle větu :

"že aplikaci budeme navrhovat tak, že se pokusíme identifikovat objekty, které jsou součástí systému, jejich vlastnosti, činnosti které provádějí a vzájemné vztahy"

popř. bude [možná] stačit jen nástin třeba mi to dojde samo :-)

btw. Hugo nejsem ten typ, který sedne a naučí se přesně jak co má být jen z manuálu, já to prostě musím zkusit a pochopit o co go, to že se to naučím a budu to "papouškovat" se mi nelíbí a ani nechce - uvidím příklad - sesmolím něco sám - mrknu na jednotlivé syntaxe - řeknu "A jó to musí být tak protože ... no jasný" - relátka cvaknou a už tak nějak vím o co go. Ale to jen na okraj :)
thingwath
Profil
Kniha návštěv je možná zbytečně jednoduchá, ale dejme tomu. Z čeho se nám skládá? Ze samotné knihy návštěv, z příspěvků a uživatelů. V praxi asi ještě budeme chtít i nějaký datový sklad, kam budeme příspěvky trvale ukládat. To máme nějaké třídy. Jaké mají mít metody a jaké obsahují data, to už vyplývá samo. Kniha tříd má seznam příspvěvků, příspěvek má text, autora a datum... Co se metod týče, kniha tříd umí přidat příspěvek a zobrazit je. U příspěvku mě nic nenapadá, ten asi žádné funkce nepotřebuje :-)
WertriK
Profil
thingwath
Dík, zítra resp. dnes ráno si to přečtu ještě tak 3x a snad mi to něco řekne :-)
ah01
Profil
thingwath
Přijde mi jenom přirozené, že aplikaci budeme navrhovat tak, že se pokusíme identifikovat objekty, které jsou součástí systému, jejich vlastnosti, činnosti které provádějí a vzájemné vztahy. - to je přesně ono a v tom je největší rozdíl od strukturálního (procedurálního) programování.

WertriK "nejsem ten typ, který sedne a naučí se přesně jak co má být jen z manuálu" - OOP (ten princip uvažování) se stejně z manuálu naučit nedá

Snažil jsem se najít nějaký stravitelný text o OOP pro začátečníky na internetu (česky), ale moc úspěšný jsem nebyl (možná jsem špatně hledal?). Našel jsem akorát zajímavé texty o tom jak učit OOP - http://vyuka.pecinovsky.cz/ (na konci jsou pdfka) a pak hlavně jak se používá v tom či onom jazyku - např. http://objekty.vse.cz/Programovani/OopC

Ale narazil jsem na knihu OOP Objektově orientované programování bez předchozích znalostí - ta OOP sice vysvětluje pomocí Javy a C++, to ale tak nevadí, nejdůležitější je pochopit objektové myšlení, jazyk je už jen nástroj.
ah01
Profil
WertriK tady zmínil "Tak třeba mi řekněte jak by jste řešili knihu návštěv v OOP" - no jak na to reaguje thingwath, jedná se o dost jednoduchý příklad, ale možná proto je vhodný, snadno se na něm dá ledascos ukázat.

Tak jsem se trochu rozepsal a zde najdete Rozbor řešení návštěvní knihy pomocí OOP.
pE eLL
Profil
ah01
jako clovek ktery by se neco o OOP rad dozvedel uvitam vse.


nicmene jsem presvecen ze nam vsem tady chyby jedno a to same - PRIKLAD.
podle me by bylo absolutne super kdyby nekdo zacal napr tu knihu navstev delat normalne v php bez opp a zaroven stejnou i s oop. kdy by pak pri tvorbe popisoval oop jeho vyhody aj.
finc
Profil
to: ah01
Moc pěkné. Ono učit začátečníky OOP není žádná legrace. Sám ze své zkušennosti vím, že pochopit principy OOP je dost velký problém zejména pro lidí, kteří několik let psali procedurálně.
Sám jsem toho příkladem. Učím se OOP cca. 6-7 měsíců a vím, že sice zvládám syntaxi a píšu již vše v classes, ale.... Umím psát OOP (třídy, používat abstraktní třídy, volat jednotlivé metody, vědět, kdy vytvořít statické metody či třídy), ale stále mi chybí ten nadhled nad celým kódem. Sám jsem se k OOP dostal tak, že jsem se začal zajímat o Javu a tam ani jiný způsob volit nejde. A ejhle. V PHP je taky OOP, jenže tak zmršené, že učit se to na PHP je dost sebevražda. Vytknul bych tomu zejména typovou kontrolu, která je pro OOP velice důležitá. (ať už se to týká polymorfismu: volání stejné metody, pouze s jinými typy nebo počty parametrů, díky tomu se i přes stejný název metody může zpracovat naprosto odlišný kód).
Problém v PHP navíc je na úplném začátku. Jak vytvářet objekty z třídy, jak poznat z URL adresy, co mám nyní udělat, co zpracovat.
1) Jedna možnost je, využít OOP jen pro důležité a znovu se opakující věci a jinak psát procedurálně. (ale to je špatně, myslím, že člověk, co se snaží o obojí, nikdy nedosáhne dobrého výsledku)
2) Vytvářet objekt z jednotlivé třídy podle parametrů URL adresy, kde budu mít převodní metodu $_GET["blabla"] == "blabla" ? objekt tridy A : objekt tridy B, dost neefektivní a chybové řešení
3) A myslím, že nejsprávnější způsob je využití modu rewrite. Díky tomu využívat něco ve smyslu:
http://framework.zend.com/manual/en/zend.controller.html

Stejně jako já to nyní dělám, doporučuji lidem, co začínají, či se stále tak nějak plácají v návrhu OOP, mrknout na Zend Framework, pročíst manuál a prozkoumat jejich kod. Myslím, že díky tomu spoustu lidí dostane jiný náhled na programování v PHP.
Jinak pokud se chce někdo skutečně dobře naučit OOP, ať rovnou přejde na Javu nebo C++
Hugo
Profil
Jinak pokud se chce někdo skutečně dobře naučit OOP, ať rovnou přejde na Javu nebo C++

To je pravda, ale tady je forum o tvorbe webu, takze tady bude jeste dlouho prevazovat php.
thingwath
Profil
finc
V tomhle se budu opakovat asi už posté, ale opravdu si nemyslím, že (statická) typová kontrola je pro OOP nutná. Když se podíváte na jazyky kde není, není to o nic horší a můžete jednoduše udělat věci, jejichž realizace by v Javě znamenala desítky až stovky řádek šíleného kódu.
finc
Profil
to: Hugo
Samozřejmě. Jen jde o to, že na těchto vyšších jazycích to člověk pochopí mnohem rychleji a lépe. Tam totiž ti nic jiného než OOP psaní kódu nezbývá. Ještě jsem v jave procedurální kód neviděl. Za to jsem viděl v PHPku takové zvěrstva, že se vůbec divím, že to někoho napadlo :)
Takže zpět. Po 14denním studiu základů javy jsem z OOP pochopil mnohem více než bych to pochopil z půlročního studia na phpku. PHP má být jednoduchý jazyk pro tvorbu malých aplikací. Jeho výhodou má být rychlost vývoje, dobrá základna v podpoře hostingů.
Pokud chce někdo psát v PHPku větší projekt (samozřejmě, že to jde, ne že ne) musí se to OOP naučit. A nejlepší cesta jak toho dosáhnout je si vzít "vyšší"programovací jazyk a naučit se nejprve ten i s OOP a pak se vrátit k PHP.
PHPko je dobré pro začátečníky (je jednoduché, neobtěžuje s typovou kontrolou, není potřeba OOP, stačí to mrskat procedurálně), ale pokud chce někdo z toho dostat víc, tak musí své obzory i víc rozšířit, ne jen na PHP a MySQL.
finc
Profil
to thingwath:
Nutná pro programování asi ne, ale nutná pro ošetření vlastního kodu ano. i PHPko má typovou kontrolu (i když jen na array a vytvárené objekty). Asi věděli proč to dělají.
Já osobně si myslím, že s typovou kontrolou a to zejména na primitivní typy člověk dosáhne lepší přehlednosti, menší chybovosti a lepší orientace kódu.
Pokud jsi něco četl o PHP 6, měli by do metod přidat definování návratových hodnot (sice to nebude povinné), což také spoustu lidí uvítá.
Navíc když vidíš, jak někdo má proměnnou a nejdříve do ní cpe int, pak String a nakonec objekt, tak se nemůžeš divit a proč? Protože je to jenom PHPčkář, který ani neví, že něco dělá špatně ;)
thingwath
Profil
Primitivní datové typy existovat nemusí vůbec, objekt má být všechno ;-) Runtime jazyka i u PHP, i u jiných OOP jazyků typy zná. Ten zásadnější rozdíl je spíš v tom, že ty staticky typované jazyky typu Java je nutno prohnat kompilátorem, který musí všechno znát předem. To u PHP a podobných jazyků není. Takže tu kontrolu (pokud je potřeba) musíte dělat jinde a jinak, ale nijak vás neomezuje. Zrovna PHP je v tomhle stejně běs a děs :-) Asi to ale bude trochu pomalejší (to neplyne z toho samotného faktu, že prvé se kompiluje a to druhé ne).

Když se koukneš do té wikipedie, jako příklad čistě objektového jazyka je tam uveden Smalltalk. Kontrolní otázka, vnucuje statickou typovou kontrolu? ;-)
ah01
Profil
finc, taky jsem názoru, že je lepší učit se OOP na čistě objektově orientovaném jazyku (např. Java), ale J2EE pro tvorbu webu asi moc začátečníků nepoužívá, takže budeme muset zůstat u PHP. Myslím že v PHP lze použít OOP velmi dobře, ale více to vyžaduje určitou "kázeň" programátora a s tím souvisí i ta typovost. Pro začátečníka je typový jazyk asi lepší, prostě ho to nutí zamyslet se nad typem a víc si zašije co je nutné pro dědičnost a polymorfizmus.
finc
Profil
to: thingwath
Ale to, že to musí znát předem je dobře.
Na tohle máme každý asi jiný názor. Já osobně bych v PHP uvítal, kdyby zde typová kontrola existovala, ať už se to týká parametrů metod nebo vrácené hodnoty metody. Jeden z důvodů jsem napsal výše.
To, že některé věci se v Javě musí obcházet (např. v PHP: metoda vrátí buď false nebo se provede správně a vrátí hodnotu, která nemusí být typ Boolean, v Javě toto zařídít nelze), je pravda, ale k tomu zase existují vyjímky.
To vytýká i spousta vývojářů v PHP, že sice existuje možnost použít vyjímky, ale funkce v php jsou stále dělány pomocí návratových hodnot Boolean.
Na tohle existuje dost flame po forech, takže myslím, že nemá cenu to tady znovu rozjíždět. Osobně zastávám názor, že by se mělo v PHP více přitvrdit, co se týče striktního dodržování psaní kódu.
Snad se spolu alespoň shodneme na tom, že takové pole by mělo být předem inicializované.
Veškerá tato volnost vede jen k chybám a nekvalitnímu programování v PHP. Otázkou možná je, jestli PHP nemá zůstat jen jednoduchý skriptovací jazyk. Ale jak říkám, to už zacházím úplně někam jinam.
Abych se vrátil k OOP:
Rudolf Pecinovský v jedné své knize napsal: Je mnohem snažší naučit principy OOP člověka, co nikdy neprogramoval, než předělávat programátora, co píše svůj kód procedurálně již několik let. S tímto tvrzením musím souhlasit. Navíc není to otázka jednoho týdne či měsíce, pro celkové pochopení a skutečně psaní objektově orientovaného kódu je zapotřebí studium minimálně roku či dvou. A to nejen na PHPku, kde objektový model není úplně do konce navržen jako u jiných jazyků, které jsem zmiňoval.
thingwath
Profil
finc
Všechno musí nějak vzniknout a i to pole musím nějak vytvořit. Ale je otázka, proč by koho mělo dále zajímat, jestli to je pole. Podstatné je, že se to jako pole chová. Mně se naopak zdá, že tento přístup vede ke značným složitostem. Musím mít spousty rozhraní a složitou hiearchii tříd. A v tom se též snadno udělá chyba. Navíc je pak hodně těžko řešitelný problém, když udělám v prvním návrhu nějakou chybu. Ale nejde jenom o to. Nepředstavujte si každopádně PHP, to moc hezký příklad není.
Joker
Profil
Tak já se taky přidám do diskuse... upozorňuju předem, že jak já začnu něco vysvětlovat, bývá to nadlouho :D Ale zase mi spousta lidí říká, že to umím pěkně vyložit :o)
Disclaimer: Samozřejmě jsem jenom člověk a můžu se mýlit, takže neberte to co napíšu jako pevně danou pravdu :-)

Takže:
Základem OOP je vpodstatě myšlenka "všechno je objekt". Na něčem takovém je založené i naše vnímání světa, předměty rozeznáváme podle toho, jak se liší od ostatních, u předmětů identifikujeme různé vlastnosti a předměty s podobnými vlastnostmi třídíme do kategorií.
Teorie
Třeba objekt "moje auto"- má různé vlastnosti, v programování "atributy": výrobce, model, rok výroby, barva, atd. Bývají to věci, které označujeme podstatnými jmény. A pak taky něco dělá... to jsou věci, které označujeme slovesy. V programování se jim říká metody. Například můžu nastartovat. A tady je první výhoda OOP- říká se tomu "zapouzdření". Procedurálně bych nastartování auta řešil nějak že vezmu klíček, otočím v zapalování, vyšle se nějaký elektrický impuls do ECU, tam se to nějak zpracovává, rozsvítí se kontrolky, pak se kontrolují jednotlivé systémy v autě, blablabla. V OOP na to koukám úplně jinak. Vím, že mi někdo udělal objekt "moje auto" a dal mi jeho "protokol"- soupis použitelných metod a atributů. Takže přeneseně- vím, že auto má metodu nastartuj(klíček). Nezajímá mě, co se děje uvnitř, prostě jen (z protokolu objektu) vím, jak mám metodu zavolat (vložením klíčku a otočením) a co se stane (programátorsky řečeno: vrátí se bool- nastartováno/nenastartováno a chybu zjistím v nějakých atributech... například špatný klíček- atribut "kontrolka imobilizéru" má hodnotu "rozsvícená").
Další důležitá věc na OOP je zapouzdření- můžu vložit objekt do jiného objektu. Například uvnitř objektu "auto" se nachází poměrně složitý objekt "motor". Opět to ohromně zjednodušuje práci, "vývojář" toho auta nemusí do detailu vědět, jak vevnitř funguje ten motor, akorát dostane parametry toho motoru- protokol objektu.
Další věc je dědičnost- objekty s podobnými vlastnostmi seskupujeme do tříd. Na světě existuje spousta dalších objektů, podobných objektu "moje auto". Proto je zařadím všechny do třídy "auto". Třídě auto definuju atributy a metody, o těch už jsem mluvil na začátku. Moje auto potom bude konkrétní naplnění, instance třídy "Auto". Rozdíl mezi třídou a instancí uvidíte, když si někdo koupí nové auto a vy se ho vyptáváte: Co to je za auto? Jakou má barvu? Jaký je tam motor? Atd. Vy víte, že má objekt třídy auto a ten má nějaké atributy... a teď se ptáte, jak vypadá ten objekt- jaké jsou hodnoty jeho atributů.
A teď v čem je to dobré- například třída auto bude mít tu metodu nastartuj(klíček). A já budu potřebovat místo objektu "moje auto" použít třeba objekt "Pepy auto".
Imperativní přístup: Tak Pepy auto je například stodvacítka a vůbec nemá řídící jednotku, takže všechno bude úplně jinak. Objektový přístup: Vím, že Pepy je objekt třídy auto, takže má metodu nastartuj(klíček). Vezmu klíček a nastartuju. To, že metoda nastartuj(klíček) je v Pepy autě udělaná úplně jinak než v mém autě mě vůbec nezajímá.

Praxe- PHP
Analýza:
Imperativní přístup: Mám problém. Navrhnu algoritmus, který bude problém řešit. Napíšu program, který bude realizovat ten algoritmus.
Objektový přístup: Mám problém. Identifikuji potřebné objekty. Zjistím, jak spolu ty objekty komunikují. Určím atributy a metody objektů. Naprogramuji metody.

Využití zapouzdření:
Asi nejpoužívanější věc: třída database, která mi bude realizovat připojení k databázi. V ní budu mít například metodu query($sql, $die=false). Metoda mi nad databází provede SQL dotaz, v případě chyby podle hodnoty parametru $die buď ukončí skript s chybovou hláškou anebo jenom vrátí false.
A budu mít tenhle objekt napsaný na třech serverech- na jednom bude MySQL databáze, na druhém PostgreSQL a na třetím nebude žádná databáze a data budou uložena v XML souborech. Na samotných skriptech nebude nutné změnit ani řádku, akorát se přepíše metoda database->query.

Využití skládání:
Nedávno jsem to řešil- mám nějaký svůj objekt, který mi řeší správu věcí jako přihlášení a podobně. Mám tam metodu login_check(), která kontroluje, zda je uživatel přihlášen a pokud ne, přesměruje ho na přihlašovací stránku. Problém je, že login_check() a ještě některé další metody potřebují připojení k databázi... jak to udělat? Nejdřív se ze skriptu připojím k databázi a předám připojení jako parametr. To je vpodstatě imperativní uvažování. Objektové uvažování je- potřebuju mít uvnitř svého objektu atributy a metody z databázového objektu. No tak prostě udělám ten databázový objekt součástí toho svého objektu!
A protože se potřebuju připojit k databázi hned na začátku, hodím si přihlašovací údaje rovnou do konstruktoru.
Skript na kontrolu přihlášení:
$muj = new Muj($server, $jmeno, $heslo, $databaze);
$muj->login_check();
A ještě připojím třeba kontrolu oprávnění:
$muj->check_privilege(R_ADMIN);

Všimněte si přenositelnosti a znovupoužitelnosti.
Změním databázi? Překopu způsob přihlašování? No a co, hlavní skript se vůbec nezmění

A složitější věc: Můj systém bude někdy používán i na jednoduchých stránkách, kde jsou uživatelská oprávnění na nic, stačí přihlášen-nepřihlášen. Rozhodnu se tedy udělat parametr, který kontrolu oprávnění odstaví.
Imperativní přístup:
přidám parametr do funkce check_privilege() - něco jako check_privilege($pravo, $kontrolovat) a na začátek funkce přidám ještě řádek if(!$kontrolovat) return(true);
a přepíšu všechna volání dané funkce.
Jednodušší varianta je si nastavení vytáhnout z databáze hned někde na začátku stránky a uložit do globální proměnné a ve funkci login_check pak používat tu globální proměnnou.

Objektový přístup:
Mám vlastnost "stav kontroly práv - zapnuto/vypnuto". No to je jasný atribut objektu. Přidám nový atribut do třídy.
Nastavení se čte z databáze jednou, hned na začátku... tak to patří do konstruktoru.
A do metody check_privileges($pravo) přidám řádek:
if(!$this->kontrolovat) return(true);

Všimněte si: přidal jsem poměrně významnou funkčnost a hlavní skript se vůbec nezměnil. Změnil se vnitřek mého objektu, ale díky zapouzdření lze můj objekt používat nadále úplně stejným způsobem jako předtím.
A proč by se s tím taky měl hlavní skript trápit? Hlavní skript mi řekl: Zjisti, jestli uživatel má toto právo. O to, jak to zjistím, už se hlavní skript nestará.


Uff... já vám říkal, že to bude dlouhé :o))) Tak doufám, že to taky bude někomu užitečné
Joker
Profil
Chyba:
"Další důležitá věc na OOP je zapouzdření"
má být:
"Další důležitá věc na OOP je skládání"
« 1 2 »
Toto téma je uzamčeno. Odpověď nelze zaslat.

0