Diskusia – Objektovo orientované programovanie a evolúcia vývoja softvéru
SpäťUpozorňujeme, že diskusie pod našimi online kurzami sú nemoderované a primárne slúžia na získavanie spätnej väzby pre budúce vylepšenie kurzov. Pre študentov našich rekvalifikačných kurzov ponúkame možnosť priameho kontaktu s lektormi a študijným referentom pre osobné konzultácie a podporu v rámci ich štúdia. Toto je exkluzívna služba, ktorá zaisťuje kvalitnú a cielenú pomoc v prípade akýchkoľvek otázok alebo projektov.
David Hartinger:1.9.2011 17:06
Ahoj, když díky rýpání vznikne nějaká konstruktivní diskuze, tak ho jen uvítám, tady mi ale přijde, že rýpeš ve většině případů zbytečně. No nic, jdeme na to:
"Moorův zákon" - Byl vysloven v době, kdy bylo na čipech dost "místa",
takže nebyl problém každý rok počet tranzistorů zdvojnásobit. Dnes
výrobci HW pracují na úrovni samotných atomů a proto se vývoj nepatrně
zpomaluje. Stále jsou nové cesty kam jít, tvořit ještě menší tranzistory
nebo jít cestou kvantového počítače. Jestli to někdo teď aktuálně
vypočítal na 18 měsíců a s příchodem menšího tranzistoru to bude 10 a
potom chvíli 20 je přeci úplně jedno. Vůbec nic to na článku nemění. A
jak chceš zvyšovat výkon bez zvýšení frekvence a počtu tranzistorů, to
opravdu nevím 
" A tím se dostáváme do situace, kdy je hodně nových programů i na nejnovějším hardwaru pomalejší než jejich předchůdci na starším." - To je docela trefná připomínka, ano, to se děje. Musíš si však uvědomit, že výroba toho pomalejšího programu zabere např. s využitím technologie .NET setinu času i rozpočtu, než zabraly tamty programy. Programů je potřeba tolik, že se prostě musí dělat levně. Když byl počítač velký jako budova, asi jich moc nebylo a program mohl stát miliony a uměl třeba jen vyřešit rovnici. Určitě si pamatuješ, že třeba na ZX Spectru někdo napsal šachový program do 1KB a podobně. To je jako by k tobě přišel a říkal, že je Pascal špatný, protože ty to máš na 50kb a to je hrůza. Myslíš, že se to vyplatilo, cpát vše do 1kb, ukládat integery jako stringy, abys měl o pár bitů navíc a využívat pro mezivýpočty videopaměť? Asi ne, že jo. Na tom se doufám shodneme. Nehledě na to, že v tom 99% lidí udělá chyby. V tom je ta evoluce. Když má nyní počítač každý v kapse a chce tam desítky komplexních programů, hledá se cesta jak psát programy rychle, kvalitně a levně. Že jsou trochu pomalejší nebo větší (resp. ony jsou rychlé dost, jen mají vysoké požadavky na HW) je prostě daň, která se za to platí.
"Jednoduchá utilitka se dá bez problémů napsat po dvou měsících" - Jo
a v Javě po dvou dnech 
Už
chápeš ten rozdíl?
"dostáváme za ni zhruba totéž, co javisti a céčkaři" - To sice ano, ale kolik programu napíšete? Za jak dlouho bys v ASM napsal třeba DB systém? Dokážeš si představit, že bys psal v ASM třeba Introsort? Jak dlouho by ti to trvalo? A jak náročné by to bylo, když jen sečtení dvou čísel je tam na několik řádků. Porovnej si výsledek práce Javisty a ASM programátora za 1 den. Javista napíše polovinu obchodní logiky malého databázového systému včetně uživatelského rozhraní. Ty tak možná dopíšeš řazení čísel, které umí stejně Java již v základu. Kdo má pěníze platit měsíce práce ASM programátora, když Javista udělá to samé za týden a je to jen jak ty říkáš "pomalejší"?
"S metodami objektů je to ovšem stejné - když chceme, aby některá dělala něco jiného, musíme si napsat novou" - I metody se dají rozšiřovat, ale tady je to spíše míněné k dědění rozhraní.
"Pascal zná kouzelné slovíčko UNIT" - Mezi knihovnou (jednotkou) a
objektem je dost velký rozdíl. Např na obsluhu grafiky máš jednotku, ve
které jsou příslušné funkce. O tom žádná. Ale objekt nemusí umět jen
něco obsluhovat, ale také udržovat data, to v jednotce asi dost dobře
neuděláš, možná pomocí nějakých globáních proměnných a to vede
rovnou do pekla. Malá ukázka by mohl být program pro evidenci zaměstnanců.
Jak si je uložíš? Do nějakého hrozného globálního pole. Hodnoty v něm
budou potom normálně veřejně přístupné. Mějme třeba pohlaví (mám an
mysli proměnnou 
), ta bude
nabývat hodnot MUZ nebo ZENA (bude to string). V programu do toho budou ty
jednotlivé procedury hrabat a přepisovat, jak se jim zlíbí. Pak se
rozhodneš, že uděláš lokalizaci a bude to raději M a F. Musíš to
přepsat na 50ti místech programu. A když pak přijde někdo, kdo o změně
neví, použije MUZ a ZENA a program rozbije. Je potřeba nastavit rozhraní a
viditelnost tak, aby se k tomuto procedury nedostaly. To pole nesmí být
veřejné, měly by tam být nějaké set a get procedury. Také funkce musí
být veřejné a neveřejné, ve starých jazycích se to simulovalo
podtržítkem na začátku názvu funkce. Pokud Pascal v unitech něco takového
má (už si to nepamatuji), pak je to opravdu náznak OOP (jak říkám, OOP je
způsob komunikace mezi částmi programu), ale to pravé OOP myšlenku dovádí
ještě dále.
A přidávání nových metod do objektů je snad jednodušší? - Ano, je. Mohu je dědit a hlavně když se ve verzi programu s číslem 10 rozhodnu, že chci něco modifikovat a zjistím, že k tomu potřebuji přepsat rozhraní tohodle což je závislé na rozhraní támhletoho a nakonec zjistím, že musím přepsat 90% kódu, tak končím (na to prostě nejsou prostředky). Tím vysvětluji i bod níže, protože dospěji do stavu, kdy je potřeba k postupu vpřed změnit strukturu programu a to bez OOP a dědičnosti rozhraní prakticky nelze. Nemohu vědět, co od programu budu požadovat za 5 let leho života, proto návrh nebude nikdy stoprocentní. Když chci v OOP změnit návrh, změním to na jednom místě a všude se to podědí, další metody a objekty nemají přístup ke globálním datům a tudiž se jich změna netýká. Tobě zůstane jen rozbitý program.
"Podle mě není OOP samospasitelné". - A to já snad někde říkám? OOP
myšlenkový směr programování a doporučená praktika. Když budeš jezdit
na bruslích s helmou, tak ti také nezaručí, že se ti nic nestane. Ale
jezdit bez ní je docela hloupé . Jsou tu i jiné cesty, mně osobně se velmi líbí funkcionální
paradigma v Javascriptu, kde se funkce ukládají mdo proměnných a pomocí
nich se tvoří jakési pseudoobjekty, ale to je nad rámec tohoto článku.
Mircosoft:1.9.2011 18:37
Dyť jsem říkal, že si jenom rejpnu, neber mě tak vážně .
Jednoduchá utilitka po dvou měsících - tím myslím po dvou měsících úvodního kurzu, kde na začátku dotyčný nevěděl o cílové architektuře a instrukčním souboru ani zblo. Za jak dlouho se dá naučit Java, včetně Windows a všeho ostatního pod tím? Jasně, i tak asi za míň. To jsem jenom reagoval na těch pět let.
Ovšem chtěl bych vidět někoho, kdo v Javě umí napsat ovladač nebo
jádro OS (já vím, to není fér příklad 
).
Za jak dlouho bych v ASM napsal třeba DB systém? Za dlouho, ale proč, když mi stačí napsat prográmek, který nějaký už hotový systém zavolá? To můžu i bez OOP, záleží jenom na tom, jaké rozhraní ten systém poskytuje.
K těm jednotkám v Pascalu: globální proměnné definované v implementation jsou zvenku jednotky nepřístupné, stejně jako atributy objektu v private; podobně je to s funkcemi. Zvenku vidím jenom interface, takže se v tom neztratím. Akorát dědit a polymorfovat to nejde.
Je otázka, jestli je lepší plýtvat časem jednoho programátora a ušetřit čas spoustám uživatelů, nebo naopak. Z obchodního hlediska samozřejmě to první, protože program levně vyvinu, rychle prodám a ještě tím přihraju zákazníky prodejcům výkonného hardwaru. Běžný uživatel ale možná chce něco, co rychle a spolehlivě funguje a kvůli čemu by nemusel s každou novou verzí kupovat nový stroj. Ale to už je o ekonomice a ne o programování.
Každopádně nejvíc záleží na tom, kolik hotových knihoven pro daný jazyk existuje. Kdybych si měl psát všechno sám od nuly, nevím, jestli by OOP představovalo nějakou podstatnou časovou výhodu.
No nic, shrnu to, co jsem chtěl říct:
Asm je téměř nepoužitelný pro velké projekty, ale nepostradatelný pro utilitky na úrovni hardwaru, takže ho OOP nikdy úplně nenahradí a assembleristi nevymřou, muhehe
OOP je dobré pro rychlou tvorbu složitých programů, což zase nejde v Asm.
Dobře navržený a zdokumentovaný neobjektový program (obecně - ne jenom Asm) se dá udržovat velice dobře, i to zmíněné přepisování na více místech se dá minimalizovat. V opačném případě je to samozřejmě hrůza.
I objektový program se dá zprasit tak, že je nepřehledný a udržuje se špatně. Jenom se to asi nestává tak často
Hm, jak tak koukám, žádná hlubší myšlenka se v tom shrnutí stejně
nevyskytla . Tak nic, už
mlčím.
David Hartinger:1.9.2011 18:53
Podle mně čas uživatelům moc neušetříš, jak jsem říkal, ty programy
běží normálně rychle, jen požadujíé rychlý HW, který však uživatelé
mají (486ky se přece už nějaký pátek neprodávají ).
Nikdo vůbec nic nepozná a ušetří se, navíc ty virtuální stroje co mají Java a C# jsou docela šikovné, když dělají nějaké husté vědecké výpočty, dokáží si třeba natvrdo zkompilovat operace, které provádí často a dostanou se na rychlost nižších jazyků. V Javě nebo C# jsou normálně pěkné 3D hry nebo další renderovací programy a nikdo s tím nemá problém.
Profesor na přednášce nám říkal, že nějaké ještě hustší
vědecké výpočty, které potřebují opravdu vymačkat z HW 100% se píší
normálně v Pythonu, aby v nich neudělali chybu a potom se dají člověkovi,
který dělá X let v Cčku a který je přepíše do C-čka.
Kit:21.10.2012 14:23
Také netuším, co řešíš ve vlákně starém přes půl roku.
C, C++, ani C# neumí komplexní čísla a neumí ani pořádně pracovat s polem. Pro vědeckotechnické výpočty se tedy nehodí.
Pokud potřebuji vědecké programy vyvinout rychle, použiji Octave (resp.
Matlab) nebo Python. Pokud potřebuji výkon, použiji Fortran nebo se ten
Octave naučím pořádně
Java, resp. C# se zase hodí na zpracování textu. Pokud to chci mít rychle hotové, použiji PHP, Perl nebo Python. Je tedy třeba vybrat pro každý účel ten správný nástroj.
David Hartinger:21.10.2012 14:27
V .NETu je hodně věcí: http://msdn.microsoft.com/…complex.aspx
S tou definicí programátorů v ASM náhodou souhlasím
Zatiaľ nikto nevložil komentár - buď prvý!