Názory ke článku OOP v PHP – Programujte.com

Super clanek. Diky za nej. Nejsem primarne php programator a OOP obecne pouzivam uz dlouho, ale ocenuji vyznam tohoto clanku pro osvetu php programatoru. Snad pozvedne uroven php programatoru (tedy te bastlirske casti z nich, cest vyjimkam). Jenom bych k OOP dodal, ze lide po pochopeni zakladnich principu maji tendenci OOP cpat vsude a roubovat na vsechno (sam sem to tak delal)...neni to uplne nejlepsi a casto si tak pridate praci. Nejlepsi je vzdy zlata stredni cesta.

To, že ukážete lidem jak se píšou základní konstrukce neznamená, že to někomu pomůže pochopit psání aplikací pomocí OOP. Na internetu mi chybí články, které by lidem vysvětlili analogii objektů s náhledem na fungování aplikace (i kdybychom vysvětlovali proč tak psát přes nějakou hloupost s auty), takových článků je naopak na internetu přehršle, tedy z mého pohledu, ano, pěkná sumarizace syntaxe, nikoliv snaha vysvětlit obecné fungování.

Článek je moc hezký, mám jen několik drobných připomínek:

[seznam]Viditelnost protected je dostupná i pro předky objektu, nejen pro potomky.
To, že si nedovedeme představit využití dědičnosti u nějaké třídy, podle mě ještě neznamená, že bychom ji měli deklarovat jako final. Má to význam spíš tam, kde by nám vytvoření potomka nabouralo zbytek kódu.
Základní metoda normalizovatCestu by mohla volat funkci realpath.[/seznam]

Škoda také nejednotného oddělování slov ve vlastnostech a metodách.

Článek není špatný, akorát bych měl několik poznámek:
1) připadá mi to trochu jako manuál, ten je na php.net, OOP není o syntaxi ale o způsobu myšlení a hlavně praxi (ostatně jako každý jazyk)
2) procedurální programování není špatný a nechápu, proč je dotyčný označen za bastliče. Na tom přece není nic zlého, z praxe jsem spíš pro přehledný jednoduchý procedurální webík než spagetti bastl či nevhodně navržené OOP. Samozřejmě souhlasím s tím, že úroveň PHP programátorů je značně kolísavá a OOP nutí alespoň nějak úhledně psát kód. Na druhou stranu se totéž dá udělat i s funkcemi a kdo píše "jako prase", OOP se učit asi nebude.
3) "Objekt je něco, co dokáže udržovat svůj stav". To v případě PHP IMHO není zcela pravda. Pokud nepoužijeme speciální cache či např. SESSION, objekty mezi stránkami se stále vytváří a zanikají. Ideální stav by bylo něco na způsob Javy (tam prý lze "odložit" instanci to speciální cache)
4) abstract function a interface jsou pro mne divnost. Ve Vašem příkladě je to již patrné - když mám předka a definuji že v potomcích používám nějakou metodu, definuji ji jako abstract protected function. Potom ale i v potomkovi musí být protected (nebo public), což ale mi přijde divný - ta metoda pro toho potomka je ve vztahu private, ne protected. Nikdo další ji již dědit nemusí a potomek je třeba final. Interface jsou IMHO užitečné při rozsáhlejším počtu vetších tříd, jinak mi to přijde zbytečné.
5) jestli bude další čánek, přimlouvám se rozebrat nativní PHP interface a třídy, popř. výjimky jako např. interface Countable apod. - zkrátka SPL extenzi. Do toho osobně moc nevidím.
Na závěr musím poděkovat za "osvětu" PHP komunity, v poslední době co jsem viděl za "kódy", byla síla... jak jsem již řekl, obávám se však, že ten, kdo chce psát rozumně, hledá tyto možnosti, ale kdo ne, bude psát "jak čuně" pořád...

