Vlákno názorů k článku Zaostřeno na PHP (po roce) 2 od Gig - Jestliže v PHP něco velkého chybí, je to...

To samozřejmě záleží na tom, jakou metodou programujete. Já osobně programuji objektově, a největší nárůst produktivity ušetřím ve fázi ladění a odchytávání chyb. Nárůst produktivity je přímo úměrný pečlivosti návrhu struktury objektů.

U objektového návrhu se dá říci, čím větší projekt, tím větší nárůst produktuvity oproti neobjektovému programování. Na mini projektech je skoro jedno, jakou metodou programujete. Pokud si zkusíte projekt na 3 obrazovky zdrojového kódu porovnat z hlediska produktivity, tak je to k ničemu.

To je také důvod, proč se dost často stává, že větší projekty jsou dost často přepisovány z C do C++, apod.. Viz třeba případ Firebirdu (klonu databázového serveru Interbase), apod..

Objektové programování dokáže podstatně omezit zmatky na mnoha úrovních, zaručit, že Vám lidé používající objekt nasáhnou na data, která nemají, apod..

Ještě více ta výhoda objektového přístupu vyplyne v případě, že programátor pracuje na více projektech a chce používat určité části kódu v různých projektech. Tam je pak možnost izolace určitého celku do samostatné jednotky (ať už jí říkáme jakkoli - objekt, třída, komponenta) dost výrazným přínosem. Lze to samozřejmě řešit i v neobjektových jazycích, ale vyžaduje to udržování disciplíny, u objektového přístupu je to přirozený postup.

Objektové programování není všelék ani jediná správná víra. Je to jen nástroj, který se pro některé účely hodí více, pro některé méně. Proto mám raději jazyky jako C++, které umožňují programovat objektově, ale neházejí mi klacky pod nohy v okamžiku, kdy se to z jakýchkoli důvodů nehodí. Pokud je jazyk koncipován tak, aby neobjektový přístup a priori potíral, při jeho praktickém použití se nakonec vždy dostanete do situace, kdy řešíte problém mnohonásobně složitěji a obtížněji než je potřeba jenom proto, aby byl váš přístup čistě objektový. Vzpomínám si na přednášku o vývoji NTS, kde jeden z vývojářů popisoval, jaké strašné ukrutnosti musejí vymýšlet proto, že na počátku místo C++ zvolili Javu.

Je to podobné, jako když kdysi dávno jakási skupina teoretiků (v čele s jistým panem Pecinovským) dštila oheň a síru na příkaz goto. Přitom rozumně použitý příkaz goto (často maskovaný za přezdívky typu return, exit, break nebo continue) může program naopak zpřehlednit. Jak pravil poručík Hamáček: "Protože, Kefalín, každej fundamentalismus je co? Každej fundamentalismus je na h___o."

jeste tomu porad nerozumim:

[...] Narust produktivity je primo umerny peclivosti navrhu struktury objektu. [...]
To je ale v jedne a te same metode. Nas ale zajima to srovnani tech dvou metod programovani a ne, ze kdyz v objektovem udelam blbe objekty tak je to horsi nez kdyz jsou ty objekty spravne.

[...] cim vetsi projekt, tim vetsi narust produktuvity oproti neobjektovemu programovani [...]

uz jste delal 2 podobne projekty -jeden funkce, druhy objekty a mohl jste zjistit tu zavislost. Nebo jak jste na tu zavislost prisel? V jakem pomeru jsou ty produktivity u stredne velkeho projektu?

[...]dokaze podstatne omezit zmatky na mnoha urovnich, [...]

ja citim, ze to myslite opravdove a proto tu vetu nechci tvrde kritizovat (to umi kazdy). Ale popravde, takova veta nas nepohne dal.

to: pan Kubecek
[...] pouziti trid pres hranice projektu prinese znacne uspory [...]

jak znacne ve srovnani s pouzitim stejnych funkci pri klasickem proceduralnim programovani. prinasi pouziti trid oproti funkcim narust produktivity 5x, 2x, 1.2x, nebo take eventuelne 0.5x ?

