Fórum Root.cz
Práce => Studium a uplatnění => Téma založeno: Jirka 12. 12. 2014, 21:14:14
-
Zdravím,
chodím na jednu SŠ se zaměřením na Informační technologie - Počítačové sítě a programování. Vzhledem k nabídkám práce a poptávce po programotárech. Jak moc důležitá je znalost webového programování v dnešní době a zároveň také pro budoucnost? Učitel do nás rve za každou cenu PHP, ale já v tom moc perspektivu nevidím. Jaký je na to Váš názor? Já spíše preferuji jazyky jako je C/C++ a Java. Jsem ve fázi takové, že hledám něco, čeho bych se měl opravdu chytnout, abych se uplatnil. Dnes to s prací není jednoduché a můj názor je, že dnes dělá weby téměř každý. Opravdu bych rád znal názor veřejnosti.
Díky. :)
-
Velmi zjednoduseny pohled: Kdyz budes umet C/C++ a Javu, tak to PHP podle me zvladnes s prstem v noce.
-
Ty jazyky jsou do značné míry podobné, v PHP se z nich asi nejlépe dělá OOP. Proto tuto volbu chápu. Když se naučíš PHP, hravě zvládneš i ty zbývající.
-
K "hmmm" doplním: akorát ti pak bude pít krev třeba i taková drobnost, jako pojmenovávání funkcí v PHP. CamelCase a podtržítkové_názvy vedle sebe bez jakékoliv logiky... :D
PHP neučí žádným pořádným návykům, ale spíš jen lepit špagety dohromady. A rozhodně není dobrý ani na učení OOP, to do něj bylo znásilněné až časem.
-
K "hmmm" doplním: akorát ti pak bude pít krev třeba i taková drobnost, jako pojmenovávání funkcí v PHP. CamelCase a podtržítkové_názvy vedle sebe bez jakékoliv logiky... :D
PHP neučí žádným pořádným návykům, ale spíš jen lepit špagety dohromady. A rozhodně není dobrý ani na učení OOP, to do něj bylo znásilněné až časem.
Souhlasím s tímto názorem. PHP moc nemusím, přijde mi to jako patlání všeho možného do sebe a to je přesně to co mě nebaví. Jenže je to těžké. Učitel tento jazyk silně preferuje, sice neodsuzuje jiné jazyky, ale já v tom nevidím perspektivu pro budoucnost, zatímco on třeba ano. Myslím si, že se spíše vyplatí věnovat ten čas C/C++, Javě nebo něčemu dále podobnému.
-
K "hmmm" doplním: akorát ti pak bude pít krev třeba i taková drobnost, jako pojmenovávání funkcí v PHP. CamelCase a podtržítkové_názvy vedle sebe bez jakékoliv logiky... :D
To se už dnes dá slušně zabalit do objektů tak, aby to nevadilo. Pokrok však nastane, až tyto funkce budou nahrazeny metodami. Na to si ale ještě asi počkáme.
PHP neučí žádným pořádným návykům, ale spíš jen lepit špagety dohromady. A rozhodně není dobrý ani na učení OOP, to do něj bylo znásilněné až časem.
Dobré návyky se nedají naučit v žádném ze jmenovaných jazyků jen tak bez správného vedení. Všechny svádí k nepravostem a naopak kvalitní OOP se dá dělat v každém z nich. Jen v C/C++ to jde trochu hůř.
-
Nedej bože naučit se něco navíc, že? PHP se dá zvládnout za dva týdny perfektně, tak tady nebreč, nauč se ho, uděláš službu učiteli i sobě, těžko ti to uškodí...
K "hmmm" doplním: akorát ti pak bude pít krev třeba i taková drobnost, jako pojmenovávání funkcí v PHP. CamelCase a podtržítkové_názvy vedle sebe bez jakékoliv logiky... :D
PHP neučí žádným pořádným návykům, ale spíš jen lepit špagety dohromady. A rozhodně není dobrý ani na učení OOP, to do něj bylo znásilněné až časem.
Souhlasím s tímto názorem. PHP moc nemusím, přijde mi to jako patlání všeho možného do sebe a to je přesně to co mě nebaví. Jenže je to těžké. Učitel tento jazyk silně preferuje, sice neodsuzuje jiné jazyky, ale já v tom nevidím perspektivu pro budoucnost, zatímco on třeba ano. Myslím si, že se spíše vyplatí věnovat ten čas C/C++, Javě nebo něčemu dále podobnému.
-
Ty jazyky jsou do značné míry podobné, v PHP se z nich asi nejlépe dělá OOP. Proto tuto volbu chápu. Když se naučíš PHP, hravě zvládneš i ty zbývající.
no nevim, jak ti php pomuze treba k pochopeni stl v c++...
-
php ma urcite budoucnost dokud facebook bude investovat do interpretu php kodu. nez dokoncis skolu a udelas si jeste jeden papir na hlavu, tak se stejne vsechno zmeni tolikrat, ze je uplne jedno co se budes ucit ted.
-
php je správný směr, stejně jako C++ a Java. navíc je triviální na pochopení, jeho naučením nelze nic zkazit.
na co bych si dal pozor, je lepení kódu (ono lze lepit i v C++ a Javě, ale PHP je k tomu mnohem náchylnější je příliš volné)
takový BASH se třeba vůbec nehodí na programy a přesto se v něm píšou a nemusí být tak zlé a určitě je dobré ho umět.
-
situaci na trhu neznam, spis jen zaujate odhaduju. v zahranici uplatneni prumerne az podprumerne a ve vyjimkach jako facebook spickove. na domacim pracovnim trhu asi spis typu kazdy te bude chtit zamestnat, ale nebude te chtit a mit z ceho zaplatit. pro zalozeni vlastniho byznisu je to spis lepsi ve smyslu jistejsi varianta, ale plati mene rizika je mene muziky. jinak vlastni byznis nebude psat od nuly, ale spis jen upravovat neco co uz existuje nebo jeste hur jen preprodavat hotova reseni. nekde v minulosti na foru je vlakkno kde je odkaz na celkem slusny eshop s sablonami, skiny a kupou dalsich veci.
-
můj názor je, že dnes dělá weby téměř každý. Opravdu bych rád znal názor veřejnosti.
Spatne weby dela kazdy. Dobreho webare je problem sehnat.
-
no nevim, jak ti php pomuze treba k pochopeni stl v c++...
Jazyk C++ se pro začátečníka vůbec nehodí. Kdyby začal s C++, zase by nepochopil OOP. Tak si vyber.
-
můj názor je, že dnes dělá weby téměř každý. Opravdu bych rád znal názor veřejnosti.
Spatne weby dela kazdy. Dobreho webare je problem sehnat.
V PHP píši nejen weby, ale i běžné aplikace pro zpracování dat. Mnoho lidí si myslí, že PHP je jen na weby.
-
Zdravím,
chodím na jednu SŠ se zaměřením na Informační technologie - Počítačové sítě a programování. Vzhledem k nabídkám práce a poptávce po programotárech. Jak moc důležitá je znalost webového programování v dnešní době a zároveň také pro budoucnost? Učitel do nás rve za každou cenu PHP, ale já v tom moc perspektivu nevidím. Jaký je na to Váš názor? Já spíše preferuji jazyky jako je C/C++ a Java. Jsem ve fázi takové, že hledám něco, čeho bych se měl opravdu chytnout, abych se uplatnil. Dnes to s prací není jednoduché a můj názor je, že dnes dělá weby téměř každý. Opravdu bych rád znal názor veřejnosti.
Díky. :)
Posledni dobou se PHP zase vraci do mody, i samotny jazyk se znacne zlepsuje a cim dal vice se v nem da psat pekne objektove. Urcite ti nauceni PHP nijak neublizi ba naopak. Pokud te bavi C++ a Java, tak se jim klidne dal venuj ve volnem case, klidne se podivej i na dalsi jazyky (Go, Rust, D). Osobne si myslim ze jazyk je jen nastroj a je vhodne umet ovladat pokud mozno vice nastroju, pak ma clovek i vetsi sanci se uplatnit.
Ja osobne jsem se ve tvem veku take zameroval na C++ a Javu, a dneska programuji prevazne v PHP. Ale to mi nebrani dal rozvijet sve znalosti v jinych jazycich.
-
můj názor je, že dnes dělá weby téměř každý. Opravdu bych rád znal názor veřejnosti.
Spatne weby dela kazdy. Dobreho webare je problem sehnat.
dobreho webare nie je az taky problem zohnat ako zaplatit...
"to on chce fakt tolko penazi??? to mu nedame, ved Fero zo susednej dediny nam to spravi za 400€ a php predsa vie kazdy, tak to nemoze byt nic narocne"
spatni webari dost deformuju ceny
-
Ve skutečnosti o ten jazyk vůbec nejde, protože jak jsi "programátor", tak pochopíš, že jazyk je to nejmenší (pokud se tedy nebude vysloveně jednat o přechod např. z nějakého imperativního c-style jazyka na funkcionální typu scala apod.) Jde o to znát různé algoritmy apod.. Taky jsem před pár lety ve středoškolských letech pořád řešil, který konkrétní jazyk je nejlepší, který si vyberu a budu v něm programovat i po smrti a podobně. Nemá to cenu, něco si vyber a jdi v tom něco realizovat, to ti dá nejvíc zkušeností.
-
To, jak je to didaktické, je jedna věc. Ale co se uplatnění týče, mimo Prahu a Brno vidím nabídek práce, které nejsou IS v .NET nebo weby v PHP, naprosté minimum. Možná se blbě dívám…?
-
Kdyz se budes drzet jazyku z top ten v indexu popularity na http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
tak uplatneni rozhodne najdes.
PHP tam je aktualne na sestem miste.
Podporuji, jiz zde nekolikrat opakovany nazor, ze jazyk je pouze nastroj, rozhodujici je co chces vytvorit a podle toho zvolis ten nejvhodnejsi.
Ja sam jsem leta programoval v php, c, jave a nakonec jsem skoncil u pythonu, ktery osobne povazuji za jeden z nejkomplexnejsich jazyku.
-
PHP podle mě není ideální na začátek. Jednak to není plnohodnotný programovací jazyk a jednak ti dovolí psát prasácky. Začal bych s Javou. V javě můžeš dělat weby i normální aplikace, navíc je používána i na Androidu (myslím že dnes, kdy každý má v kapse chytrý mobil je to perspektivnější než ty webové aplikace). Navíc Java není tak těžká jako C++ a jak ji zvládneš, budeš mít solidní základ pro další jazyky.
-
PHP ... Jednak to není plnohodnotný programovací jazyk ...
Jak jsi na to přišel? Nějakým vlastním výzkumem?
-
PHP podle mě není ideální na začátek. Jednak to není plnohodnotný programovací jazyk a jednak ti dovolí psát prasácky. Začal bych s Javou. V javě můžeš dělat weby i normální aplikace, navíc je používána i na Androidu (myslím že dnes, kdy každý má v kapse chytrý mobil je to perspektivnější než ty webové aplikace). Navíc Java není tak těžká jako C++ a jak ji zvládneš, budeš mít solidní základ pro další jazyky.
Dovolil bych si nesouhlasit :)
PHP je plnohodnotny programovaci jazyk, lze v nem delat stejne typy aplikaci jako v Jave, neco jde hur neco lepe a jako u kazdeho jineho jazyka.
Na web bych ho rozhodne uprednostnil pred javou nejen kvuli nizsim narokum na beh prostredi, ale kvuli rychlosti vyvoje a deploymentu aplikaci
Mobilni aplikace se dnes take daji psat ve vetsine oblibenych jazyku vcetne php :)
Myslim si, ze kazdy programator by mel vyzkouset co nejvice jazyku aby nasbiral zkusenosti a hlavne zjistil co jemu samotnemu nejlepe vyhovuje pro psani ruznych typu aplikaci.
-
Nie, nie je.
PS. Weby kvalitne robi malokto.. O UX ani nehovorim.
-
PHP ... Jednak to není plnohodnotný programovací jazyk ...
Jak jsi na to přišel? Nějakým vlastním výzkumem?
Nechci rozpoutávat flame, jenom říkám svůj názor. Dlouho sem PHP nepoužíval (naposled rannou verzi 5), mohlo se něco změnit, ale pro mě to je prostě skriptovací jazyk pro tvorbu webu a rozhodně míň univerzální než Java. Pokud bude umět javu, php bude hračka (a navíc uvidí proč PHP dovolí psat tak prasácky), naopak to bude těžší.
PHP podle mě není ideální na začátek. Jednak to není plnohodnotný programovací jazyk a jednak ti dovolí psát prasácky. Začal bych s Javou. V javě můžeš dělat weby i normální aplikace, navíc je používána i na Androidu (myslím že dnes, kdy každý má v kapse chytrý mobil je to perspektivnější než ty webové aplikace). Navíc Java není tak těžká jako C++ a jak ji zvládneš, budeš mít solidní základ pro další jazyky.
Dovolil bych si nesouhlasit :)
PHP je plnohodnotny programovaci jazyk, lze v nem delat stejne typy aplikaci jako v Jave, neco jde hur neco lepe a jako u kazdeho jineho jazyka.
Na web bych ho rozhodne uprednostnil pred javou nejen kvuli nizsim narokum na beh prostredi, ale kvuli rychlosti vyvoje a deploymentu aplikaci
Mobilni aplikace se dnes take daji psat ve vetsine oblibenych jazyku vcetne php :)
Myslim si, ze kazdy programator by mel vyzkouset co nejvice jazyku aby nasbiral zkusenosti a hlavne zjistil co jemu samotnemu nejlepe vyhovuje pro psani ruznych typu aplikaci.
Jistě, to se může rovnou naučit Céčko psát všechno v něm, jenom to půjde o něco hůř.
-
PHP se pouziva dneska primarne jen kvuli tomu ze lidi kteri jsou schopni v nem neco slepit je vsude plno a jsou hlavne velmi levni. Ze setrvacnosti i kvuli webhostingum (dneska je uz situace uplne jinde, VPS si muze dovolit vetsina lidi, kteri chteji nejaky slozitejsi eshop nebo webovou aplikaci). Pokud to myslite s webovyma aplikacema vazne zameril bych se na Spring/Play/JSP/... v Jave a k tomu se venoval i jinym jazykum a frameworkum (Node.js, RoR, Django,...).
-
dobreho webare nie je az taky problem zohnat ako zaplatit...
To je totez. Drazi jsou proto, ze jich je malo.
-
Dlouho sem PHP nepoužíval (naposled rannou verzi 5), mohlo se něco změnit, ale pro mě to je prostě skriptovací jazyk pro tvorbu webu a rozhodně míň univerzální než Java. Pokud bude umět javu, php bude hračka (a navíc uvidí proč PHP dovolí psat tak prasácky), naopak to bude těžší.
Změnilo se hodně, z PHP se mezitím stal plnohodnotný multiparadigmatický jazyk, vhodný zejména ke generování čehokoliv. Návrhové vzory se v něm aplikují mnohem snáze, než např. v Javě, protože se nemusí obcházet hromada klacků, které Java hází vývojářům pod nohy za účelem "čistoty" kódu. Prasit se však dá i v Javě. PHP je mnohem lépe vybaveno na zpracování textů. Vždyť v Javě nejsou ani tolik potřebné funkce map(), filter() a reduce() a programátor jejich potřebu musí obcházet přes cykly nebo rekurzi.
PHP podle mě není ideální na začátek. Jednak to není plnohodnotný programovací jazyk a jednak ti dovolí psát prasácky.
Prasácky se dá psát i v Javě a také se v ní běžně i prasácky programuje. Jazyk ti v tom prostě nezabrání.
Jistě, to se může rovnou naučit Céčko psát všechno v něm, jenom to půjde o něco hůř.
Céčko bych začátečníkovi nedoporučil. Raději Python.
-
Ne kazdy potrebuje super-mega-hyper ultra cool server appky s navtevnosti bambilion unikatnich denne. PHP je pro potreby drtive vetsiny webu proste dost dobre. Ukaz mi v jave apod framework na kterym za vikend udelam kompetni webovku, kam za pul hodiny doinstaluju kompletni plnohodnotny newsletter, komplexni spravu pristupovych prav apod. Kam pridam prakticky cokoliv na par klinuti a to co nahodou neni tak si muzu sam napsat (mluvim o Drupalu). Mam tam na par kliknuti podporu cachovani do memcached, podporu pro cachovani nebo i data storage do MongoDB.
Pro vetsinu pripadu tam udelam pro zakaznika komplet web za vikend. Zaroven nemam zadne limity kdyz potrebuju neco vetsiho (rekneme miliony pageloads mesicne). Jasne pro banky to neni, ale kdo z nas se jak casto s timhle typem byznysu potka...
BTW hodnotit neco podle verze stare 10 let je troufalost (tj ranna verze 5 - vydani 2004)
-
Hlavně si uvědom, že jako absolvent střední rozhodně nebudeš žádná hvězda a tak jako tak toho budeš muset hodně nastudovat.
PHP sice nepodporuje dobré programátorské návyky, ale zase jsou s ním výsledky vidět rychle - možná proto ho učitel používá.
-
komplet web za vikend
Tak to musí být nějaké opravdu propracované, originální a nešablonovité stránky, když to trvá celé dva dny...
-
PHP ... Jednak to není plnohodnotný programovací jazyk ...
Jak jsi na to přišel? Nějakým vlastním výzkumem?
Kazdemu sa paci nieco ine. To ako keby ste sa hadali o zenskej krase: jednemu sa pacia vysoke, stihle, dlhonohe barbiny a druhemu staci mala, tlsta a skulava zena s krivymi zubami.
-
PHP ... Jednak to není plnohodnotný programovací jazyk ...
Jak jsi na to přišel? Nějakým vlastním výzkumem?
Kazdemu sa paci nieco ine. To ako keby ste sa hadali o zenskej krase: jednemu sa pacia vysoke, stihle, dlhonohe barbiny a druhemu staci mala, tlsta a skulava zena s krivymi zubami.
V tom případě mohl napsat: "Mně se PHP nelíbí, nevyhovuje mi proto a proto" a bylo by po problémech. Místo toho napsal tvrzení, které ničím nepodložil.
-
komplet web za vikend
Tak to musí být nějaké opravdu propracované, originální a nešablonovité stránky, když to trvá celé dva dny...
Jasne, bral jsem to bez a analyzy a grafickyho navrhu, ciste jen realizace webu.
Za den naklikana struktura(typy obsahu, views apod), dalsi den responsible sablona z PSD. Naprosto originalni bezne webovky. Dalsi den pro naklikani jednoducheho e-shopu. A hlavne mam tam zaklad na kterym dokazu v dalsim rozvoji cokoliv. Zadny estranky.cz apod.
Proste jen nevymyslim kolo a znovupouzivam jiz napsany kod.
Tohle samozrejme mluvim o takovym beznym webu v cene 15-20 tisic. Ale je super tam mit stejny podvozek jako na projektech za statisice - miliony.
-
PHP ... Jednak to není plnohodnotný programovací jazyk ...
Jak jsi na to přišel? Nějakým vlastním výzkumem?
Kazdemu sa paci nieco ine. To ako keby ste sa hadali o zenskej krase: jednemu sa pacia vysoke, stihle, dlhonohe barbiny a druhemu staci mala, tlsta a skulava zena s krivymi zubami.
No, je rozdil jestli se nekomu libi blondyna nebo tvrdit, ze zrzka neni plnohodnotna zenska...
-
Ľudia, ktorý nerobia v PHP povedia, že to je prasačina, zlý kód atď. a to aj kvôli tomu, že je dynamicky typovaný. K veci, ak sa naučíš programovať
v jednom jazyku tak do ďalšieho sa dostaneš pomerne rýchlo tiež, veci si nájdeš v dokumentacií a máš vystarané, po nejakom čase sa vtom zabehneš.
Určite by som neodsudzoval nejaký jazyk, každý sa dá dobre využiť na niečo iné. Načo by niekto strácal čas a peniaze na nejaký malý projekt a mal to písať v jave
alebo inom jazyku keď požiadavkám vyhovuje napr. aj PHP. Zas nebude vtom niekto kódiť server, alebo iné služby keď nato môže využiť zas niečo iné.
Naviac, keď sa naučíš používať "pekne" nejaký framework, šablóny,..tak ten kód vyzerá oveľa lepšie :)
-
...
Změnilo se hodně, z PHP se mezitím stal plnohodnotný multiparadigmatický jazyk, vhodný zejména ke generování čehokoliv. Návrhové vzory se v něm aplikují mnohem snáze, než např. v Javě, protože se nemusí obcházet hromada klacků, které Java hází vývojářům pod nohy za účelem "čistoty" kódu. Prasit se však dá i v Javě. PHP je mnohem lépe vybaveno na zpracování textů. Vždyť v Javě nejsou ani tolik potřebné funkce map(), filter() a reduce() a programátor jejich potřebu musí obcházet přes cykly nebo rekurzi.
...
Pusobi to trochu komicky, psat o zlatych zmenach v PHP a pritom ignorovat zmeny v Jave... http://docs.oracle.com/javase/8/docs/api/java/util/stream/package-summary.html
-
Pusobi to trochu komicky, psat o zlatych zmenach v PHP a pritom ignorovat zmeny v Jave... http://docs.oracle.com/javase/8/docs/api/java/util/stream/package-summary.html
Mám Javu sedmičku a v ní to ještě není. V PHP jsou tyto funkce už od verze 4.
-
V PHP jsou tyto funkce už od verze 4.
v jave je oop od verzie 1
badum tsss.
existuje guava alebo ine veci na funkcionalne elementy
okrem toho si mozete nalozit napr. groovy a tam si rubat closury do bezvedomia
-------
imho clovek moze pokojne preskocit fazu "bol som phpckar na webe" a ist rovno do sveta enterprise javy (kde si ako alternativu moze robit androidy) alebo ist robit c / c++ / objectivec
-
V PHP jsou tyto funkce už od verze 4.
v jave je oop od verzie 1
Tak proč to OOP v Javě využívá tak málo programátorů?
-
Céčko bych začátečníkovi nedoporučil. Raději Python.
A to já zase jo, ale to staré dobré ANSI C, případně C99. Mně to teda dalo docela dost (správa paměti, pointery apod. s tím se webař moc nesetká). Stejně tak si myslím že každý, i když chce dělat jen webového programátora, by měl zkusit něco napsat v assembleru. Je dobré vědět jak to chodí pod pokličkou...
-
V PHP jsou tyto funkce už od verze 4.
v jave je oop od verzie 1
Tak proč to OOP v Javě využívá tak málo programátorů?
Pardon že se vám do toho pletu, ale vážně se tady porovnáváte Javu a PHP z hlediska "higher-order programming"? To abych někde našel "vtipný" obrázek s paralympiádou...
Zkuste si nějak pořádně jazyky jako python, ruby, groovy, scala (abych jmenoval dva zástupce z obou stran) a uvidíte, že PHP a Java je prostě na jedno brdo. Já osobně mám ze stávajícího stavu PHP silný pocit, že hlavní inspirací vývoje od verze 3 byla právě Java :-(
-
V PHP jsou tyto funkce už od verze 4.
v jave je oop od verzie 1
Tak proč to OOP v Javě využívá tak málo programátorů?
bez prikladov je to argumentacny vystrel do tmy
-
no nevim, jak ti php pomuze treba k pochopeni stl v c++...
Jazyk C++ se pro začátečníka vůbec nehodí. Kdyby začal s C++, zase by nepochopil OOP. Tak si vyber.
jo, to mas pravdu, takhle jsem nad tim ze sveho pohledu cloveka co uz oop zvlada nepremyslel.
-
Tak proč to OOP v Javě využívá tak málo programátorů?
bez prikladov je to argumentacny vystrel do tmy
Stačí se podívat na příklady použití Javy v dokumentaci, které jsou z velké části napsány procedurálním stylem. Hromada metod v knihovnách začíná na set... a get..., což s OOP moc nesouvisí. Programátoři pak tento styl slepě používají ve svých aplikacích a dělají další procedurální gettery a settery.
-
Zkuste si nějak pořádně jazyky jako python, ruby, groovy, scala (abych jmenoval dva zástupce z obou stran) a uvidíte, že PHP a Java je prostě na jedno brdo. Já osobně mám ze stávajícího stavu PHP silný pocit, že hlavní inspirací vývoje od verze 3 byla právě Java :-(
Java a PHP se skutečně hodně podobají, ale psst, javisti to neradi slyší :-)
-
Stačí se podívat na příklady použití Javy v dokumentaci, které jsou z velké části napsány procedurálním stylem. Hromada metod v knihovnách začíná na set... a get..., což s OOP moc nesouvisí. Programátoři pak tento styl slepě používají ve svých aplikacích a dělají další procedurální gettery a settery.
gettre a settre su v jave lame nahrada za properties (lombok anyone?), ktore c# a spol riesia lepsie, ale oop nie je o gettroch a settroch, ked je tu este inheritance a interfejsy, ktore java rozhodne pouziva.
ktory projekt / jazyk je podla vas vzorom pre oop?
lebo oop nie je o gettroch a settroch, pokial teda nie ste na urovni, ze pre kazdy private member automaticky nechate ide vygenerovat getter a setter.
/a red herring protivystrel: kolko phpckarov mapy a foldy realne v projektoch pouziva?/
-
gettre a settre su v jave lame nahrada za properties (lombok anyone?), ktore c# a spol riesia lepsie, ale oop nie je o gettroch a settroch, ked je tu este inheritance a interfejsy, ktore java rozhodne pouziva.
Java mi nevadí, pouze se mi příčí její chybné používání. OOP je hlavně o přesouvání algoritmů směrem k datům, do objektů. Gettery a settery tento princip narušují. C# problém getterů a setterů neřeší, ale spíš zhoršuje.
ktory projekt / jazyk je podla vas vzorom pre oop?
Objektově se dá programovat téměř v jakémkoli jazyku. Tedy i v Javě, PHP, C#, Pythonu,... Žádný z nich programátora nenaučí psát objektově, to se musí naučit z kvalitních učebnic a od kvalitních učitelů.
lebo oop nie je o gettroch a settroch, pokial teda nie ste na urovni, ze pre kazdy private member automaticky nechate ide vygenerovat getter a setter.
Naopak. Pro privátní atributy nedělám žádné gettery ani settery. Není důvod. Prostě je nepotřebuji. Nemanipuluji s privátními atributy objektu, ale s objektem.
/a red herring protivystrel: kolko phpckarov mapy a foldy realne v projektoch pouziva?/
Obávám se, že jich zas moc nebude. Přitom vypadají velmi elegantně a jsou i efektivní.
-
Objektově se dá programovat téměř v jakémkoli jazyku.
ja som chcel konkretne, lebo toto su take genericke (ehm) vyroky, ze az
Žádný z nich programátora nenaučí psát objektově, to se musí naučit z kvalitních učebnic a od kvalitních učitelů.
a to su ktori? (dufam, ze nedostanem odpoved, ze to su tie, ktore su napisane kvalitne)
Gettery a settery tento princip narušují.
predpokladam, ze sme sa zhodli na tom, ze bezduche generovanie getterov a setterov pre vsetky privatne premenne je blbost (ale to sa da odnaucit dobrou z kvalitnych ucebnic od kvalitnych ucitelov)
napriklad spring dost tlaci do toho, ze settery sa davaju pre zavislosti a gettery a settery sa pouzivaju pre data transfer object. napriek tomu, ze anemicky model neni nic moc, v jave vela moznosti nie je... paradoxne, springovske a JEE architektury na tom funguju, je to udrzovatelne, a predpokladam, ze nik neoponuje voci tomu, ze je to objektovo orientovane.
Obávám se, že jich zas moc nebude. Přitom vypadají velmi elegantně a jsou i efektivní.
takze sme dosli k zaveru, ze tieto konstrukcie su aj v jave aj v php, akurat v php k nim nedosli developeri a v jave ste este k nim nedosli vy :-) ale to sa samozrejme casom zmeni k lepsiemu
-
Žádný z nich programátora nenaučí psát objektově, to se musí naučit z kvalitních učebnic a od kvalitních učitelů.
a to su ktori? (dufam, ze nedostanem odpoved, ze to su tie, ktore su napisane kvalitne)
Oblíbil jsem si Roberta C. Martina, Martina Fowlera a Bruce Eckela. Samozřejmě jejich učebnice i videa.
napriklad spring dost tlaci do toho, ze settery sa davaju pre zavislosti a gettery a settery sa pouzivaju pre data transfer object. napriek tomu, ze anemicky model neni nic moc, v jave vela moznosti nie je... paradoxne, springovske a JEE architektury na tom funguju, je to udrzovatelne, a predpokladam, ze nik neoponuje voci tomu, ze je to objektovo orientovane.
Pokud je např Spring napsán anemicky, tak se na to můžeme napojit objektově. Píšeme další vrstvu a můžeme ji psát jiným stylem, než jak vývojáři psali Spring. Není tedy nutné jim to vyčítat, ale také není nutné psát jejich stylem. Je jen nutné dodržet rozhraní. Podobně prezentační vrstvu nedělám objektově, ale deklarativně. Proč? Protože se to tak píše lépe a šablony jsou přenositelné mezi programovacími jazyky.
-
suhlasim, eckel teda bol jeden cas hviezda Javy, ale asi by ste zistili, ze by ste miestami nad nim prskali, detto pri fowlerovi netreba byt fowlerovskejsi nez fowler [1], mohlo by dojst k zaujimavym pozorovaniam :-) triezvost je dobre ovladat.
inak ja by som fakt chcel vidiet ten tutorialny projekt, lebo zacinam mat pocit, ze su tu nejake vysnivane koncepty bez odrazu v realite
konkretne: ako konkretne by sa na spring dalo napojit objektovo? co by ta este-viac-objektovo-orientovana robila? to ste v reali nieco take robili? ved spring v jave principialne pokryva takmer vsetko, co by z hladiska konkretnej neanemickej architektury taka vacsia aplikacia mohla pokryvat.
viete to elaborovat?
[1] http://martinfowler.com/bliki/GetterEradicator.html
-
suhlasim, eckel teda bol jeden cas hviezda Javy, ale asi by ste zistili, ze by ste miestami nad nim prskali, detto pri fowlerovi netreba byt fowlerovskejsi nez fowler [1], mohlo by dojst k zaujimavym pozorovaniam :-) triezvost je dobre ovladat.
[1] http://martinfowler.com/bliki/GetterEradicator.html
Ten odkazovaný článek znám a ztotožňuji se s jeho obsahem. Zcela správně tam tvrdí, že pokud se objektu ptám 2×, měl bych se přinejmenším zamyslet nad tím, zda by nešlo se ho zeptat jen jednou přesunutím části funkcionality dovnitř objektu.
Vím, že to nejde udělat vždy. Pokud to nejde, pokládám si další otázku, jestli ten objekt má být skutečně jen jeden. Často vývojář slepí dohromady několik atributů do jedné třídy. Po jejich rozseknutí do samostatných tříd najednou vidím, že rozvolněním vazeb vznikají kvalitativně jiné možnosti, jak s nimi pracovat.
inak ja by som fakt chcel vidiet ten tutorialny projekt, lebo zacinam mat pocit, ze su tu nejake vysnivane koncepty bez odrazu v realite
Mám ho napsaný v PHP, ale ještě s ním nejsem zcela spokojen. Až přijde čas, vydám ho.
konkretne: ako konkretne by sa na spring dalo napojit objektovo? co by ta este-viac-objektovo-orientovana robila? to ste v reali nieco take robili? ved spring v jave principialne pokryva takmer vsetko, co by z hladiska konkretnej neanemickej architektury taka vacsia aplikacia mohla pokryvat.
Spring neznám, vycházel jsem z tvrzení
napriklad spring dost tlaci do toho, ze settery sa davaju pre zavislosti a gettery a settery sa pouzivaju pre data transfer object. napriek tomu, ze anemicky model neni nic moc, v jave vela moznosti nie je...
Na takové rozhraní se přece dá objektově navázat, ne?
-
omg epic combo
Mám ho napsaný v PHP, ale ještě s ním nejsem zcela spokojen. Až přijde čas, vydám ho.
takze vas nevydany projekt ma byt prikladom dobreho navrhu OO projektov...lolwut?
Na takové rozhraní se přece dá objektově navázat, ne?
ano, na rozhranie sa da objektovo naviazat
ja stale ale nechapem, preco by ste chceli na nieco, co je z definicie objektovo orientovane napisane nalepovat vrstvu, ktora ma byt objektovo orientovanejsia...
najma ked tam je presne sustava klasickych veci, interfejsy, dedicnost, settre, dependency injection + best practices
fail z vasej strany vyplyva z toho, ze malo tusite, o com rozpravate a bez prikladov si mozete akurat malovat skvele OO krabice na tabulu.
-
Mám ho napsaný v PHP, ale ještě s ním nejsem zcela spokojen. Až přijde čas, vydám ho.
takze vas nevydany projekt ma byt prikladom dobreho navrhu OO projektov...lolwut?
Projekt je vydán, ale není open source. Je na tom něco nepochopitelného?
-
takze vas neviditelny projekt ma byt prikladom dobreho navrhu OO projektov...lolwut?
-
takze vas neviditelny projekt ma byt prikladom dobreho navrhu OO projektov...lolwut?
Bacha, aby sis neublížil. Jak vypadá tvůj viditelný příklad dobrého návrhu OO projektů? Máš k němu dokumentaci v češtině, cestine nebo angličtině?
-
takze vas neviditelny projekt ma byt prikladom dobreho navrhu OO projektov...lolwut?
Bacha, aby sis neublížil. Jak vypadá tvůj viditelný příklad dobrého návrhu OO projektů? Máš k němu dokumentaci v češtině, cestine nebo angličtině?
Sorry, až teď jsem zjistil, že píšeš slovensky (bez diakritiky, tedy mizerně). Takže ve slovenčině nebo slovencine?
-
Pro začátek by bohatě stačilo napsat definici OOP, jak si kdo představuje :) Hned by se ukázalo že část účastníků diskuze má už s tímto potíže, namátkou:
procedurální gettery a settery.
Getter/setter je samozřejmě nic než standardní OOP metoda a je na odpovědnosti programátora co tam napíše.
-
Getter/setter je samozřejmě nic než standardní OOP metoda a je na odpovědnosti programátora co tam napíše.
Že je getter/setter metoda, to je jasné. Méně však je jasné, že takové metody zbytečně rozšiřují rozhraní objektu o přístupy k atributům, které by měly zůstat skryty. Porušují tedy zapouzdření objektu.
-
Že je getter/setter metoda, to je jasné. Méně však je jasné, že takové metody zbytečně rozšiřují rozhraní objektu o přístupy k atributům, které by měly zůstat skryty. Porušují tedy zapouzdření objektu.
To je velké nepochopení. Getter/setter != povinnost umožnit přímý přístup k členské proměnné. Je na libovůli a odpovědnosti programátora co tam napíše, je to normální metoda.
Že tam někdo píše hlouposti ještě neznamená že je to hloupost samo o sobě.
-
To je velké nepochopení. Getter/setter != povinnost umožnit přímý přístup k členské proměnné. Je na libovůli a odpovědnosti programátora co tam napíše, je to normální metoda.
Že tam někdo píše hlouposti ještě neznamená že je to hloupost samo o sobě.
Fajn, až uvidím getter/setter podle těchto pravidel, budu nadšen.
Ještě mi poraď, jak mám nazývat ty mizerné jednořádkové gettery/settery, které jen suplují viditelnost public, ale jinak nejsou schopny ověřit ani validitu parametru?
-
Ještě mi poraď, jak mám nazývat ty mizerné jednořádkové gettery/settery, které jen suplují viditelnost public, ale jinak nejsou schopny ověřit ani validitu parametru?
Pokud to nedělá co to dělat má, pak je to zmetek.
-
Pokud to nedělá co to dělat má, pak je to zmetek.
Dobrá. Budu to tedy nazývat getterový/setterový zmetek, abych to nějak odlišil od ostatních zmetků.
Stále si však myslím, že často je výhodnější místo jednoho anemického objektu se třemi atributy, třemi gettery a třemi settery použít tři plnohodnotné objekty - každý se svým rozhraním, konstruktorem a sadou metod.
-
Stále si však myslím, že často je výhodnější místo jednoho anemického objektu se třemi atributy, třemi gettery a třemi settery použít tři plnohodnotné objekty - každý se svým rozhraním, konstruktorem a sadou metod.
Objekt se třemi private atributy a k tomu 6 metod pouze převádějící viditelnost mezi private a public, je naho*no, to se shodneme. Náhrada záleží na situaci.
-
To je velké nepochopení. Getter/setter != povinnost umožnit přímý přístup k členské proměnné. Je na libovůli a odpovědnosti programátora co tam napíše, je to normální metoda.
Že tam někdo píše hlouposti ještě neznamená že je to hloupost samo o sobě.
Fajn, až uvidím getter/setter podle těchto pravidel, budu nadšen.
Ještě mi poraď, jak mám nazývat ty mizerné jednořádkové gettery/settery, které jen suplují viditelnost public, ale jinak nejsou schopny ověřit ani validitu parametru?
ze by enterprise?
-
Bacha, aby sis neublížil. Jak vypadá tvůj viditelný příklad dobrého návrhu OO projektů?
spring framework. skvela inspiracia pre citanie
Stále si však myslím, že často je výhodnější místo jednoho anemického objektu se třemi atributy, třemi gettery a třemi
settery použít tři plnohodnotné objekty - každý se svým rozhraním, konstruktorem a sadou metod.
eh? mate priklad?
lebo sa bojim, ze v boji voci getterom a setterom vygenerujete cosi, co evokuje ejb 2.1, kde hello world zaberal dva interfejsy, dve implementacie, two turtle doves and a partridge in a pair tree
ku getterom a setterom: to, ze niekto nevidi dovod pisat do settera validacie napr. pre zaporne parametre, je problem vyvojara, ktory to mozno nepovazuje za potrebne (opat, autogenerovanie bez zmyslu)
a dolezita vec: gettre a settre maju dalsiu vyhodu, stoji na nej tooling (napr. reflexia, javabeans, mapovanie jsonov, mapovanie databaz)
-
ku getterom a setterom: to, ze niekto nevidi dovod pisat do settera validacie napr. pre zaporne parametre, je problem vyvojara, ktory to mozno nepovazuje za potrebne (opat, autogenerovanie bez zmyslu)
zrovna k tomu se settery a gettery moc nehodi ;), ne ze by daji se pouzit ale jsou lepsi zpusoby jak toto resit
-
ku getterom a setterom: to, ze niekto nevidi dovod pisat do settera validacie napr. pre zaporne parametre, je problem vyvojara, ktory to mozno nepovazuje za potrebne (opat, autogenerovanie bez zmyslu)
zrovna k tomu se settery a gettery moc nehodi ;), ne ze by daji se pouzit ale jsou lepsi zpusoby jak toto resit
Máš na mysli obalové třídy?
-
samozrejme, validacia sa da riesit externe.
kit, takze z prikladu pre Pravejsie OOP nic? :-) miesto toho novy termit?
-
Bacha, aby sis neublížil. Jak vypadá tvůj viditelný příklad dobrého návrhu OO projektů?
spring framework. skvela inspiracia pre citanie
To je tvůj framework? A jede v PHP?
-
samozrejme, validacia sa da riesit externe.
Externí validace? To myslíš vážně?
-
nechcete si jit rozslapavat babovicky jinam?
-
Externí validace? To myslíš vážně?
javax.validation
-
Externí validace? To myslíš vážně?
javax.validation
Takže ji voláš z konstruktoru validovaného objektu? To pak není externí validace, ale interní.
-
ku getterom a setterom: to, ze niekto nevidi dovod pisat do settera validacie napr. pre zaporne parametre, je problem vyvojara, ktory to mozno nepovazuje za potrebne (opat, autogenerovanie bez zmyslu)
zrovna k tomu se settery a gettery moc nehodi ;), ne ze by daji se pouzit ale jsou lepsi zpusoby jak toto resit
Máš na mysli obalové třídy?
JJ, v pripade nekterych jazyku existuji i specialny vlastni typy s vlastnimi rozsahy hodnot atd.
-
Máš na mysli obalové třídy?
JJ, v pripade nekterych jazyku existuji i specialny vlastni typy s vlastnimi rozsahy hodnot atd.
Zjistil jsem, že ty obalové třídy skutečně má smysl dělat. Logika objektu (refaktorovaného z pouhého atributu) je hezky zapouzdřena a dá se dobře recyklovat. Kupodivu se tím aplikace o něco málo zkrátí a stane se robustnější. Také se dá mnohem lépe použít polymorfismus, takže odpadne spousta rozhodovacích bloků a program se o něco zrychlí.
-
Externí validace? To myslíš vážně?
javax.validation
Takže ji voláš z konstruktoru validovaného objektu? To pak není externí validace, ale interní.
opat dedukujete z niecoho, o com viete malo, mlady padawan
validaciu vola externy objekt. moznost c. 1 je obhadzat instancne premenne / gettre a settre (sic!) anotaciami a externy objekt to zvaliduje, alebo v spring style vyrobite externy validator s pravidlami (nieco ako nette ked definuje validacne pravidla pre polozky html formulara)
Kupodivu se tím aplikace o něco málo zkrátí a stane se robustnější.
A moje pradlo je este bielejsie.
-
validaciu vola externy objekt. moznost c. 1 je obhadzat instancne premenne / gettre a settre (sic!) anotaciami a externy objekt to zvaliduje, alebo v spring style vyrobite externy validator s pravidlami (nieco ako nette ked definuje validacne pravidla pre polozky html formulara)
Takže objekt si ani nedokáže ohlídat vlastní vstupy? Co je to za objekt?
Podíval jsem se na ten Spring. Dávat ho jako příklad kvalitního OOP je fakt velkou odvahou. Když už se chlubíš cizím peřím, tak se aspoň podívej na ty prasárny uvnitř.
-
validaciu vola externy objekt. moznost c. 1 je obhadzat instancne premenne / gettre a settre (sic!) anotaciami a externy objekt to zvaliduje, alebo v spring style vyrobite externy validator s pravidlami (nieco ako nette ked definuje validacne pravidla pre polozky html formulara)
V takovém případě objekt a zmetské gettery/settery vůbec nepotřebujete a můžete použít tradiční strukturu. Nebo emulaci struktury přes public members variable, když se autoři jazyka na struktury vykašlali.
-
samozrejme, validacia sa da riesit externe.
Externí validace? To myslíš vážně?
Externí validace může vést k vyšší znovupoužitelnosti kódu - např. lze použít jednu strukturu pro držení dat a k ní mít více různých stupňů validnosti.
-
Externí validace může vést k vyšší znovupoužitelnosti kódu - např. lze použít jednu strukturu pro držení dat a k ní mít více různých stupňů validnosti.
U struktury není žádný problém. Ovšem nelze takhle validovat private member variables, to je velmi špatně.
-
Externí validace může vést k vyšší znovupoužitelnosti kódu - např. lze použít jednu strukturu pro držení dat a k ní mít více různých stupňů validnosti.
U struktury není žádný problém. Ovšem nelze takhle validovat private member variables, to je velmi špatně.
Ano, vše by bylo public (alespoň z pohledu validátoru).
-
nechcete si jit rozslapavat babovicky jinam?
Napadlo mi ine prirovnanie (o merani casti tela), ale toto je tiez dobre.
Btw. skusim odpovedat na polozenu otazku. PHP nie je vobec nutne k uplatneniu, ale pomocou znalosti PHP sa da dobre uplatnit (neviem preco mnohi tu otazku pochopili ako, ci je PHP ta jedina prava cesta k perfektnemu systemu a uplatneniu sa).
-
Externí validace může vést k vyšší znovupoužitelnosti kódu - např. lze použít jednu strukturu pro držení dat a k ní mít více různých stupňů validnosti.
U struktury není žádný problém. Ovšem nelze takhle validovat private member variables, to je velmi špatně.
Ano, vše by bylo public (alespoň z pohledu validátoru).
To je takový problém z těch zvalidovaných dat rovnou vyrobit objekt? Public viditelnost pak není nutná.
-
To je takový problém z těch zvalidovaných dat rovnou vyrobit objekt?
A proč bych to dělal, proč bych měl splácat dvě věci dohromady? Podobně proč by mělo být např. compare součástí objektu, když může existovat mnoho různých uspořádání?
-
Ani jedním neuděláš do budoucna chybu - pokud vytrváš.
C/C++ - delší doba učení, spousta práce, výsledek pomalu. Využití v praxi - složitější věci, ke kterým se dostaneš až po pár letech.
Java - delší doba učení, méně práce, výsledek rychleji. Využití v praxi - skoro hned, od jednoduchých věcí až po složité.
PHP - krátká doba učení, méně práce, výsledek hned. Využít v praxi - hned.
V C/C++ když jsi mistr, tak jsi mistr, ale ta cesta k tomu být je dlouhá. V PHP můžeš něco vytvořit i se znalostí základů, spousta věcí je hotových, atd. Java je něco mezi tím.
Pokud jsi začátečník, začal bych něčím, kde uvidíš hnedka na začátku výsledek svojí práce - což je na prvním místě PHP, pak Java. Jinak by tě to mohlo odradit, a programování ti do konce života znechutit - nebo taky ne, to záleží.
Další věc je, že řešením skutečných problémů (=> práce) se naučíš nejvíc. A k tomu se rychlejdi dostaneš s PHP, popřípadě Javou.
Po tom co se naučíš principy programování, tak další jazyk nebude problém - už se budeš jen učit věci specifické pro tento jazyk, a jeho knihovny (což je 90% učení Javy).
Největší problém bude vytvrat - a k tomu ti pomůže vidět nějaký praktický výsledek co nejdřív.
-
To je takový problém z těch zvalidovaných dat rovnou vyrobit objekt?
A proč bych to dělal, proč bych měl splácat dvě věci dohromady? Podobně proč by mělo být např. compare součástí objektu, když může existovat mnoho různých uspořádání?
K čemu je mi validace, když nedostanu výsledek? Taková validace není pro OOP, ale pro procedurální styl.
-
To je takový problém z těch zvalidovaných dat rovnou vyrobit objekt? Public viditelnost pak není nutná.
Není to problém, třeba přes friend class. Rozhodně ne vytvořit objekt a pak tam nasázet data přes zmetský setter.
-
Externí validace? To myslíš vážně?
Externí validace může vést k vyšší znovupoužitelnosti kódu - např. lze použít jednu strukturu pro držení dat a k ní mít více různých stupňů validnosti.
Takhle se ale programuje strukturovaně. Pokud je v enterprise zakázáno použití OOP, tak ať si klidně programují strukturovaně, ale ať nekecají do výuky OOP.
-
Ne, PHP rozhodne neni nutne k uplatneni. PHP ale muze byt pranim zakaznika (to je ten, co to plati) a pak ma samozrejme smysl se jim zabyvat.
Predpokladam, ze v tom jazyce nechces delat jen pidiprojekty a ze by te to melo zivit. Pak bych ti rad napsal, ze PHP je technologicky desna sr...a a pokud to s programovanim myslis vazne, tak se na nej vykasli. PHP neni technologie vhodna na implementaci bussiness logiky, takto pouzita na serveru dokonale pouze vyzira uhli z elektrarny. PHP je chytrejsi sablonovaci jazyk (kdyz uz, tak ho pouzivej v kombinaci), na backend, ani te webove aplikace, se nehodi. Spousta lidem tady na Rootu se muj nazor nebude libit, ale tech 12 let, ktere jsem profesne stravil vyvojem a udrzbou webovych aplikaci, mluvi zcela jasne: mnoho malych a predevsim jednoduchych webovych aplikaci v PHP je OK (vizitky, prezentace, ...), ale na vetsi aplikace se opravdu nehodi a uz vubec ne, aby vas na nem nekdo ucil jak se programovuje (to uz vas muze ucit programovat v PDF; PHP je tak trochu vysmech programovacim jazykum). Pouzivejte ho jako sablonovaci nastroj, ostatni pouziti tohoto nastroje je spatne pouziti.
Ucitele pozdravuji a ze doporucuji, aby nezustal i nadale lenivym a rozhledl se po rozumnejsich technologiich na uceni programovani namisto PHP.
-
K čemu je mi validace, když nedostanu výsledek?
akoze nedostanete? v springu ked neuspesne zvalidujete objekt, dostanete pekny hashmap chyb na jednotlivych atributoch.
Pokud je v enterprise zakázáno použití OOP, tak ať si klidně programují strukturovaně, ale ať nekecají do výuky OOP.
Ale vy ste stale neuviedli konkretny priklad, ako by sa to malo robit, stale len placate o akomsi fiktivnom "bad bad baaaad" strukturovanom programovani, ktore ste si zadefinovali len vy v hlave.
Nehovoriac o tom, ze vyuka OOP je do velkej miery prejavom toho, co je v praxi, a nie naopak, ako vasom pripade.
-
K čemu je mi validace, když nedostanu výsledek?
akoze nedostanete? v springu ked neuspesne zvalidujete objekt, dostanete pekny hashmap chyb na jednotlivych atributoch.
Když validuji v konstruktoru, tak případnou chybu dostanu také a v přesnější podobě - všetně přesného označení místa, kde chyba vznikla. To mi externí validace neudělá.
Pokud je v enterprise zakázáno použití OOP, tak ať si klidně programují strukturovaně, ale ať nekecají do výuky OOP.
Ale vy ste stale neuviedli konkretny priklad, ako by sa to malo robit, stale len placate o akomsi fiktivnom "bad bad baaaad" strukturovanom programovani, ktore ste si zadefinovali len vy v hlave.
Nehovoriac o tom, ze vyuka OOP je do velkej miery prejavom toho, co je v praxi, a nie naopak, ako vasom pripade.
Příklady jsem uvedl. Jenom je nevidíš. Když někdo v praxi neví, jak se dělá OOP, tak ať si programuje jak chce, ale ať do toho nekecá. Jsem zvědav, kdy uvidím nějaké tvé příklady.
A v tom tvém Springu autoři ani neumí ani pořádně pojmenovat interface. To má být podle tebe super kvalitní OOP? Je to hrůzný moloch, který má skoro milión řádek. Copak do OOP patří logické špagety?
-
tu je dalsie food for frolls
Když validuji v konstruktoru, tak případnou chybu dostanu také a v přesnější podobě - všetně přesného označení místa, kde chyba vznikla. To mi externí validace neudělá.
co znamena presne oznacenie miesta? mate zaporny pocet neuronov na riadku 25 v triede Mozog? (nerozumiem tomu, preto sa pytam a dufam, ze mi date priklad)
Příklady jsem uvedl. Jenom je nevidíš.
pardon, mozete mi ukazat konkretne prispevky, kde ste ich dali?
A v tom tvém Springu autoři ani neumí ani pořádně pojmenovat interface. To má být podle tebe super kvalitní OOP? Je to hrůzný moloch, který má skoro milión řádek. Copak do OOP patří logické špagety?
co je podla vas priklad pomenovania interfacu? lebo v jave nie je konvencia pomenovata IBrainService ani BrainServiceInterface (ine konvencie som nevidel).
Copak do OOP patří logické špagety?
ktory iny rozsiahly projekt s oop pouzite ako ukazku? (okrem vasho).
-
Když validuji v konstruktoru, tak případnou chybu dostanu také a v přesnější podobě - všetně přesného označení místa, kde chyba vznikla. To mi externí validace neudělá.
co znamena presne oznacenie miesta? mate zaporny pocet neuronov na riadku 25 v triede Mozog? (nerozumiem tomu, preto sa pytam a dufam, ze mi date priklad)
Třeba i takhle a je to vypropagováno do místa volání konstruktoru. Stačí jen tu výjimku zachytit nebo ji nechat propadnout.
Příklady jsem uvedl. Jenom je nevidíš.
pardon, mozete mi ukazat konkretne prispevky, kde ste ich dali?
Kdo hledá, najde.
A v tom tvém Springu autoři ani neumí ani pořádně pojmenovat interface. To má být podle tebe super kvalitní OOP? Je to hrůzný moloch, který má skoro milión řádek. Copak do OOP patří logické špagety?
co je podla vas priklad pomenovania interfacu? lebo v jave nie je konvencia pomenovata IBrainService ani BrainServiceInterface (ine konvencie som nevidel).
Adjektivum.
Copak do OOP patří logické špagety?
ktory iny rozsiahly projekt s oop pouzite ako ukazku? (okrem vasho).
Rozsáhlé projekty mě moc nezajímají, protože dělají zbytečně mnoho věcí a nic z toho pořádně. Raději sem nebudu dávat další krmivo pro trolly. Vystačíme s tím, co tu už máme.
-
tu je dalsie food for frolls
Tak nám konstruktivně řekni, jak se v tvém případě ty zvalidované data dostanou dovnitř instance do private member variables a to tak aby se eliminovala potřeba zmetských setterů.
-
Já umím Javu (obecně a pro Android, J2EE věci neumím) docela dobře, C docela dobře a C++ použitelně (ale s hardcore fanoušky C++ se pracovně nesnesu :-) ) a uplatním se bez problémů. Weby umím dělat velmi špatně, ale v práci mi to nevadí. Přijde mi i, že najít dobru práci na dělání webu je hodně těžké, protože opravdu hodně lidí to aspoň trochu umí, takže je třeba být opravdu dobrý, pokud chcete, aby si vás v práci vážili. Naopak, Javu, C a C++ umí na použitelné úrovni relativně málo lidí. Takže pokud se v těch jazycích dokážete vyjádřit (tj. např. napsat šachový program) a nejste asociál, tak nebudete mít v práci problém. Samozřejmě jakákoli znalost je výhoda, nicméně podmínka to není.
-
a kolko chcete zarabat?
Web developer To je to PHP 1 090 € (30 058 CZK)
alebo
Architekt HW systému 2 980 € (82 177 CZK)
Architekt IS 2 500 € (68 940 CZK)
http://www.naseplaty.sk/prehlad-platov/informacne-technologie.html
pripadnme chcete robit trosku lepsiu pracu, ale len na obmedzeny cas
Názov pozície JAVA Programátor/Leader
Predpokladaná suma plnenia 3800 až 5800 € mesačne (104 790 CZK- 159 942 CZK )
Miesto plnenia Slovensko / Bratislava
Termín 07.01.2014 - 31.12.2015
Druh spolupráce živnosť alebo s.r.o. (spoločnosť s ručením obmedzeným) - Vy to poznate ako Dvarc system
Názov pozície Solution Architekt
Predpokladaná suma plnenia 4900 až 6000 € mesačne (135 123 CZK- 165 457 CZK)
Miesto plnenia Slovensko / Bratislava
Termín 15.12.2014 - 31.05.2015
Druh spolupráce živnosť alebo s.r.o. (spoločnosť s ručením obmedzeným)
http://titans.sk/sk/it-freelancers/pracovne-ponuky/
Cim vyssia suam, tym viac ucenia...
-
Tak nám konstruktivně řekni, jak se v tvém případě ty zvalidované data dostanou dovnitř instance do private member variables a to tak aby se eliminovala potřeba zmetských setterů.
skuste mi popisat situaciu blizsie, moznosti je viac
napr. javax.validation umozni validovat anotovane instancne premenne (@NotNull private int pocetNeuronov) a nemusite mat gettery/settery, ide sa na to reflexiou
-
Tak nám konstruktivně řekni, jak se v tvém případě ty zvalidované data dostanou dovnitř instance do private member variables a to tak aby se eliminovala potřeba zmetských setterů.
skuste mi popisat situaciu blizsie, moznosti je viac
napr. javax.validation umozni validovat anotovane instancne premenne (@NotNull private int pocetNeuronov) a nemusite mat gettery/settery, ide sa na to reflexiou
Ano, to je fakt výhra mít validaci v anotacích :D
-
... Ano, to je fakt výhra mít validaci v anotacích :D
Nemam moc zkusenosti s validaci, nejsem profesional; mohl bych poprosit o vysvetleni, proc je to spatne? (Takhle "na papire" to pusobi celkem pouzitelne a logicky.)
-
a kolko chcete zarabat?
...
Architekt HW systému 2 980 € (82 177 CZK)
Architekt IS 2 500 € (68 940 CZK)
Predpokladaná suma plnenia 3800 až 5800 € mesačne (104 790 CZK- 159 942 CZK )
Predpokladaná suma plnenia 4900 až 6000 € mesačne (135 123 CZK- 165 457 CZK)
Prezident Slovenska ...
P(r)asydent Česka ...
Prezident Zemegule ...
Prezydent Vesmíru ...
...
;D ;D ;D
A přesně o tom to je!
Getry/Setry ...
PS: Není to Dvarc, ale Švarc. (otázku, na kolik je to dobré a pro koho tu nebudu řešit (ani to zřejmě nejde))
-
Ano, to je fakt výhra mít validaci v anotacích
mozete mat validacne pravidla definovane explicitne a rovnako obchadzat instancne premenne reflexiou
-
ide sa na to reflexiou
Reflexe není OOP, tím není dotčena funkčnost, nepochybně to funguje.
Prostě si z objektů děláte klasickou strukturu, jelikož se na Vás evidentně autoři jazyka se strukturami vys*. Odněkud nataháte data, zpracujete je a pak je nasázíte do struktury, OOP na tohle vůbec nepotřebujete, jsou to pro Vás klacky pod nohy.
-
ano, pokial sa bavime o hladisku akademickej cistoty, tak toto nie je featura, ktora by bola na reklamnom slajde s napisom "toto je oop".
ale to som vravel vyssie, ze je to featura pouzivana pri DTO a anemickom modeli, ktory napr. na webe v JEE je pomerne technicky problem implementovat
otazka ostava, ako by vyzeralo cistejsie OOP riesenie.
-
Musim povedat, ze nechapem hateovanie getterov a setterov.
V PHP som sa zatial nedostal do situacie, kedy by mi zacali prekazat. Pekne reprezentuju enkapsulaciu dat v objekte. Clenske premenne su private a ked chcem vybrat hodnotu, tak pouzijem getter a nemusim sa starat o to v akom stave tie data pridu, pretoze viem, ze getter sa postara o to aby prisli v pouzitelnej forme.
A pokial nechcem nejaku clensku premennu ukazovat svetu, tak ten getter ani nenapisem. A tym je aj dalsim programatorom v time jasne co ma v kode aky vyznam.
Rovnako ked chcem hodnotu zmenit, tak pouzijem setter a nestaram sa o validnost dat, pretoze viem, ze sa postara setter.
A ze rozsiria triedu o niekolko metod? No boze... Ano, na pohlad to nie je pekne, ale trieda ma fungovat a nie byt pekna na pohlad. A pokial mam clenskych premennych privela, tak je cas sa vratit k navrhu, pretoze je nieco zle tam...
-
Musim povedat, ze nechapem hateovanie getterov a setterov.
Jde hlavně o primitivní jednořádkové gettery a settery, které pouze suplují public viditelnost a jinak nic nedělají. Svádějí k tvorbě anemických tříd, ve kterých jednotlivé atributy spolu vůbec nesouvisí, pouze jsou "tak nějak pohromadě".
V PHP som sa zatial nedostal do situacie, kedy by mi zacali prekazat. Pekne reprezentuju enkapsulaciu dat v objekte. Clenske premenne su private a ked chcem vybrat hodnotu, tak pouzijem getter a nemusim sa starat o to v akom stave tie data pridu, pretoze viem, ze getter sa postara o to aby prisli v pouzitelnej forme.
Zkus enkapsulaci atributu tak, že každý nezávislý atribut dáš do samostatné třídy. K tomu konstruktor a dalších pár užitečných metod.
A pokial nechcem nejaku clensku premennu ukazovat svetu, tak ten getter ani nenapisem. A tym je aj dalsim programatorom v time jasne co ma v kode aky vyznam.
Rovnako ked chcem hodnotu zmenit, tak pouzijem setter a nestaram sa o validnost dat, pretoze viem, ze sa postara setter.
A ze rozsiria triedu o niekolko metod? No boze... Ano, na pohlad to nie je pekne, ale trieda ma fungovat a nie byt pekna na pohlad. A pokial mam clenskych premennych privela, tak je cas sa vratit k navrhu, pretoze je nieco zle tam...
Jde o to neukazovat světu žádnou členskou proměnnou a to ani prostřednictvím getterů/setterů. S atributy objektů se nepracuje venku, ale uvnitř. OOP je o přesouvání funkcionality co nejblíž k datům, tedy vytváření plnohodnotných objektů.
[/quote]
-
;D ;D ;D
A přesně o tom to je!
Getry/Setry ...
PS: Není to Dvarc, ale Švarc. (otázku, na kolik je to dobré a pro koho tu nebudu řešit (ani to zřejmě nejde))
Ano to bol moj preklep S za D. Aj ked ja by som to pisal Schwarz s ohladom na moje rodne mesto a jeho historiu
Po oficiálnom sčítaní obyvateľov v rokoch 1850 až 1851 bolo v Bratislave 42 238 obyvateľov, z toho 31 509 (74,59%) Nemcov, 7 586 (17,9%) Slovákov a 3 154 (7,4%) Maďarov. Veľa Židov bolo zarátaných medzi Nemcov alebo Maďarov.
V roku 1890 prebehlo ďalšie sčítanie a tu sa už prejavila silná maďarizácia. V meste malo žiť 52 441 obyvateľov, z toho 31 404 Nemcov, 10 433 Maďarov a 8 709 Slovákov.
V roku 1907 tu žilo vyše 70-tisíc obyvateľov, z čoho tretinu tvorili Maďari, polovicu Nemci, sedminu Slováci, okrem toho ešte Chorváti, Srbi, Bulhari, Rumuni, a iné národnosti.
http://sk.wikipedia.org/wiki/Bratislava
Aj ked je to skor v style piesne Tesinska
http://www.supermusic.sk/skupina.php?idpiesne=687&sid=
-
Zmetské gettery a settery se tedy používají proto, že jazyk/IDE k nim poskytuje extravuřty, jež nejsou součástí OOP.
To je pak všechno jasné.
-
Kit: rozumiem tomu suplovaniu public metody jednoriadkovymi gettermi/settermi, ale ja, napriklad, mam rad ked je uz na nulty pohlad poriadok v tom co sa da pouzit a ako. Preto mi je proti srsti kombinovanie public vlastnosti a getterov/setterov a potom nasledne hadanie co este public je a co uz musim volat getterom.
To uz radsej mam vsetko private a obsluhovane gettermi a settermi, ale len ak je naozaj treba z vonku tieto atributy menit. Ak nie, tak getter/setter ani nepisem.
-
Kit: rozumiem tomu suplovaniu public metody jednoriadkovymi gettermi/settermi, ale ja, napriklad, mam rad ked je uz na nulty pohlad poriadok v tom co sa da pouzit a ako. Preto mi je proti srsti kombinovanie public vlastnosti a getterov/setterov a potom nasledne hadanie co este public je a co uz musim volat getterom.
public vlastnosti nepoužívám.
To uz radsej mam vsetko private a obsluhovane gettermi a settermi, ale len ak je naozaj treba z vonku tieto atributy menit. Ak nie, tak getter/setter ani nepisem.
Také mám všechno private, ale bez getterů a bez setterů.
-
public vlastnosti nepoužívám.
Tiez mam bicykel, ale nosim ho v krabici na chrbte...
-
public vlastnosti nepoužívám.
Tiez mam bicykel, ale nosim ho v krabici na chrbte...
Špatně jsi to pochopil. Viditelnost public atributům nedávám.
-
public vlastnosti nepoužívám.
Tiez mam bicykel, ale nosim ho v krabici na chrbte...
Ani ja public vlastnosti nepouzivam. Ak potrebujem, tak k tej vlastnosti mam napisany getter/setter a ak nepotrebujem, tak ani jedno.
Pripada mi prasacke mat cast vlastnosti, ktore su public a cast, ku ktorym je getter/setter. Ked sa k takej triede vratim po pol roku, tak stale musim pozerat, ze co musim volat priamo a co cez getter/setter.
Na druhu stranu, bez public vlastnosti viem, ze vsetko je private a ze obsah kazdej vlastnosti ziskam cez get metodu.
Public je klucova viditelnost, pri metodach. Pri vlastnostiach proste jeho vyuzitie nevidim. Aj ked rozumiem tomu, ze niekomu sa moze pacit opacny pristup.
-
Public je klucova viditelnost, pri metodach. Pri vlastnostiach proste jeho vyuzitie nevidim. Aj ked rozumiem tomu, ze niekomu sa moze pacit opacny pristup.
Proč pořád píšeš o public vlastnostech, když je ani jeden z nás dvou nepoužívá?
-
Public je klucova viditelnost, pri metodach. Pri vlastnostiach proste jeho vyuzitie nevidim. Aj ked rozumiem tomu, ze niekomu sa moze pacit opacny pristup.
Proč pořád píšeš o public vlastnostech, když je ani jeden z nás dvou nepoužívá?
Lebo som reagoval na NooNa, ktory ich, zrejme, pouziva a cudoval sa nad ich nepouzivanim.
-
Pripada mi prasacke mat cast vlastnosti, ktore su public a cast, ku ktorym je getter/setter. Ked sa k takej triede vratim po pol roku, tak stale musim pozerat, ze co musim volat priamo a co cez getter/setter.
Je naprosto normální mít public členské proměnné.
To že se pak některým přistupuje přímo a k některým přes getter/setter je chyba návrhu jazyka, v ideálním případě se k property přistupuje pořád stejně, nezávisle na tom zda je to členská proměnná nebo getter/setter.
-
Pripada mi prasacke mat cast vlastnosti, ktore su public a cast, ku ktorym je getter/setter. Ked sa k takej triede vratim po pol roku, tak stale musim pozerat, ze co musim volat priamo a co cez getter/setter.
Je naprosto normální mít public členské proměnné.
To že se pak některým přistupuje přímo a k některým přes getter/setter je chyba návrhu jazyka, v ideálním případě se k property přistupuje pořád stejně, nezávisle na tom zda je to členská proměnná nebo getter/setter.
Máš na mysli styl používání getterů/setterů, který je běžný v C# a PHP?
-
Máš na mysli styl používání getterů/setterů, který je běžný v C# a PHP?
Jistě, styl C# toto řeší uspokojivě.
-
Máš na mysli styl používání getterů/setterů, který je běžný v C# a PHP?
Jistě, styl C# toto řeší uspokojivě.
A zkusil jsi to už někdy bez nich? Tedy bez getterů, setterů, properties i public viditelnosti?
Přiznám se, že někdy "gettery" používám v PHP u primitivních úloh, u kterých se mi nevyplatí dělat výstupní šablonu. I když je vlastně nemohu jako gettery označit, protože mi v jejich názvech chybí ta předpona "get". Vypadá to podobně jako použití property v C#.
Větší aplikace však navrhuji tak, abych gettery, settery, property ani public atributy vůbec nepotřeboval.
-
Máš na mysli styl používání getterů/setterů, který je běžný v C# a PHP?
Jistě, styl C# toto řeší uspokojivě.
Presne tak som to myslel aj ja, kde public vlastnost (Property (get/set)) sprostredkovava pristup k private attributom.
Staci si ujednotit nazvoslovie
-
A zkusil jsi to už někdy bez nich?
Větší aplikace však navrhuji tak, abych gettery, settery, property ani public atributy vůbec nepotřeboval.
Zkusil jsem vše. Property a související věci vznikly právě za účelem zvýšení přehlednosti, není znám důvod proč je zavrhnout jako celek.
-
A zkusil jsi to už někdy bez nich?
Větší aplikace však navrhuji tak, abych gettery, settery, property ani public atributy vůbec nepotřeboval.
Zkusil jsem vše. Property a související věci vznikly právě za účelem zvýšení přehlednosti, není znám důvod proč je zavrhnout jako celek.
To tady fakt nikdo neví, jak elegantně a přehledně pracovat bez nich?
-
To tady fakt nikdo neví, jak elegantně a přehledně pracovat bez nich?
Jak se to dělá ví skoro každý. Elegantní a přehledné to není, právě proto property vznikly.
-
To tady fakt nikdo neví, jak elegantně a přehledně pracovat bez nich?
Jak se to dělá ví skoro každý. Elegantní a přehledné to není, právě proto property vznikly.
Zatím vidím jen nepochopení. Kdekdo si myslí, že je mám public. Nemám.
Jak se to tedy dělá bez property to, co není ani elegantní ani přehledné?
-
Jak se to tedy dělá bez property to, co není ani elegantní ani přehledné?
Vysvětlení jak se to dělá bez g/s se čeká od Vás :)
Ve výsledku představíte způsob který je identický dobře napsaným g/s, jenom se metody budou jmenovat jinak.
Připomínám že getter/setter != povinnost zpřístupnit private member variables, programátor si tam může napsat libovolně co chce.
-
Jak se to tedy dělá bez property to, co není ani elegantní ani přehledné?
Vysvětlení jak se to dělá bez g/s se čeká od Vás :)
Ve výsledku představíte způsob který je identický dobře napsaným g/s, jenom se metody budou jmenovat jinak.
Připomínám že getter/setter != povinnost zpřístupnit private member variables, programátor si tam může napsat libovolně co chce.
Vždyť jsem to už psal. Nepracovat s atributy objektu, ale s objektem. Nesouvisející atributy rozdělit do více objektů.
-
PHP se pouziva dneska primarne jen kvuli tomu ze lidi kteri jsou schopni v nem neco slepit je vsude plno a jsou hlavne velmi levni. Ze setrvacnosti i kvuli webhostingum (dneska je uz situace uplne jinde, VPS si muze dovolit vetsina lidi, kteri chteji nejaky slozitejsi eshop nebo webovou aplikaci). Pokud to myslite s webovyma aplikacema vazne zameril bych se na Spring/Play/JSP/... v Jave a k tomu se venoval i jinym jazykum a frameworkum (Node.js, RoR, Django,...).
Naprostej souhlas. PHP je k uplatneni stejne nutne asi jako Paskal v dnesni dobe. Kdyz da Javu/C/++ tak to pro nej nebude problem a Python/Django stoji rozhodne za to. Node.js ma stejnou syntax jako JavaScript (ktery teda taky nemusim), ale v dnesni dobe jet na necem co byl puvodne sablonovaci system pro html a rikat tomu programovani je offtopic. A jestli si chce chlapec vydelat penize tak at se naucit Fortran a extensivni jazyky pro SQL jako TLC atp., protoze v tom psat nikdo nechce a pritom to vsichni musi pozivat v korporatech :) Tak ci onak power of triforce mluvi jasne....
-
Node.js ma stejnou syntax jako JavaScript
8)
-
Node.js ma stejnou syntax jako JavaScript
8)
K smíchu to moc není, hlavní smysl node.js je mít stejnou (= stejně vymaštěnou) syntaxi jazyka na serveru i v prohlížeči.
-
K smíchu to moc není
Mně přišla vtipná ta formulace. Když se to řekne takhle, tak Spring má stejnou syntaxi jako Java, Nette má stejnou syntaxi jako PHP, QT, ... počkat, není "stejných syntaxí" nějak moc najednou?
blablabla
Nemám zájem o flame, toho už je tady dost i bez toho.
-
PHP je k uplatneni stejne nutne asi jako Paskal v dnesni dobe.
Ne tak docela. Vývoj Pascalu se prakticky zastavil, PHP se stále zdokonaluje. Stále je to sice slepenec, ale při dobré sebekázni programátora a s kvalitním testováním se v něm dají napsat i rozsáhlé projekty. Jen se v něm nesmí moc dělat finanční výpočty, protože na ně není řádně vybaven.
Kdyz da Javu/C/++ tak to pro nej nebude problem a Python/Django stoji rozhodne za to. Node.js ma stejnou syntax jako JavaScript (ktery teda taky nemusim),
Python rozhodně za to stojí. Pokud je možnost volby, tak Pythonu dám přednost před PHP.
... ale v dnesni dobe jet na necem co byl puvodne sablonovaci system pro html a rikat tomu programovani je offtopic.
Co bylo, bylo. Dnes už PHP jako šablonovací systém nepoužívám. PHP mám jako lepidlo mezi HTTP serverem, databází a výstupní šablonou. Vyhozením šablon z PHP aplikacím významně prospělo a nemusím se obávat, že bych výstup neměl validní.
A jestli si chce chlapec vydelat penize tak at se naucit Fortran a extensivni jazyky pro SQL jako TLC atp., protoze v tom psat nikdo nechce a pritom to vsichni musi pozivat v korporatech :) Tak ci onak power of triforce mluvi jasne....
Fortran je dodnes používaný programovací jazyk, z mého pohledu je lepší a výkonnější než C. Na drcení čísel nic lepšího než Fortran neznám.
SQL bude potřebné vždy.
-
Jak se to tedy dělá bez property to, co není ani elegantní ani přehledné?
Vysvětlení jak se to dělá bez g/s se čeká od Vás :)
Ve výsledku představíte způsob který je identický dobře napsaným g/s, jenom se metody budou jmenovat jinak.
Připomínám že getter/setter != povinnost zpřístupnit private member variables, programátor si tam může napsat libovolně co chce.
Dal by sa uviest priklad? len pre zaujimavost a uplnost
Vždyť jsem to už psal. Nepracovat s atributy objektu, ale s objektem. Nesouvisející atributy rozdělit do více objektů.
-
Fortran je dodnes používaný programovací jazyk, z mého pohledu je lepší a výkonnější než C. Na drcení čísel nic lepšího než Fortran neznám.
Ve fortranu jsem nikdy neprogramoval, můžeš být konkrétnější v čem spočívá výhoda fortranu na výpočetní úlohy?
-
Fortran je dodnes používaný programovací jazyk, z mého pohledu je lepší a výkonnější než C. Na drcení čísel nic lepšího než Fortran neznám.
Ve fortranu jsem nikdy neprogramoval, můžeš být konkrétnější v čem spočívá výhoda fortranu na výpočetní úlohy?
Fortran je o něco výkonnější, než C, pro techniky a vědce má přijatelnější syntaxi. Indexy polí začínají od 1, ale mohou být jakékoli, třeba -10:20 je pole o 31 prvcích začínající indexem -10. Na polích a maticích se přímo dají dělat některé matematické operace, bez cyklů. Z polí a matic se přímo dají dělat výřezy, opět bez cyklů. Pracuje s reálnými i komplexními čísly s volitelnou přesností, pro vědecké výpočty existuje spousta knihoven.
-
To tady fakt nikdo neví, jak elegantně a přehledně pracovat bez nich?
ja to neviem
lebo bez prikladu netusim co chcete vasimi vseobecynmi vyrokmi povedat
urobim robotu za vas
class ucet {
private int zostatok
private osoba majitel
public void zuroc() {
zostatok = zostatok + zlozityVypocet()
}
}
zostatok a majitela natrepete cez konstruktor? k zostatku pristupujete ako?
priklad 3:
class matica {
private int[][] prvky
...
}
ako nastavujete prvky matice?
priklad 2:
ako riesite objekty mapovane na riadky tabulky? cez properties, ktore v php nemate?
class automobil {
private string znacka
private string model
}
kto vam riesi ukladanie dat? automobil ma metodu find a save ako v ruby?
-
Ta otazka evokuje narazky na tototo: Chcem vedit, co mi staci na rutinnej baze, aby to bolo dobre?
Odpoved je nic. Treba byt mimo rutinnej prace a teda byt tvorivy, je jedno v com...
Ktoré profesie nám ukradnú roboty?
16.12.2014
Austrálska správa, ktorá sa zamerala na tamojší priemysel, sa snažila analyzovať, ktorým profesiám hrozí najväčšie riziko automatizácie či rastúce využívanie robotov. Podľa nej budú súperiť s robotmi o zamestnanie najmä účtovníci, pokladníci, sekretári, stenografi či bankári, ale napríklad aj mäsiari. Do zóny ohrozenia sa zaradili aj poštoví úradníci, farmaceuti a lekárnici.
Zo správy vyplýva, že automatizácia nie je obmedzená na pracovné pozície s nízkou kvalifikáciou – austrálski farmaceuti dosahujú bakalársky alebo vyšší titul. „Vyššie vzdelanie teda negarantuje záruku proti automatizácii,“ cituje správu ekonomický portál Business Insider.
Ide najmä o práce, ktoré sú založené na rutinnej báze a ktoré je možné riešiť pomocou algoritmov.
Ako sa presvedčili americké noviny LA Times, roboty sú vhodné aj na písanie automatizovaných správ. Mediálne.sk v marci tohto roka upozornilo, že kedykoľvek v Los Angeles a okolí nastane zemetrasenie, systém nazývaný Quakebot, ktorý naprogramoval jeden z redaktorov novín, dokáže o tom napísať správu.
Pretože ide o robota, ktorý dokáže analyzovať emócie zákazníkov, ich mimiku a tón hlasu, mnohí ho považujú za vhodného adepta, ktorý môže poskytovať zákaznícky servis alebo vykonávať maloobchodný predaj.
S príchodom vyvinutejších počítačov sa potreba ľudskej pracovnej sily výrazne zredukuje v profesiách, ktoré zahŕňajú rutinu. Ide najmä o práce, kde sa vykonávajú obchodné a finančné operácie. Predpokladá sa, že takýmto spôsobom príde o prácu približne sedem miliónov ľudí.
Business Insider upozorňuje, že ak sa všetky dôsledky súvisiace s expanziou technológií, automatizácie a robotiky zhrnú, môže v USA vzniknúť 50-percentná nezamestnanosť. Podnikateľ Martin Ford však predpovedá, že nezamestnanosť sa môže vyšplhať až k 75 percentám. „Väčšina ľudí vykonáva rutinnú prácu. Ľudská ekonomika vždy vyžadovala rutinnú prácu,“ dodáva M. Ford.
http://www.etrend.sk/technologie/ktore-profesie-nam-ukradnu-roboty.html
-
Práca pre priemerných je mŕtva, zvykajte si
23.07.2013
Technológie a globalizácia rozbíjajú trh práce aj vzdelávanie, zároveň však budujú nové príležitosti
Trh práce sa navždy zmenil. Pracovné pozície pre stredne kvalifikovaných zmizli a už sa nikdy nevrátia. Práce bude len na pozíciách pre nekvalifikovaných a pre vzdelaných špecialistov, ktorých záber sa postupom času bude čoraz viac zužovať, povedala profesorka London Business School Lynda Grattonová publiku konferencie Premier Business Leadership (PBLS), ktorú v júni Amsterdame zorganozivala analytická spoločnosť SAS.
L. Grattonová tejto premene na pracovnom trhu pripisuje aj vysokú nezamestnanosť medzi mladými ľuďmi, ktorí po štúdiu v minulosti rozbiehali kariéru práve na pozíciách vyžadujúcich strednú kvalifikáciu.
Ľudia podľa L. Grattonovej potrebujú pochopiť a prijať, že tento druh práce sa nikdy nevráti bez ohľadu na to, čo tvrdia ministri krízou sužovaných vlád. Zároveň musia musieť investovať oveľa viac do svojho vzdelania.
http://www.etrend.sk/ekonomika/praca-pre-priemernych-je-mrtva-zvykajte-si.html
-
class ucet {
private int zostatok
private osoba majitel
public void zuroc() {
zostatok = zostatok + zlozityVypocet()
}
}
zostatok a majitela natrepete cez konstruktor? k zostatku pristupujete ako?
println(ucet);
priklad 3:
class matica {
private int[][] prvky
...
}
ako nastavujete prvky matice?
Do konstruktoru injektuji zdroj dat. Konstruktor si uloží zdroj dat a na povel si je načte nebo si je načte rovnou.
priklad 2:
ako riesite objekty mapovane na riadky tabulky? cez properties, ktore v php nemate?
class automobil {
private string znacka
private string model
}
kto vam riesi ukladanie dat? automobil ma metodu find a save ako v ruby?
Značka a model nejsou atributy, ale objekty. Navíc jsou na sobě závislé - nemůžeš tedy změnit značku a ponechat model.
$automobil->update(new Znacka('Audi', 'A8'));
Tohle sice také vypadá jako setter, ale funguje jinak.
-
println(ucet);
akym magickym sposobom zisti funkcia println() zostatok z uctu?
-------------------------------------------------------------------------------------
Do konstruktoru injektuji zdroj dat. Konstruktor si uloží zdroj dat a na povel si je načte nebo si je načte rovnou.
public class Matica {
private Source source;
public Matica(Source source) {
this.source = source;
}
public int getElementAt(int row, int column) {
return this.source.getElementAt(row, column);
}
}
public class ArraySource implements Source {
private int[][] elements;
public int getElementAt(int row, int column) {
return this.elements[row][column];
}
}
neviem, ci mi nieco uslo, ale som tam, kde som bol, akurat mam odabstrahovany zdroj dat do separatnej triedy, co je jedna vrstva indirekcie (a mozem mat maticu, ktora taha data z nosql databazy, co moze byt trochu overengineering).
datam v privatnych premennych som sa urcite nevyhol.
---------------------------------------
priklad 3
class automobil {
private Znacka znacka
public void update(Znacka znacka) {
....
}
}
aky je, pretty please, rozdiel medzi
public void update(Znacka znacka) {
....
}[/quote]
a
[quote] public void setZnacka(Znacka znacka) {
....
}
[/quote]
okrem toho, ze to "funguje jinak"?
a podme dalej
[quote]public class Znacka {
private String znacka;
private String model;
}[/quote]
takze riesenim problemu je, ze miesto triedy s dvoma instancnymi premennymi, kde mame triedu s jednou instancnou premennou a jednu triedu s dvoma instancnymi premennymi. opat mam dalsiu vrstvu abstrakcie.
a co toto?
[code]
class automobil {
private znacka znacka
private motor motor
}
-
pokazil sa kod, tak este raz
aky je rozdiel medzi
public void update(Znacka znacka) {
....
}
a
public void setZnacka(Znacka znacka) {
....
}
okrem toho, ze to "funguje jinak"?
a podme dalej
public class Znacka {
private String znacka;
private String model;
}
takze riesenim problemu je, ze miesto triedy s dvoma instancnymi premennymi, kde mame triedu s jednou instancnou premennou a jednu triedu s dvoma instancnymi premennymi. opat mam dalsiu vrstvu abstrakcie.
a co toto?
class automobil {
private znacka znacka
private motor motor
}
-
pokazil sa kod, tak este raz
aky je rozdiel medzi
public void update(Znacka znacka) {
....
}
a
public void setZnacka(Znacka znacka) {
....
}
okrem toho, ze to "funguje jinak"?
Ten, že se to už dál netahá po objektech, ale rovnou se to uloží v databázi. Setter by nemohl mít tento postranní efekt. Update to má v popisu práce.
[/quote]
a podme dalej
public class Znacka {
private String znacka;
private String model;
}
takze riesenim problemu je, ze miesto triedy s dvoma instancnymi premennymi, kde mame triedu s jednou instancnou premennou a jednu triedu s dvoma instancnymi premennymi. opat mam dalsiu vrstvu abstrakcie.
a co toto?
class automobil {
private znacka znacka
private motor motor
}
Totéž. Automobil nepotřebuji mít v objektech, když ho mám v databázi.
Vždy je nutné úlohu rozdělit do vrstev a těm přidělit pravomoce. Objektové volání se převede na procedurální úkon pro zapsání do relační databáze. Klasické ORM.
Myslel jsem si, že se mě zeptáš na něco, co se má řešit objektově.
-
Nie je nutné. Ale zas, skriptovacie jazyky sa celkom hodia na rutinné úlohy, keď si potrebuješ predpripraviť data, šablony, čokoľvek iné.
2flame twins (perceptron a Kit): Dobre to robíte chlapi, mladému ste isto silno pmôhli ;).
-
Setter by nemohl mít tento postranní efekt. Update to má v popisu práce.
Lži. Do setteru se může napsat identický kód jako do metody. Jediný rozdíl je v šesti znacích "update" versus devět znaků "setZnacka".
To že máte nějaký interní politický předpis na to že metoda s určitým názvem může pouze něco, je irelevantní.
-
a potom sa rozsypali koralky...
-
Setter by nemohl mít tento postranní efekt. Update to má v popisu práce.
Lži. Do setteru se může napsat identický kód jako do metody. Jediný rozdíl je v šesti znacích "update" versus devět znaků "setZnacka".
To že máte nějaký interní politický předpis na to že metoda s určitým názvem může pouze něco, je irelevantní.
Asi by se ti líbil zápis
$automobil->setZnacka(new Znacka('Audi', 'A8'));Takže $automobil bude mít rozšířené rozhraní o další metodu setZnačka(). Když budu změnit barvu, tak do rozhraní přidám další zbytečnou metodu setBarva()?
Když budu mít v rozhraní třídy objektu $automobil metodu
function update(Updatable $objekt) {
$objekt->update($db);
}tak pokryji všechny změny jednou metodou, ve které jen zavolám update a je to. Ví, co má uložit a kam to má uložit. Všechny objekty jsou privátní. Kde vidíš nějaký setter? Nebo si snad myslíš, že databázi ukládám do auta?
-
Nekdy je lepsi update, nekdy setter, resite tu malichernosti ale to je uz udelem vasich zivotu....
-
Podla mojho nazoru je jedno, aky jazyk sa naucis. Casom ich budes pouzivat viac a vsetko budes vidiet abstraktnejsie. Jazyk sa ti stane prostriedkom, ako dosiahnut urcity ciel. Preto, ak ta ucitel tlaci do PHP, nauc sa PHP. S inymi jazykmi by si si to len komplikoval. Po par rokoch uz nebudes vidiet az taky rozdiel a budes switchovat syntax, aj ked priznavam, ze zo zaciatku to bolo tazke.
Domenovo-specificke veci je vzdy lepsie nechat spravit domenovym specialistom a hlavne navrhnut ich advisovat aby spravili dobry interface! Mozes sa pustat aj tymto smerom, ale podla mna je to zahrabanie sa do nizko-urovnovych veci a neviem ci by si bol pouzitelny stale ako programator po X rokoch.
M.
Zdravím,
chodím na jednu SŠ se zaměřením na Informační technologie - Počítačové sítě a programování. Vzhledem k nabídkám práce a poptávce po programotárech. Jak moc důležitá je znalost webového programování v dnešní době a zároveň také pro budoucnost? Učitel do nás rve za každou cenu PHP, ale já v tom moc perspektivu nevidím. Jaký je na to Váš názor? Já spíše preferuji jazyky jako je C/C++ a Java. Jsem ve fázi takové, že hledám něco, čeho bych se měl opravdu chytnout, abych se uplatnil. Dnes to s prací není jednoduché a můj názor je, že dnes dělá weby téměř každý. Opravdu bych rád znal názor veřejnosti.
Díky. :)
-
ja uz zacinam tusit ducha kitovej architektury :-) to bude tymi prikladmi!
entity, ktore zmene atributov rovno updatuju databazu. takze ten setter-update vola nejaku metodu, tak rovno v nej sa vykonaju sql dopyty. prakticky activerecord styl (ma $automobil findbyid()?).
$automobil->setZnacka(new Znacka('Audi', 'A8'));
predpokladam, ze setZnacka() vola nejaky externy objekt, ktory ma metody s realnou pracou s databazou (teda nejaky orm)
----------
v jave je to pretocene, tam je entita len kontajner na data. neimplementuje ziadne specialne rozhranie, necakaju sa od automobilu ziadne metody typu update() alebo findById(), to riesi externa trieda
takze v jave je to typicky
automobil.setZnacka(new Znacka('Audi', 'A8'));automobilRepository.saveOrUpdate(automobil)
ano, je to anemicky styl a ano, fowler na to strasne nadava, ale
1. v jave je to cele o datach, ktore tecu cez vrstvy, ale realne oni na webe tecu aj tak: v takom angulari tecu data z widgetov do controllerov cez jsony do mvc controllera na serveri, ktory to zvaliduje, posunie do servicu, ktory to spracuje, posunie do perzistencie a ta posunie do databazy.
2. je to dominantny styl, ktory funguje.
3. technicke dovody nepustia (je tazke urobit dependency injection ORM do entity a ak to aj spravite, je tazke potom ten ORM mockovat v unit testoch a teda predpokladam, ze unit testy kit pise)
4. kyvadlo ide od objektovo orientovanych veci naspat k mentalite "tu je procedura / webservice / rest api" a "tu su spravy, co medzi nimi tecu". ... pretoze skalovanie nepusti
-
ja uz zacinam tusit ducha kitovej architektury :-) to bude tymi prikladmi!
entity, ktore zmene atributov rovno updatuju databazu. takze ten setter-update vola nejaku metodu, tak rovno v nej sa vykonaju sql dopyty. prakticky activerecord styl (ma $automobil findbyid()?).
Vypadá to následovně:
$automobil->update(new AutoZnacka('Audi', 'A8'));Objekt $automobil má metodu update():
function update(Updatable $objekt) {
$objekt->update($this->db, $this->id);
}
a pak je tu ještě třída AutoZnacka, která je v servisní vrstvě:
class AutoZnacka implements Updatable {
private $znacka;
private $typ;
function __construct($znacka, $typ) {
$this->znacka = $znacka;
$this->typ = $typ;
}
function update(MyPDO $db, $id) {
$update = $db->prepare('UPDATE automobil SET znacka=?, typ=? WHERE id=?');
$update->execute(array($this->znacka, $this->typ, $id));
}
}
Trochu jsem to zjednodušil, aby byl pochopitelný princip. Namespace a ošetření výjimek si tam snad každý dodělá podle svých potřeb.
-
class AutoZnacka implements Updatable {
private $znacka;
private $typ;
function __construct($znacka, $typ) {
$this->znacka = $znacka;
$this->typ = $typ;
}
function update(MyPDO $db, $id) {
$update = $db->prepare('UPDATE automobil SET znacka=?, typ=? WHERE id=?');
$update->execute(array($this->znacka, $this->typ, $id));
}
}
Trochu jsem to zjednodušil, aby byl pochopitelný princip. Namespace a ošetření výjimek si tam snad každý dodělá podle svých potřeb.
Jde získat např. hodnotu $znacka? Mj. není ten kód AutoZnacka boilerplate?
-
ja mam pocit, ze ten priklad je blby^wzjednoduseny ze popiera pointu
function update(Updatable $objekt) {
$objekt->update($this->db, $this->id);
}
lebo potom auto, ktore updatuje autoznacku, v skutocnosti to prehodi na volanie na autoznacku, ktora updatuje automobil..., co je, ako vravi pan Micek, dost boilerplatovo.
ak by to bolo mapovanie, ze co tabulka, to Updatable entita, tak aj tak mi z toho ide hlava kolem
ak autoznacka nesie Audi a A8, preco ma vediet o konkretnych autach, ktore ma updatnut? ak teda predpokladam, ze znacky su v nejakom ciselniku
dalsia vec je, ze takto neurobite unit testy, co je epic fail
-
... lebo potom auto, ktore updatuje autoznacku, v skutocnosti to prehodi na volanie na autoznacku, ktora updatuje automobil..., co je, ako vravi pan Micek, dost boilerplatovo.
AutoZnacka updatuje pouze značku auta. Nevidím v tom boilerplate.
ak by to bolo mapovanie, ze co tabulka, to Updatable entita, tak aj tak mi z toho ide hlava kolem
Co doména, to Updatable. Entity jsou pohromadě, nevidím v tom problém.
ak autoznacka nesie Audi a A8, preco ma vediet o konkretnych autach, ktore ma updatnut? ak teda predpokladam, ze znacky su v nejakom ciselniku
Také bych to tak nedělal. V zadání byla doména Automobil se dvěma atributy: značka a typ. Tak jsem to napsal podle toho.
dalsia vec je, ze takto neurobite unit testy, co je epic fail
Dělal jsem to právě kvůli tomu, aby se mi dobře psaly unit testy. Proč by nešly udělat? Epic fail se nekoná.
-
Jde získat např. hodnotu $znacka? Mj. není ten kód AutoZnacka boilerplate?
K čemu by mi měla být hodnota $znacka vytržená z kontextu?
-
Jde získat např. hodnotu $znacka? Mj. není ten kód AutoZnacka boilerplate?
K čemu by mi měla být hodnota $znacka vytržená z kontextu?
Ne vždy je kontext třeba. Co když chci značku vypsat nebo se zeptat nějaké služby, zda je auto kradené, to vše pak implementuji přímo do AutoZnacka?
AutoZnacka updatuje pouze značku auta. Nevidím v tom boilerplate.
No právě, skoro nic to nedělá a je toho 10 řádků. V tom příkladu je jediná zajímavá informace SQL dotaz, ostatní z něj lze odvodit, tudíž to ostatní je zbytečné.
-
Jde získat např. hodnotu $znacka? Mj. není ten kód AutoZnacka boilerplate?
K čemu by mi měla být hodnota $znacka vytržená z kontextu?
Ne vždy je kontext třeba. Co když chci značku vypsat nebo se zeptat nějaké služby, zda je auto kradené, to vše pak implementuji přímo do AutoZnacka?
AutoZnacka je doména, která v tomto modelovém případě pracuje s dvojicí atributů $znacka a $typ. Dostanu tedy celou dvojici jako objekt nebo zúžím doménu.
AutoZnacka updatuje pouze značku auta. Nevidím v tom boilerplate.
No právě, skoro nic to nedělá a je toho 10 řádků. V tom příkladu je jediná zajímavá informace SQL dotaz, ostatní z něj lze odvodit, tudíž to ostatní je zbytečné.
SRP. Je to pouze příklad, jak stavím větší projekty. Pokud bych měl v modelu jen jednu doménu, tak se bez tohoto postupu obejdu. Kdybych to dělal s gettery a settery, tak tam těch 10 řádků bude také, ale bude to namačkáno do modelu, bude to mít debilní názvy a nebude to mít doménovou logiku.
-
SRP. Je to pouze příklad, jak stavím větší projekty. Pokud bych měl v modelu jen jednu doménu, tak se bez tohoto postupu obejdu. Kdybych to dělal s gettery a settery, tak tam těch 10 řádků bude také, ale bude to namačkáno do modelu, bude to mít debilní názvy a nebude to mít doménovou logiku.
SRP? Jenže tahle třída dělá 3 věci: drží data, validuje data, zapisuje data do databáze. Osobně bych se snažil tohle všechno oddělit.
-
SRP? Jenže tahle třída dělá 3 věci: drží data, validuje data, zapisuje data do databáze. Osobně bych se snažil tohle všechno oddělit.
Objekt drží jen data, která má držet. Každá metoda dělá jen jednu věc. SRP.
-
SRP? Jenže tahle třída dělá 3 věci: drží data, validuje data, zapisuje data do databáze. Osobně bych se snažil tohle všechno oddělit.
Objekt drží jen data, která má držet. Každá metoda dělá jen jednu věc. SRP.
Ale vše je splácané dohromady. Když budu chtít změnit např. validaci, tak musím přepsat celou třídu, ne? (Vycházím z toho, že atributy $znacka a $typ jsou privátní, takže k nim nejde přistupovat z vnějšku a ani z podtřídy.)
-
Objekt drží jen data, která má držet. Každá metoda dělá jen jednu věc. SRP.
Ale vše je splácané dohromady. Když budu chtít změnit např. validaci, tak musím přepsat celou třídu, ne? (Vycházím z toho, že atributy $znacka a $typ jsou privátní, takže k nim nejde přistupovat z vnějšku a ani z podtřídy.)
[/quote]
Validace se přece týká této konkrétní třídy. Proč bych při změně způsobu validace měl přepisovat jinou třídu než tuto? Kterou jinou třídu bych podle tebe měl při změně způsobu validace přepisovat? Takovou, která se značkou auta nijak nesouvisí?
-
Validace se přece týká této konkrétní třídy. Proč bych při změně způsobu validace měl přepisovat jinou třídu než tuto? Kterou jinou třídu bych podle tebe měl při změně způsobu validace přepisovat? Takovou, která se značkou auta nijak nesouvisí?
Chtěl bych využít kód z této třídy (držení dat nebo ukládání do databáze), ale s jinou validací. Tím, že to smícháte dohromady, ztrácíte znovupoužitelnost kódu. Např.:
- Různé části kódu mohou provádět validaci jinak - nové značky budu validovat jinak než ty staré (tj. validace při vkládání se liší od validace při editaci) nebo administrátor má možnost zadat nevalidní značku.
- Pokud třída nebude závislá na databázi, mohu ji použít i v klientském kódu (pokud jazyk umí kompilovat do JS).
- V jiné aplikaci může mít značka nějaké atributy navíc, ale validaci pro shodné atributy mohou oba systémy sdílet.
-
Validace se přece týká této konkrétní třídy. Proč bych při změně způsobu validace měl přepisovat jinou třídu než tuto? Kterou jinou třídu bych podle tebe měl při změně způsobu validace přepisovat? Takovou, která se značkou auta nijak nesouvisí?
Chtěl bych využít kód z této třídy (držení dat nebo ukládání do databáze), ale s jinou validací. Tím, že to smícháte dohromady, ztrácíte znovupoužitelnost kódu. Např.:
- Různé části kódu mohou provádět validaci jinak - nové značky budu validovat jinak než ty staré (tj. validace při vkládání se liší od validace při editaci) nebo administrátor má možnost zadat nevalidní značku.
- Pokud třída nebude závislá na databázi, mohu ji použít i v klientském kódu (pokud jazyk umí kompilovat do JS).
- V jiné aplikaci může mít značka nějaké atributy navíc, ale validaci pro shodné atributy mohou oba systémy sdílet.
- Pokud se jedná o jinou validaci, jedná se zřejmě o jinou doménu.
- Pokud se jedná o jiná validační pravidla, tak ta se mohou injektovat v konstruktoru, jinak default.
- Tato třída je použitelná nezávisle na databázi. Podívej se pořádně.
- Validační pravidla mám v databázi. Není problém je zkompilovat do JS.
- Mé třídy jsou znovupoužitelné právě proto, že dodržuji SRP.
- Podle tvých pravidel prakticky každá třída porušuje SRP. Ta, která ho podle tebe neporušuje, je k ničemu.
- Neodpověděl jsi na otázku, kterou třídu bych měl při změně způsobu validace přepisovat. Všechny, které dělají validaci? Je lepší opravit jednu třídu, než hledat v celé aplikaci, kde všude je použita.
-
Mé třídy jsou znovupoužitelné právě proto, že dodržuji SRP.
Právě, že ten váš kód znovupoužitelný není a není ani modulární - nemohu vzít část funkcionality a jednoduše ji použít nebo nahradit, mohu s tím pracovat pouze jako s celkem.
Neodpověděl jsi na otázku, kterou třídu bych měl při změně způsobu validace přepisovat. Všechny, které dělají validaci? Je lepší opravit jednu třídu, než hledat v celé aplikaci, kde všude je použita.
Ve Scale bych to řešil zhruba takhle:
// Pouze drží data (validní i nevalidní).
case class AutoZnacka(typ: String, znacka: String)
// Obsahuje standardní kód pro ukládání do databáze i pro validaci.
// Na jeho vygenerování si lze napsat makro.
object AutoZnacka {
implicit val u = Updatable.fromFunction[AutoZnacka] { (x, db) =>
/* TODO */
}
implicit val v = Validation.fromFunction[AutoZnacka] { x =>
/* TODO */
}
}
Všimněte si, že validace i ukládání do repository je zvlášť a uživatel to může snadno předefinovat nebo použít v jiném kódu. Abych odpověděl na otázku, tak při změně způsobu validace stačí napsat
implicit val autoZnackaValidation = /* TODO */
Například potřebujete-li v administrační sekci jinou validaci, uděláte trait
trait AdminValidation {
implicit val autoZnackaValidation = /* TODO */
}
a ten pak namixujete, kde je to třeba
class SomeController extends Controller with AdminValidation {
/* TODO */
}
-
Já jsem se uplatnil a PHP jsem nikdy neuměl. Tolik k tématu.
-
Ve Scale bych to řešil zhruba takhle:
Scala není PHP. Na znovunepoužitelnost si nehraji. Spousta se toho nakecá, ale když se nějaká třída má použít znovu, použitelná není.
Podle tebe každá anemická třída porušuje SRP. Má v sobě data, getter a setter. To jsou 3 komponenty. Kde je SRP?
Data a příslušné metody mají být pohromadě. Teprve pak je to OOP.
Repository je antipattern.
-
Data a příslušné metody mají být pohromadě. Teprve pak je to OOP.
Definujte, co je podle vás OOP? Pokud stačí, že data a funkce jsou pohromadě, pak je i záznam, jenž obsahuje data a funkce OOP? Např.
type Ctverec =
{ A : int
Nakresli : unit -> unit }
Podle tebe každá anemická třída porušuje SRP. Má v sobě data, getter a setter. To jsou 3 komponenty. Kde je SRP?
Ne, neporušuje, stále se stará o jednu věc, o držení dat.
Scala není PHP. Na znovunepoužitelnost si nehraji.
Ano, v PHP nemáte typové třídy, ani implicity, takže to nemůžete takhle snadno oddělit od sebe. Proto si myslím, že na programovacím jazyku dost záleží.
-
Podle tebe každá anemická třída porušuje SRP. Má v sobě data, getter a setter. To jsou 3 komponenty. Kde je SRP?
Ne, neporušuje, stále se stará o jednu věc, o držení dat.
- držení dat
- nastavení dat
- získávání dat
To jsou 3 komponenty, které mohou existovat nezávisle na sobě.
-
- držení dat
- nastavení dat
- získávání dat
To jsou 3 komponenty, které mohou existovat nezávisle na sobě.
Mohou, ale nemám pocit, že by to porušovalo SRP, stále tam jde o držení dat.
Mj. v mém příkladě žádný setter ani getter není (alespoň ne z pohledu uživatele jazyka, z pohledu bajtkódu ano).
-
- držení dat
- nastavení dat
- získávání dat
To jsou 3 komponenty, které mohou existovat nezávisle na sobě.
Mohou, ale nemám pocit, že by to porušovalo SRP, stále tam jde o držení dat.
Nejen držení dat, ale i jejich modifikace a zjišťování stavu. Můžeš mít 3 důvody, proč modifikovat třídu.
Gettery a settery navíc porušují zapouzdření objektu, takže by se ani z tohoto důvodu neměly používat.
Kdyby se SRP mělo dodržovat striktně, třída by mohla mít v sobě jeden atribut, jeden getter, jeden setter nebo jednu metodu. To by byl samozřejmě nesmysl. SRP není striktní dogma, ale pomůcka při rozhodování, jak uspořádat kód programu. Pokud má běžná třída 2-4 souvisejících atributů a k nim 5-10 nepříliš složitých metod, které s nimi pracují, obvykle SRP neporušuje.
-
Gettery a settery navíc porušují zapouzdření objektu, takže by se ani z tohoto důvodu neměly používat.
To je nesmysl. Zapouzdření by bylo např. porušeno, kdybych zvenku přistupoval k privátním fieldům objektu přímo.
Nejen držení dat, ale i jejich modifikace a zjišťování stavu. Můžeš mít 3 důvody, proč modifikovat třídu.
Mám jen jeden důvod, a to když se změní data, jenž chci držet. U anemické třídy přeci neměním getter nebo setter nezávisle, aniž by se změnila data, jenž ta třída má držet.
-
Gettery a settery navíc porušují zapouzdření objektu, takže by se ani z tohoto důvodu neměly používat.
To je nesmysl. Zapouzdření by bylo např. porušeno, kdybych zvenku přistupoval k privátním fieldům objektu přímo.
V reálu to vypadá stejně a také funkčnost je prakticky stejná. V C# se to liší velikostí písmene, v PHP se to neliší vůbec. Je otevřené další rozhraní zvenku do objektu, zapouzdření je porušeno. Přimhouříme oko a prohlásíme, že porušeno není.
Nejen držení dat, ale i jejich modifikace a zjišťování stavu. Můžeš mít 3 důvody, proč modifikovat třídu.
Mám jen jeden důvod, a to když se změní data, jenž chci držet. U anemické třídy přeci neměním getter nebo setter nezávisle, aniž by se změnila data, jenž ta třída má držet.
Anemické třídy raději obhajovat nebudeme, že?
- Změním typ atributu. Musím změnit getter i setter
- Změním typ vstupní hodnoty. Musím změnit setter
- Změním typ výstupní hodnoty. Musím změnit getter
Tři různé požadavky, tři změny. SRP se v principu nekoná, ale opět přimhouříme oko a řekneme, že to SRP vyhovuje.
-
V reálu to vypadá stejně a také funkčnost je prakticky stejná. V C# se to liší velikostí písmene, v PHP se to neliší vůbec. Je otevřené další rozhraní zvenku do objektu, zapouzdření je porušeno. Přimhouříme oko a prohlásíme, že porušeno není.
Ne, není potřeba přivírat oči, je to naprosto korektní. Podívejte se, jak je zapouzdření formalizováno - nejjednodušší je to na modulech (http://www.seas.harvard.edu/courses/cs152/2014sp/lectures/lec17-existential.pdf), těžší pak na objektech (http://www.cs.cornell.edu/courses/CS6110/2013sp/lectures/lec37-sp13.pdf), a uvidíte, že se nic neporušilo. Ve zkratce: před vnějším světem se schová (zapouzdří) část objektu (v odkazovaných materiálech pomocí existenciálních typů) a vnější svět přistupuje pouze k neschovaným částem, přičemž gettery ani settery to nijak nenarušují.
- Změním typ atributu. Musím změnit getter i setter
- Změním typ vstupní hodnoty. Musím změnit setter
- Změním typ výstupní hodnoty. Musím změnit getter
Tři různé požadavky, tři změny. SRP se v principu nekoná, ale opět přimhouříme oko a řekneme, že to SRP vyhovuje.
Ta třída má jen jednu odpovědnost a to držení dat. Gettery a settery slouží k tomu, abychom v té třídě ta data mohli držet. Mj. můžete si představit třeba automaticky implementované vlastnosti v F# nebo C#, kde ten typ je pouze na jednom místě.
Anemické třídy raději obhajovat nebudeme, že?
Ale ano. Ve funckionálních jazycích, i moderních OO jazycích jako je Scala a F# se to normálně používá a je to užitečné (viz třeba můj příklad). Navíc o přidání podpory pro anemické třídy (https://onedrive.live.com/view.aspx?resid=4558A04E77D0CF5!5396&app=Word) uvažoval i C# - př.:
abstract class Expr;
record class X() : Expr;
record class Const(double Value) : Expr;
record class Add(Expr Left, Expr Right) : Expr;
record class Mult(Expr Left, Expr Right) : Expr;
record class Neg(Expr Value) : Expr;
-
Scala není PHP. Na znovunepoužitelnost si nehraji. Spousta se toho nakecá, ale když se nějaká třída má použít znovu, použitelná není.
aby sme neblabolili o tom, ze vy mate vlastnu definiciu oop, vlastnu definiciu srp a vlastnu definiciu zapuzdrenosti, ktora vam sedi do kramu...
co s tymi unit testami? napr. ste v stave vo vasej architekture mocknut kod pre vkladanie do databazy? (pytal som sa viackrat)
prave na unit testoch sa ukaze prisposobitelnost a znovupouzitelnost classov (a napr. anemicky model je jednym z prikladov, ked to mockovat viete radostne)
Gettery a settery navíc porušují zapouzdření objektu, takže by se ani z tohoto důvodu neměly používat.
jo, ked uz kolega umne spomenul scalu: co takto immutable classy, data pchane cez konstruktor?