1) Jak říkal LamiCZ je to spíš o způsobu myšlení a tak jsem doufal, že se článek bude právě ubírat tímto směrem ale i tak jsem se dozvěděl pár věcí, které jsem ještě nevěděl.

2) Co se týče inteface v kombinaci s hints řekl bych, že to má uplatnění ve chvíli kdy chci použít metody jednoho objektu v objektu jiném aniž bych musel používat $this->$objekt->metoda

interface rozhrani {

  public function Metodka(Foo $foo);

}



class Trida implements rozhrani {

  public function Metodka(Foo $foo){

    $foo->fooMetoda();

    $foo->fooPromenna;

  }

}

  public function Metodka(Foo $foo){

    $foo->fooMetoda();

    $foo->fooPromenna;



    $this->DalsiMetodka($foo);

  }

Reagoval na komentář od uživatele Anonymní uživatel :

public function DalsiMetodka($foo){

	//cokoliv

}

oop v php mi poněkud připomíná hysterii okolo zavádění množin do učiva počtů, anebo chcete-li matematiky, ve škole. V programovacích jazycích a programování je děsně moc moódních trendů. Stejné to je s oop a php. Stačí se ohlédnout zpět, co z programovacích jazyků a způsobu programování přežilo 20 roků? Moc toho není... Já vám, teenageři teď namítnou, že před 20 roky nebyly počítače. Bohužel se mýlí, počítače byli a programovací jazyky a oop také bylo (jen se tomu tenkrát neříkalo "oop").
Já vidím problém někde jinde, a to ve schopnostech lidí´, tedy těch co vytváří programy. Jde o to, že většina se nabifluje kódy a syntaxi nějakého jazyka, příšerně na to lpí (a většinou si myslí, že sežrali všechnu moudrost světa), bohužel mají elementární problém vymyslet slušný algoritmus. Podstatné jsou totiž efektvní algoritmy a ne způsob, jakým ve zdrojáku naťukám kódy, lhostejno v jakém jazyku.

To je opravdu úžasný článek. Programování mi celkem jde a už narážím na problém, že je stále těžší získávat nové informace o programování. Váš článek mě toho naučil opravdu hodně. Zítra se podívám na další články od vás, chci se toho naučit co nejvíc a konečně jsem trochu objevil zdroj.
Jsem unešen, děkuji.

Reagoval na komentář od uživatele remmidemmi :
Krásný příspěvek. V něčem sice souhlasím ale ta móda také vždycky byla a bude. Navíc člověk, který se podle Vás jen "nabifluje kódy" tak to asi daleko nedotáhne.

Ačkoliv musím uznat, že já jsem s programováním začínal úplně sám a proti ostatním co se ho učili ve škole apod. jsem sice uměl třetinu toho, co uměli oni ale přesto jsem vyřešil problémy, které byli pro ně takřka neřešitelné..

Reagoval na komentář od uživatele remmidemmi :
Píšete nesmysly.
Je pravda, že v programování je spousta různných cest a uliček z nichž některé se občas stanou módním trendem a následně zapadnou.
OOP ale není žádný módní trend. Je to už 20 let trvající převládající paragigma pro programování. Paradigma zcela nezbytné pro vývoj středních a velkých projektů (kde byste se s funkcionálním programováním - předchozím převládajícím paradigmatem - zcela ztratil). A pokud chce PHP být nástroj pro něco víc, než miniprojekty, tak musí toto paradigma přijmout.
OOP existuje opravdu dlouho (akorát jenom těch posledních 20 let je hlavním směrem programování), ale OOP se mu říkalo od začátku.
Že existuje spousta rádobyprogramátorů, kteří sice umí nějaký jazyk (spíše syntaxi), ale skutečně programovat/alogoritmizovat neumí je dlouhodobě platný fakt, který vůbec nesouvisí ani s OOP, ani s žádnými módními trendy v programování.