Suma sumarum:
Pres vsechny ty vseobecne vety bych rad vedel, zda muze nekdo rici:

mam 2 tymy po 5 lidech. jeden tym programuje proceduralne, druhy objektove? proceduralni tym je hotov za 6 mesicu.
jak dlouho potrva prace objektovemu tymu?

Zkusim odpovedet:

1) "To je ale v jedne a te same metode. Nas ale zajima to srovnani tech dvou metod programovani a ne, ze kdyz v objektovem udelam blbe objekty tak je to horsi nez kdyz jsou ty objekty spravne"

Presne srovnani jsem nikdy nedelal, a staci mi ma osobni zkusenost. Osobne uz me ani nenapadne delat neobjektove, protoze objektove je to mnohem lepsi. Takze statistikou s procenty opravdu neposlouzim, ale neco preci, viz bod 2.

2) "uz jste delal 2 podobne projekty -jeden funkce, druhy objekty a mohl jste zjistit tu zavislost. Nebo jak jste na tu zavislost prisel? V jakem pomeru jsou ty produktivity u stredne velkeho projektu?"

Neni duvod delat vetsi projekt dvakrat. Ale kolem Vas jsou projekty, ktere se prepisovaly z neobjektoveho do objektoveho. Viz Firebird, viz dalsi. Jen se rozhlednete. Rozdil take je, do jake objektovosti je prepisete. Treba pan Cada popisuje projekt, kdy si rekl 80 000 za program, ktery napsal v objektovem prostredi Cocoa na Macu. Uprimne uvedl, ze castka je prilis vysoka za to malo, co udelal. JIny jeho kolega pracujici neobjektove dal za stejnou praci nabidku 250 000 za stejny program. Pan Cada k tomu dodava, ze ta cena byla opravnena z hlediska toho, co ten programator musel psat.

Nutno rici, ze slo o vyuzivani objektu na vysoke urovni.

4) "jak znacne ve srovnani s pouzitim stejnych funkci pri klasickem proceduralnim programovani. prinasi pouziti trid oproti funkcim narust produktivity 5x, 2x, 1.2x, nebo take eventuelne 0.5x ?"

To zalezi na tom, co delate. Treba slusny narust produktivity je u objektu, pokud delate graficke rozhrani, coz dnes predstavuje 90% prace na projektech. Ale urcite urychleni u objektu je prakticky vzdy oproti cistemu proceduralnimu programovani.

5) "mam 2 tymy po 5 lidech. jeden tym programuje proceduralne, druhy objektove? proceduralni tym je hotov za 6 mesicu. jak dlouho potrva prace objektovemu tymu?"

To ale preci zavisi na tom, co dela, na jake technologii dela, apod.. Ale obecne pro tymy jsou objekty pozehnanim.

Na druhe strane je potreba rici, ze proste objekty zkuste a uvidite. Nelze z objektu delat boha, ale urcite je oop obrovska pomoc. Navic jde o omezeni kolizi jmen, o zabraneni chyb vlivem toho, ze jiny clen tymu sahl nekam do dat, kam nemel, apod.. Diky jasnemu rozhrani neni potreba tolik dokumentovat, a tolik veci dohadovat s kolegy. Atd..

Je na vás vidět, že jste otevřen debatě, ale současně že si teprve formujete názor na OOP. Výhody OOP jsou totiž nesporné.

Nuže, OOP má několik kvalitativních rysů, kterým se odlišuje od strukturovaného programování - jedním z nich je dědičnost. Co to v praxi znamená ?

Jedna skupina vašeho týmu vyvíjí reusable knihovny, které se pro jednotlivé projekty vašich zákazníků customizují - přičemž sdílená funkcionalita zůstává společná! Při strukturovaném programování sice taky vyvíjíte sdílelné knihovny - ale pokud chcete jejich funkcionalitu rozšířit a stávající zachovat - musíte do jejich funkcí a procedur přidávat volitelné parametry, nebo upravovat jejich zdrojáky - čímž přestanou být přenositelné a navzájem kompatibilní.