Reagoval na komentář od uživatele Flasi :
Tak předchozí převládající paradigma bylo pochopitelně procedurální. Funkcionální je teď na úrovni módního trendu a možná bude tím budoucím, možná ne :-)
Hloupá chyba :-(

Dobrá práce. Moc pěkný a komplexní článek. Z knihy, kterou jsem si koupil o OOP v PHP jsem se toho tolik nenaučil.

Jen tak dál...

Reagoval na komentář od uživatele Flasi :
naprostá pravda ... málokdo umí vymyslet Algoritmus který by byl jednoduchý a efektivní ...Jeden muj kolega vzdicky riká že Jazyk je Algoritmus napsaný toršku jinak ... když je ten algoritmus špatný , nečitelný, tak pak i kod je nečitelný a vypadá jako od prasete ... :)

Už dlhšiu dobu sa zaoberam OOP a Dia sa mi osvedčil ako skvely nastroj pri navrhu ale aj anylýzach projektov. V buducnosti by som očakaval že niečo podobne sa stane sučasťou Zend Studia napriklad.
GNU/Linux: http://live.gnome.org/Dia
Windows: http://dia-installer.de/index_en.html

Reagoval na komentář od uživatele Tomáš :
Přesně to je problém všech článků - pochopil jsem co to je objekt, vím co je třída, ale jak se stím pracuje, to jsem zatím nepochopil. Možná by stačilo napsat "udělej tohle protože proto".

Hoši přidejte, posledních 20 let se o oop mluví jako o OOP, ale toto paradigma je zde už z dob smalltalku a ten je z let 70tých. Smalltalk je čístě objetový jazyk od základů.

Abosultne nechapem naco je dobre napisat echo "ahoj"; cez oop na 6 riadkov ? Pouzivanie OOP logicky asi nikdy nepochopim.

No jato zkousim pekne od zacatku a bez toho, abych vubec tridu zalozil mi to hlasi Fatal Error. Nechybi uplne na zacatku neco jako

class Trida {};

???

Další věc:

v článku se píše: "Třída SouborovyLog je potomkem (dědí z) Logu. Rovněž tak třída DevNullLog"

ale nechybí tam tedy "extends"(?):

final class DevNullLog

Pěkný článek, avšak pro laika moc dlouhý a s minimem příkladů, takže k ničemu.

Špatně zvolený typ příkladů - všech.

Článek dobrý hlavně pro ucelený pohled na (základní) syntaxi OOP v PHP. Hlavně jaký je rozdím mezi skládáním a děděním, použití statických a abstraktních vlastností a metod. Mně osobně nejen na tomto článku chybí informace o tom kdy co a proč použít z praktického pohledu

@null_while: Nesouhlasím, přijde mi to naopak :)

@Magman: Kdy, co, proč použít z praktického pohledu - o tom vycházejí celé knížky ;)

A stejně se to člověk nejlépe naučí používat tak, že to bude používat. Dobrý objektový návrh nevznikne tím, že si v nějakém článku přečtu seznam toho, co mám dělat, co za konstrukty kdy využít, nýbrž něco navrhnu, funguje-nefunguje, časem přicházejí nové požadavky, ty staré se mění, refactoruju - a takhle pořád dokola s tím, že vždycky zanechám kód v lepším stavu než předtím.

Praktický (pragmatický) pohled na věc je, že používám, co je potřeba, kdy je potřeba. Tenhle článek není kuchařka, pouze říká, jaké suroviny máš ve spíži - vymyslet, co si uvařit, už musíš sám.

Pro zacatecnika absolutne nepochopitelny, mel by jsi davat vic prikladu aby lidi pochopili jak to vlastne funguje.

#22 Magman
Dědičnost vs. kompozice

Velmi šikovnou pomůckou pro rozhodnutí jsou pomocná slovesa mít a být. Mějme třídy Zvíře, Pes a Obojek.

• Pes je Zvíře - použiji dědičnost
• Pes má Obojek - použiji kompozici

Toto jednoduché pravidlo se dá použít ve většině případů. Zajímaly by mě výjimky z tohoto pravidla.