V OOP jsou knihovny objekty, třídy které jednoduše podědíte a nabalite si na ně vlastní funkcionalitu, aniž musíte jakkoliv zasáhnout do jejich kódu. ale v případě, že ho rozšíříte jsou změny k dipozici automaticky všem čelnům vašeho týmu - aniž však musí jakkoliv regresně upravovat spoje zdrojové kódy. Je jen na nich, zda upgrade využijí či ne. To není kvantitatiní rozdíl oproti strukturovanému programování - ale nová kvalita, přidaná fíčura, rozšířená funkcionalita oproti programování sebevíc strukturovanému.

Nebo vezměte si třeba takovou OOP inheritanci. Rozhraním definujete strukturu třídy, jak se má vypadat a chovat v budoucnosti. Nikdo z vašich vývojářů nemůže tento funkční předpis obejít, protože je zakompilován do sdílené, popř. elektronicky podepsané třídy - je tím definován do značné míry i styl a formalismus další vývojářské práce. Pro SW arcitekta představuje OOP rozhraní něco jako prefabrikát ve stavebnictví.

OOP, jak je vidět vykazuje zřetelný přínos ve vztahu k řízení SW projektů. Není to jen nějaký nový způsb psaní kódu, který někomu může vyhovovat a nemusí a celkový přínos zůstává víceméně stejný. S OOP doopravdy můžete dělat věci, které nejsou ve strukturovaném programu možné - tím neříkám, že by zásady strukturovaného programování neměly být využívány i napříč OOP. Ale zásady strukturovaného programování jsou podmnožina, subkategorie OOP paradigmatu.

Co se diskuse k PHP týče, ten jazyk příliš neznám, nezajímá mě a necítím se tedy kompetetní se k němu vyjadřovat. Podle mě se další rozšiřování jazyka dá posuzovat jedině ve vztahu či k otázce, zda je na ně jazyk koncepčně a sémanticky připraven, nebo ne. Např. ti. co programují v C++ vědí, že koncepce OOP na C byla naroubována dosti uměle - a to jak s ohledem na přehlednost a strukturovanost syntaxe, tak s ohledem na výsledný výkon, který značně degraduje možnosti původního C. Java nebo SmallTalk těmito neduhy netrpí, protože tyto jazyky byly od svého počátku koncipovány jak objektové, stejně jako JScript či Ruby byly od svého začátku koncipovány jako dynamické. A to je tedy nutné zvážit i při posouzení reálných výhod dalších rozšíření PHP směrem k OOP a vyšší dynamičnosti jazyka. Nejčistším jazykem z hlediska koncepce je podle mě dnes z dynamických jazyků Ruby, ze statických C# Microsoftu.

Posuzovat produktivitu podle toho, jestli jeden tým programuje objektově a druhý ne mi nepřijde příliš moudré. Jde totiž o to, že aby objektové programování mělo nějaký smysl, musí daný programátor skutečně objektově přemýšlet. Pokud totiž dojde pouze k bezúčelnému zabalení funkcí (metod) do nějakého objektu (např. třídy), tak to opravdu k ničemu nepovede a produktivita nestoupne.

Je skoda, pane Kubiku, ze zbytecne nechavate odpovidat lidi na otazku, ktera vas v podstate nezajima, a jen doufate, ze lidi trochu popichnete. Nic, ja sam za sebe muzu jen rici, ze jsem diky Vam zase o neco mene ochotnejsi odpovidat zacatecnikum na jejich dotazy. Asi nejsem sam, kdo nerad dela zbytecnou praci. Prave jste mi ukazal, co znamena poslat mou dobre minenou aktivitu a cas venovany v dobre vire Vam do WC. Nic, dekuji na zivotni zkusenost, zacinam naprosto chapat, proc zkuseni linuxaci pisou ostatnim RTFM. Pokud zazili par takovych lidi, jako jste Vy, vubec se tomu nedivim. Takze jeste jedno ironicke diky Vam, a moje odpovedi tem, kdo me budou zadat o radu zacatecniku budou pro blizkou budoucnost "jdi se vycpat"

To jste nepochopil.
Účelem takové popichující otázky je přimět tázaného k zamyšlení. Jistý Sokrates to kdysi praktikoval s takovým úspěchem, že ho museli nakonec ubolehlavovat, aby Athéňané nebyli moc chytří...
Zamyslet se nad souvislostmi je někdy docela příjemné, tak se nezlobte.

Zamyslim se nad OOP zhruba desatym rokem. Jasne pisu, ze OOP neni Buh, ale ze tomuto pristupu davam prednost. Vim, ze jsou i slabe stranky tohoto pristupu.

Proste jsem chtel poradit v dobre vire, a namisto toho se objevilo, ze proste nekdo chtel udelat z druhych mladiky, kteri zrovna zacinaji programovat.

Me to proste tak otravilo, ze opravdu omezim sve odpovedi tem, kdo zadaji o radu a budu jim radit az prokazi, ze se ctenim nejakeho manualu dostatecne proskvarili. To jen proto, abych priste nevenoval cas nekomu, kdo by chtel jen dokazat, ze je king a ostatni jsou blbci.

Berte to, p. Ponkráci, z té lepší stránky, utřídil jste si myšlenky...

Pokud jde o motivaci p. Kubíka... no, to je hlavně jeho problém, že zná odpověď předem. A ještě ke všemu na schválně hloupě položenou otázku. Odpovědí, rozumných, dostal dost. Moudrost vypadá jinak.

vazeny kolego,

Vase reakce me trochu prekvapila. Postavil jste se do svetla dobrocince, ktery nezjistne pomahal do dneska komunite, az tomu ten zly pan Kubik udelal konec. A hned se k tomu pridaji jinu a hovori, ze moudrost vypada jinak.

Ale ono jde porad o to OOP. Rady, ktere zde zaznely a to nejen od Vas se daji shrnout nasledovne:
- OOP je dobre, ale ma take stine stranky
- rada veci se v OOP da delat lepe
- kdyz se stim clovek zabyva, tak zjisti, ze se to muze hodit
- je treba OO myslet
- nekdo predelava projekty na OOP, pro jine to muze byt horor
- OOP je treba pouzivat tam, kde se to hodi

To jsou vsechno smysluplne vety. Ja znam ale i dalsi:
- mic je kulaty
- kazdy zapas trva 90 minut
- kazda hul ma dva konce
- "uvidime" (Franz Beckenbauer)

Vim, ze to rade lidi prijde arogantni. Ale ja Vam za sebe slibuji, ze az zase bude nejaka takova diskuze, tak se opet budu snazit dozvedet se neco konkretniho. Zaverem snad jen to, ze v takove diskuzi neni mozno polozit kazde slovo na zlatnicke vahy. Takze na videnou v nejake jine diskuzi :-)

Vazeny pane, proste jste me nastval, je to tak tezke pochopit? Pokud kazdy rok pokladate otazky komunite, a ona je neschopna polozit k noham velikana, jako jste Vy, smysluplnou odpoved, tak proste budete kazdy rok prudit namisto toho, abyste si sam zjistil odpoved vlastnimi zkusenostmi, nebo jinym zpusobem.

Pokud proste budete jen prudit, a nezkusite si to, treba Vam nikdo neni schopen predat, co OOP ve skutecnosti je. Asi tak, jako tezko predate zazitek sexualniho orgasmu nekomu, kdo sex zkouma pouze teoreticky dotazy v komunite a sam nehodla byt nicim jinym nez panicem/pannou. Proste se muzete rok co rok ptat, co je to sex, ale neco jineho je tlachat o sexu, a uplne neco jineho je zucastnit se sexu.

Mohu Vam zarucit, ze se proste muzete ptat rok co rok, co je to OOP. A stejne nikdy nedostanete odpoved. Proste si OOP zkuste, a pokud v nem budete nejaky ten rok delat, nebudete uz mit potrebu se ptat.

Ahoj, jsem student, ktery by se v budoucnu rad venoval programovani a tato diskuze je pro me docela prinosem, takova mozaika nazoru :-) Co me ale zaujalo je tento "souboj": OOP (pan Ponkrac) vs. PROC/STRUKT prg. (pan Kubik). Ja jsem zacal v Pascalu a pak jsem sel rovnou do C++, ve skole pak C (krok zpatky) a Smalltalk, i to PHP. Pokud bych se mel tedy vyjadrit ja (vicemene nezkuseny, protoze nic dokonale neovladam), co mi pripada lepsi, tak bych napsal: OOP wins! (a mozna Flawless victory :-) ikdyz to zas asi ne no). Objektovy pristup mi pripada blizsi lidskemu mysleni a me osobne opravdu vyhovuje vice. Pomoci OOP lze problemy vyresit elegantneji nez pomoci proc. pristupu, i kdyz i pomoci nej se do "cile" dobehne, prip. dojde :-) Ve skole me ing. Vojtech Merunka (velky fanda OOP a Smalltalku, autor nekolika publikaci na toto tema) ucil ze OOP je snad zatim jediny lek (i kdyz asi ne vselek) na tzv. semantickou mezeru a sva tvrzeni mimojine i dokazoval ruznymi grafy a srovnanimi, ktere si rozhodne nevycucal z prstu, ale pochazeji z verohodnych zdroju (treba OMG). Pamatuju si treba srovnani prog. jazyku z hlediska poctu napsanych radku kodu - cim vice objektovy jazyk tim lepsi vysledky, vitez byl tusim "cisty" Smalltalk ;-) Dalsi graf byl o tom ze 66% ceny softwaru tvori jeho udrzba, a ta je snadnejsi v pripade pouziti OOP. Nekde jsem cetl, ze s prichodem C++ byly prepisovany OS typu unix z C prave do C++ a tusim ze i Windows jsou tvoreny pomoci OOP, takze to asi byla pravda. Samozrejme cim mensi projekt, tim vice se rozdily smazavaji. Myslim ze chtit odpoved na otazku: Jak presne (kvantitativne vyjadreno) stoupne produktivita pri prechodu z proc. pristupu na objektovy je trochu .. no ujety :-) Proste praxe ukaze (a leckde to uz ukazala). V pripade pana Kubika by to mozna tak nevyznelo, ale jak se rika vyjimky se najdou vsude a staryho psa novym kouskum nenaucis (treba proto ze uz je prece jen starsi a nechce se uz nic noveho ucit). Jinak samozrejme bez urazky. Kazdy ma pravo na svuj nazor a toto je muj.

Samozřejmě jsem to tušil, či spíše očekával.

Ano, máte pravdu, i v C++ se dá psát prasecky a nečitelně, jen je snazší psát čitelně. I v Javě se to dá obejít přesně tak, jak popisujete - jedna třída (to je jen drobná syntaktická komplikace), z lokálních proměnných jsou rázem globální, z metod funkce, jen ty pointry by mi chyběly.
Nakonec, Pascal taky nikoho nepřinutil psát strukturovaně. Jen při tom neházel klacky pod nohy jako FORTRAN. Ale i v F IV (tuším) se už dalo psát čitelně. A nebo vyprodukovat talíř špaget, kterému po týdnu nerozuměl ani autor.

Třeba správu paměti, událostí, je toho víc. Nic co by se nedalo napsat neobjektově, jen to dá míň práce. Ergo, produktivita práce roste.

Obhajujete rozumné použití goto. Pochopitelně, proč ne. Rozumné použití téměř čehokoli nelze zavrhnout. Nedávno jsem goto taky z nezbytí použil. Ale předělával jsem mnoho programů (už dávno), kdy mi připadalo, že by GOTO/goto mělo být jen na zbrojní pas.
A kdysi měl oponovat diplomku, kde dotyčná napsala mnohasetřádkový fotranský program bez jediné funkce, zato s mnoha, velmi mnoha GOTO. Doporučil jsem jí tenkrát, aby si našla jiného oponenta, že se jí bude lépe obhajovat.
Ty převleky typu break, continue, return takové vepřovosti neumožňují a jsou užitečné. V Pascalu mi chyběly.