Jak je to dneska s Javou? – Java – Fórum – Programujte.com
 x   TIP: Přetáhni ikonu na hlavní panel pro připnutí webu
Reklama
Reklama

Jak je to dneska s Javou? – Java – Fórum – Programujte.comJak je to dneska s Javou? – Java – Fórum – Programujte.com

 

Hledá se programátor! Plat 1 800 € + bonusy (firma Boxmol.com)
JK
~ Anonymní uživatel
20 příspěvků
25. 6. 2014   #1
-
0
-

Jsem student 4. ročníku IT a tak nějak jsem vyzkoušel už pár jazyků a to co tu píšu je jednak můj názor, druhak si chci popovídat a zeptat se zkušenějších.

Co si myslíte o současné pozici Javy a její budoucnosti?

Dost se tlačí do popředí C# a .NET celkově. Mí spolužáci i já jsme měli na škole Javu i C# a oblibu sí získal C#. Co se Javy týče, je to moje oblíbená platforma, ikdyž .NET je propracovaný řekl bych lépe a programování je komfortnější. Co ale .NET nebude podle mě nikdy pořádně zahrnovat, je multiplatformní nasazení. ALE! Vzhledem k tomu, že Microsoft se docela dobře probil s Win Phone do mobilních technologií a předpokládám, že s postupem času začne válcovat Android a vzhledem k tomu, že nějáký ten pátek už nejsou Java aplikace pro mobily aktuální (a pochybuju, že se to do budoucna už zlepší), předpokládal bych ještě větší rozmach .NETu na úkor Javy. Navíc, ani u Androidu už pokud vím není předinstalován JVM.

Teď další věc a to je ona multiplatformnost Javy. Vim, že ještě před pár lety jsem u pár elektronických zařízení viděl soft. který byl napsán v Javě. Jenomže: dneska už hardware pokročil a na různých elektronických zařízeních není důvod pro to, aby tam neběžel třeba normálně Linux, či RT Linux. V tom případě moc nechápu význam toho, proč by se pro takovéto zařízení měla psát řídící aplikace v Javě namísto třeba v C/C++. Co se desktopových aplikací týče, ty, které by měly být spustitelné na Winech i na Linuxu, mohou být klidně napsány v C++ za použití třeba Qt++.

Celkově si Javu umím představit spíše pro psaní minoritně zaměřených aplikací, jako jsou různé utility, u kterých se očekává spustitelnost na různých platformách; jako třeba různé pomůcky pro výuku, vykreslování grafů, různé specializované kalkulačky, atd.

Prostě závěrem, příjde mi, že Java se postupně stává spíše minoritní vývojovou platformou.

Váš názor? :-)

Nahlásit jako SPAM
IP: 90.179.206.–
Reklama
Reklama
Flowy0
Věrný člen
25. 6. 2014   #2
-
+1
-
Zajímavé
Kit +

na androide nikdy nebezal JVM (aspon nie defaultne a verejne) ... sice pouziva syntax javy ale prostredie (sprava objektov ... garbage collector a podobne drobnosti) ma vlastne (dalvik a teraz art)

ak pises aplikaciu pre jednoduche zariadenie tak najrychlejsie riesenie bude v assemblery ... C je v podstate len krajsi assembler ... ak pouzijes C++ tak to mas nieco medzi rychlostou C a kvalitou OOP (nehovorim ze C++ nemoze mat kvalitne OOP programy ale podla mna je moc zlozite pre jednoduche veci)

urcite je vyhodne si zvykat na OOP pretoze to ma lepsiu buducnost ako cisto strukturovane algoritmy ... ci uz to budes robit v jave alebo .net/C# je na tebe v podstate budes robit aj tak to iste a ak ovladas teoriu toho co robis tak nemas problem prejst na inu platformu ... z velkej casti je to len ina syntax

vyhoda javy je ze ma kvalitne spracovane prostredie pre web (J2EE) a s jednotlivymi 'frameworkami' (hlavne je daleko so standardmi) je na tom velmi pekne (sice to chce trochu ucenia ale JPA a EJB su velmi pekne principy a zrychlia pracu mnohim) ... ak chces pisat aplikacie ktore bezia lokalne tak vecsinou najdes lepsie riesenie ako je java ale napisat aplikaciu pre server a potom ju len trochu pozmenit (samozrejme kod je rozny ale principy su rovnake a nemusis riesit prechod medzi listom a array v C++) aby fungovala na klientovy ma svoje caro

pre priklad mnozstvo aplikacii pre web sa pise v php ... profesionalne stranky sa robia v jave ... viem ze aj .net ma nejake baliky pre pracu s webom ale este som nevidel zeby bol vo velkom pouzivany (hoci som nehladal)

Nahlásit jako SPAM
IP: 84.47.11.–
https://github.com/Flowy
Kit+11
Guru
25. 6. 2014   #3
-
-2
-
Mimo téma

#1 JK
Nevím, co je na C# komfortnějšího než na Javě. Podle mne jen to, že se v něm snáze prasekóduje. Jinak jsou ty jazyky hodně podobné a dohromady si nemají co vyčítat.

Jazyky C/C++ jsou nízko- až středněúrovňové. Na ovladače dobré, ale nezvládají vyšší úroveň abstrakce OOP. Je nutné vybrat C#, Javu, Python nebo třeba Javascript.

Kromě toho jsem poměrně alergický na příponu .exe, takže programy napsané v C# to mají u mne těžké. Pokud vím, žádný program napsaný v C# momentálně nepoužívám.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
25. 6. 2014   #4
-
+2
-
Zajímavé
Kit +

osobne si myslim ze java a .NET (konkretne C#)  maji oba dva budoucnout pro nasledujici roky. osobne preferuji .NET protoze aktualni pristup MS k .NET je skvely. tento rok byl na konferenci BUILD predstaven jak prekladac roslyn (opensource prekladac .net) tak tzv. .NET foundation coz je prakticky to ze hodne MS frameworku ktere byly privatni jsou nyni opensource. diky technologii mono je mozne rozjet .net i na dalsich platformach jako linux, mac a dalsi. Komercne je zde treba Xamarin ktery umoznuje vytvaret aplikace v C# a provozovat tyto aplikace na Androidu i iOS (nativne). co se tyka webu tak asp je mnohem vice rozsirene nez java (http://trends.builtwith.com/framework).

dale pokud se podivas na pocet pracovnich prilezitosti (globalne i pro cz) tak je je to vyrovnane.

Nahlásit jako SPAM
IP: 77.92.213.–
Satik0
Stálý člen
26. 6. 2014   #5
-
-1
-
Mimo téma
Kit -

Také jsem si všiml, že nejen já, ale i pár lidí v okolí programuje raději v C# než v Javě - prostě se mi v C# programuje o něco pohodlněji než v Javě - nevím ani, jestli je to vývojovým prostředím, těmi rozdíly v jazycích nebo tím, že .NET je na Windows nativnější než JVM (takže běží nativně na více počítačích).

Nevím, co je na C# komfortnějšího než na Javě. Podle mne jen to, že se v něm snáze prasekóduje.

- Prasekódovat se dá v obou jazycích stejně, nemyslím, že by na tom bylo C# nějak hůře v tomhle ohledu.

Jazyky C/C++ jsou nízko- až středněúrovňové. Na ovladače dobré, ale nezvládají vyšší úroveň abstrakce OOP.

- C jako takové OOP neumí, ale u C++ nesouhlasím - C++ umí (co se týče OOP) v podstatě to samé, co C# nebo Java - v některých směrech více (šablony, dědění od více tříd, ...) a v některých méně (RTTI, reflexe, ...).

Nahlásit jako SPAM
IP: 86.49.188.–
Kit+11
Guru
26. 6. 2014   #6
-
0
-

#5 Satik
Součástí prasekódu jsou i nadbytečné gettery a settery. C# to velmi usnadňuje.

C++ umí toho ohledně OOP mnohem méně, než C#. C++ je v podstatě imperativní jazyk s některými vlastnostmi z OOP. Šablony ani dědění více tříd do OOP nepatří.

Nahlásit jako SPAM
IP: 147.229.242.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Satik0
Stálý člen
26. 6. 2014   #7
-
0
-

#6 Kit
Co z OOP tedy C++ neumí oproti C# / Javě ? :)

Nahlásit jako SPAM
IP: 86.49.188.–
Kit+11
Guru
26. 6. 2014   #8
-
0
-

#7 Satik
Ptal jsem se dřív :-)

C++ neumí (bez doplňků) zlikvidovat objekt, na který nevede odkaz - programátor se o to musí postarat sám. To značně ovlivňuje programátora, který na to musí myslet a přizpůsobovat tomu kód - jinak dochází k memory leakům. Tím se vzdaluje od OOP.

Nahlásit jako SPAM
IP: 147.229.242.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
KIIV+42
God of flame
26. 6. 2014   #9
-
0
-

#8 Kit
takze ti chybi garbage collector pro dynamicky alokovane objekty

me chybi v jave pretezovani metod (ale proc to nechtelo jet sem nestudoval - tusim fachal jen konstruktor),

destruktory tam taky nejsou

Nahlásit jako SPAM
IP: 62.168.56.–
Program vždy dělá to co naprogramujete, ne to co chcete...
Satik0
Stálý člen
26. 6. 2014   #10
-
0
-

#8 Kit

Ptal jsem se dřív :-)

- Na co jsi se ptal? Nikde žádnou otázku nevidím :)

C++ umí toho ohledně OOP mnohem méně, než C#

C++ neumí (bez doplňků) zlikvidovat objekt, na který nevede odkaz - programátor se o to musí postarat sám. To značně ovlivňuje programátora, který na to musí myslet a přizpůsobovat tomu kód - jinak dochází k memory leakům. Tím se vzdaluje od OOP.

Že toho C++ ohledně OOP umí "mnohem méně" je tedy v tom, že má jiný memory management, což se vlastně OOP skoro netýká? Navíc si v C++ můžeš přece vybrat - je možné psát managed kód a nechat to za tebe řešit GC, případně můžeš používat smartpointery, pokud si po sobě nechceš uklízet sám.

Zajímaly by mě ty ostatní rozdíly, co C++ ohledně OOP neumí :)

Nahlásit jako SPAM
IP: 86.49.188.–
Kit+11
Guru
26. 6. 2014   #11
-
0
-

#9 KIIV
OOP bez GC je podle mne prostě nedodělek.

Přetěžování metod funguje v Javě úplně normálně a běžně ho používám.

Destruktory nejsou ani v C#, takže v tomhle ohledu si C# a Java nemají co vyčítat. Destruktory C++ fungují explicitně, což také není zrovna nejlepší řešení.

Nahlásit jako SPAM
IP: 147.229.242.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Satik0
Stálý člen
26. 6. 2014   #12
-
0
-
Nahlásit jako SPAM
IP: 86.49.188.–
Kit+11
Guru
26. 6. 2014   #13
-
0
-

#12 Satik
To je jen parodie na destruktor, protože se spouští až při aktivaci GC. Když v takovém destruktoru budeš zavírat otevřený soubor, tak se ti zavře příliš pozdě. Mezitím se ti může vyčerpat banka volných deskriptorů a aplikace spadne. Destruktor se musí spustit už při ukončení platnosti objektu.

Nahlásit jako SPAM
IP: 147.229.242.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Satik0
Stálý člen
26. 6. 2014   #14
-
0
-

#13 Kit
Slyšel jsi o kosntrukci using () ?

Nahlásit jako SPAM
IP: 86.49.188.–
Kit+11
Guru
26. 6. 2014   #15
-
0
-

#14 Satik
Ano, tato konstrukce je v Javě 7.

Zavření souboru byl jen příklad toho, že když chci něco zavolat při zániku platnosti objektu, nemohu se v C# ani v Javě spolehnout na destruktor.

Nahlásit jako SPAM
IP: 147.229.242.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Satik0
Stálý člen
26. 6. 2014   #16
-
0
-

#15 Kit
C# to má už od počátku.

Zavření souboru byl jen příklad toho, že když chci něco zavolat při zániku platnosti objektu, nemohu se v C# ani v Javě spolehnout na destruktor.

V C# můžeš.

Použitím konstrukce using - objekt je platný jen uvnitř téhle konstrukce. V destruktoru se obvykle jen volá metoda Dispose(), ve které máš napsané třeba to zavření souboru. Pak se ti to zavolá na konci toho bloku using.

EDIT: Ale to jsme trochu odbočili, co tedy v C++ kromě memory managementu podle tebe nevyhovuje OOP v porovnání s Javou a C#?

Nahlásit jako SPAM
IP: 86.49.188.–
KIIV+42
God of flame
26. 6. 2014   #17
-
0
-

#11 Kit
jak to myslis explicitne? zavolas delete, nebo staticky objekt vyleze out of scope a mas to tam.. RAII rules them all :D

GC v c++ neni jen proto, ze se jeste nedohodli jaky tam dat... a bohate na to staci ten shared pointer...

spis sem mel v jave problem najit neco, co by odpovidalo poli 8bitovejch neznamenkovejch integeru :D

Nahlásit jako SPAM
IP: 62.168.56.–
Program vždy dělá to co naprogramujete, ne to co chcete...
Satik0
Stálý člen
26. 6. 2014   #18
-
0
-

#17 KIIV
V Jave neznamenkova cisla nejsou :) 

Nahlásit jako SPAM
IP: 86.49.188.–
Kit+11
Guru
26. 6. 2014   #19
-
0
-

#17 KIIV
Delete je explicitně. Implicitně je opuštěním bloku "out of scope".

Pole v OOP moc uplatnění nemá, Flyweight se používá spíš u nižšího levelu, kde se hledí na výkon a dělají se nejrůznější optimalizace. K čemu potřebuješ osmibitový integer bez znaménka?

Nahlásit jako SPAM
IP: 147.229.242.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Kit+11
Guru
26. 6. 2014   #20
-
0
-

#18 Satik
V Jave neznamenkova cisla nejsou :)

... aby je programátoři nepoužívali a nesnažili se optimalizovat kolo.

Nahlásit jako SPAM
IP: 147.229.242.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
KIIV+42
God of flame
26. 6. 2014   #21
-
+1
-
Zajímavé

#19 Kit
uz si ani nepamatuju.. zdalo se mi zbytecne plytvat na pole hodnot 0-255 polem 4B integeru na kazdy (a kdyz se pouzije Integer, tak jsou to vlastne jen reference a pamet je zase nekde rozesseta)

ale je to formalita na urovni neexistujiciho jednotneho gc v C++ - proste se pocita, ze java bude zabirat spoustu ramky jen tak

kazdopadne parser binarnich dat bych v jave delat teda nechtel :D

Nahlásit jako SPAM
IP: 62.168.56.–
Program vždy dělá to co naprogramujete, ne to co chcete...
Satik0
Stálý člen
26. 6. 2014   #22
-
0
-

#20 Kit
Jo, to je super, když ti třeba z nějaké knihovny choděj unsigned bajty a ty si to pak v Java aplikaci musíš buďto převést na něco většího, aby to číslo odpovídalo a nebo počítat s tím, že třeba čísla nad 127 tam máš uložená jako záporná :)

Nahlásit jako SPAM
IP: 86.49.188.–
Kit+11
Guru
26. 6. 2014   #23
-
0
-

#21 KIIV
zdalo se mi zbytecne plytvat na pole hodnot 0-255 polem 4B integeru na kazdy

Dělat Flyweight v OOP je nepraktické a často i nesprávné.

kazdopadne parser binarnich dat bych v jave delat teda nechtel :D

Také bych nechtěl vynalézat kolo.

Nahlásit jako SPAM
IP: 147.229.242.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Kit+11
Guru
26. 6. 2014   #24
-
0
-

#22 Satik
Zřejmě byla použita nevhodná knihovna. To jsou všechno low-level záležitosti, které je lepší řešit v jazycích nižší úrovně, jako jsou třeba C/C++.

Nahlásit jako SPAM
IP: 147.229.242.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
KIIV+42
God of flame
26. 6. 2014   #25
-
+1
-
Zajímavé
Kit +

proste se da vesmes shodnout na tom, ze ne kazdy jazyk se hodi na vse - to je zaklad..

ja osobne na neco, co chci aby pracovalo rychle a neni tam nutnost mit moc extra libek, pouziju c++

na nejaky dolovani dat a scripty pouziju perl..

na nejakou kravinu pro android javu

na trivialni dynamickej web php, narocnejsi klidne perl

EDIT:

uplne sem zapomel: jednocipy - C  nebo  C++ (pokud to ma smysl pouzit zrovna c++), assembler jen na zacatku, aby clovek videl jak to tam chodi

Nahlásit jako SPAM
IP: 62.168.56.–
Program vždy dělá to co naprogramujete, ne to co chcete...
Satik0
Stálý člen
26. 6. 2014   #26
-
0
-

#25 KIIV
Proto mam rad C#, je to takovy svycarsky nuz - umi v podstate vsechno - v zakladu je podobny jako Java, muzes v nem intenzivne pouzivat LINQ a pak to mas jak SQL, ale zaroven mu muzes (pres unsafe) vnutit pointery a programovat v nem v obdobne jako v C++.

A dnes uz je i multiplatformni, takze ho clovek rozjede temer vsude.

Nahlásit jako SPAM
IP: 86.49.188.–
JK
~ Anonymní uživatel
20 příspěvků
26. 6. 2014   #27
-
0
-

Sorry ale říkat, že  C++ není tak moc OOP jako C# a potom uvést toho příklad, že nemá GC, to mi příjde trochu úsměvné :-) o to právě v C++ jde. Co se týče C# vs. Java, tak zde jde samozřejmě o knihovny + různé fičury, jako třeba že Java neumožňuje přímo pracovat s eventy a další věci - pokud v C# neumíš tak to nemůžeš vědět.

Nahlásit jako SPAM
IP: 90.179.206.–
JK
~ Anonymní uživatel
20 příspěvků
26. 6. 2014   #28
-
+1
-
Zajímavé
Kit +

#25 KIIV
Nj jenže to u mě vyvolává dilema, totiž potřebu mít dobrou znalost jazyka a hlavně jeho knihoven - třeba i externích. Protože když chci něco naprogramovat, tak bych nerad sedl a řešil, jak se to či ono dělá třeba v Javě, jaké knihovny je vhodné použít v C++, jaké třeba v C#. Tzn. mít jeden nástroj a dobře ho znát (jde hlavně o knihovny).

Mě osobně se u C++ nelíbí, jak je tam všechno "rozházené" a "neunifikované". Stáhnu si třeba nějakou knihovnu a ta používá jedno nazvosloví, které není ani moc domyšlené. Jiná knihovna zase jiné. Jiná mixuje procedury a OOP dohromady. Prostě chaos. U Javy je to lepší a intuitivnější díky tomu, že obsahuje vcelku rozsáhlou nativní knihovnu (narozdíl od C++), potom i externí knihovny přebírají její logiku a dá se v tom pak prostě líp vyznat. Ještě lepší mi to příjde u .NETu. U C++ celkově zlepšuje situaci třeba knihovna Qt (nebo Boost), jenže tu zase jednou vlastnila Nokia, pak ho předala někomu jinému a kdo ví, jaká je jeho budoucnost. U C# a u Javy si aspoň můžu být jistý, že se o to bude starat velká korporace a nepustí to k vodě.

Nahlásit jako SPAM
IP: 90.179.206.–
Kit+11
Guru
26. 6. 2014   #29
-
0
-

#27 JK
Tak mi vysvětli, proč tedy programátoři v C++ píší víc procedurálně než objektově?

Nepřítomnost GC způsobuje hromadu "code smell" v objektovém kódu. Programátoři se pak raději pokročilým technikám OOP vyhýbají a používají jen základ.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
26. 6. 2014   #30
-
0
-

#28 JK
s tema knihovnama je to presne tak. kdyz si clovek hleda neco pro .net tak si pusti nugetu napise klicove slovo stahne knihovnu a vetsina knihoven se ovlada "jednim" prikazem.

Nahlásit jako SPAM
IP: 77.92.213.–
JK
~ Anonymní uživatel
20 příspěvků
26. 6. 2014   #31
-
0
-

#29 Kit
V C++ můžeš používat, až na pár detailů, knihovny napsané v C. Což je velká výhoda a každý C++ programátor zřejmě je zběhlý v použivání obojího. Dále procedury můžou být volány rychleji, viz. inline funkce, což se může hodit, nemám to ověřeno ale myslím že i funkce samotné jsou rychlejší než metody. Nevím jak se dá zobecnit, že programítoři píšou více procedurálně než OOP. Když děláš něco menšího, tak se nebudeš štvát s objektama, když něco velkého, kde je nutnost mít v tom pořádek, tak se to může napsat OOP. Kombinovat obojí dohromady, kromě třeba nějakých pomocných inline funkcí, mi moc ok nepříjde.

Nicméně třeba takové OpenCV kombinuje obojí. To je podle mě dáno tím, že jak se ta knihovna rozvíjela, byla nejdřív psaná procedurálně a potom se postupně přešlo na OOP. Podle mě je to mišmaš, jako u podobných OpenSource co spravují nadšenci ve volném čase, ale pořád lepší než nic :-)

Nahlásit jako SPAM
IP: 90.179.206.–
Flowy0
Věrný člen
26. 6. 2014   #32
-
0
-

#9 KIIV
pretazovanie metod je uplne prirodzene a JVM ma aj destruktor ... len akosi nema zmysel pretoze programator sa nestara o zrusenie objektu a JVM ti jeho zrusenie nezarucuje ani priblizne

Nahlásit jako SPAM
IP: 84.47.11.–
https://github.com/Flowy
JK
~ Anonymní uživatel
20 příspěvků
26. 6. 2014   #33
-
0
-

jo a taky stdlib od C++ je napsaná procedurálně, ale to je zde bráno jako spíše výhoda, stejně jako to že nemá GC :-)

Nahlásit jako SPAM
IP: 90.179.206.–
Kit+11
Guru
26. 6. 2014   #34
-
0
-

#32 Flowy
Pokud má být v destruktoru například smazání pracovního souboru, odeslání signálu jinému procesu nebo jiná externí aktivita, tak jsou destruktory v Javě či C# skutečně nepoužitelné.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Kit+11
Guru
26. 6. 2014   #35
-
-1
-
Mimo téma

#31 JK
Nevím jak se dá zobecnit, že programítoři píšou více procedurálně než OOP.

Zkus se podívat na běžný program v C++. Je to samé if, for a switch. To jsou klíčová slova typická pro strukturované programování a nemají mnoho společného s OOP.

Když děláš něco menšího, tak se nebudeš štvát s objektama

OOP nepoužíváme proto, že to někdo chce, ale abychom si zjednodušili programování a zpřehlednili vlastní kód. Proto se i drobné aplikace vyplatí psát objektově. Je to prostě pohodlnější, než se trápit s procedurálem.

jo a taky stdlib od C++ je napsaná procedurálně,...

To je v pořádku. Nízkoúrovňové knihovny se mají psát procedurálně kvůli výkonu.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
KIIV+42
God of flame
26. 6. 2014   #36
-
+1
-
Zajímavé

#28 JK
Velke rozdily v rozhrani knihoven pro c++ neni problem standardu c++. To je proste o tom, ze libky pisou lidi a kazdej ma jine coding standardy (pokud vubec)

#29 Kit
Ideal je pak v jave kod psanej pomoci samejch statickejch metod :D Takove proceduralni objektove programovani, kde proste proceduralni programovani "nejde";

Mimochodem - co povazujes za pokrocile objektove metody?

Kazdopadne nevidim duvod mit za kazdou cenu objekt, kdyz staci jednoducha funkce nebo dokonce lip funguje makro

Btw: java uz umi neco jako using nebo typedef ? To mi neskutecne chybelo v jave..

Nahlásit jako SPAM
IP: 94.113.95.–
Program vždy dělá to co naprogramujete, ne to co chcete...
JK
~ Anonymní uživatel
20 příspěvků
26. 6. 2014   #37
-
0
-

#35 Kit
zkus jít na abclinuxu.cz a předhoď tam svůj názor. Uvidíš, co se stane   

Nahlásit jako SPAM
IP: 90.179.206.–
p3can
~ Anonymní uživatel
312 příspěvků
26. 6. 2014   #38
-
0
-

#34 Kit
no tak presne na takoveto veci je v .NET rozhrani IDisposable ktere implementuje navrhovy vzor Dispose. prakticky se na to pouziva block using.

Nahlásit jako SPAM
IP: 77.92.213.–
Kit+11
Guru
26. 6. 2014   #39
-
-1
-
Mimo téma

#36 KIIV
Ideal je pak v jave kod psanej pomoci samejch statickejch metod :D

Neprovokuj :-)

Mimochodem - co povazujes za pokrocile objektove metody?

Například nahrazování podmíněného větvení programu polymorfismem. Docela to ten program zpřehlední a zrychlí. V C++ se pak však nedá použít pravidlo, že objekt se má likvidovat tam, kde vznikl.

Kazdopadne nevidim duvod mit za kazdou cenu objekt, kdyz staci jednoducha funkce nebo dokonce lip funguje makro

Používání objektů je výhodou tam, kde objekt obsahuje nějaký stav. Proto je knihovna Math plná statických metod - ukládání vnitřního stavu je u nich zpravidla nežádoucí.

Místo using se v Javě používá konstrukce

try (Scanner sc = new Scanner(file)) {
   :
}

Typedef má něco společného s generiky? To už Java také má.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Kit+11
Guru
26. 6. 2014   #40
-
0
-

#37 JK
Co by se mělo stát? Na abclinuxu.cz takové věci běžně píši a nemám problém si to obhájit. Však si to vyhledej.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Kit+11
Guru
26. 6. 2014   #41
-
0
-

#38 p3can
Ta maďarská notace u rozhraní mě docela dojímá :-)

Jde o to, že v jazycích, které zvládají destruktory, tohle řešit nemusíš.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
KIIV+42
God of flame
26. 6. 2014   #42
-
0
-

#39 Kit
Například nahrazování podmíněného větvení programu polymorfismem. Docela to ten program zpřehlední a zrychlí. V C++ se pak však nedá použít pravidlo, že objekt se má likvidovat tam, kde vznikl.

?? takovy veci pouzivame v praci porad... jen mas iracionalni strach z toho, ze se o pamet musis starat sam..

Proc chci destruktor v jave je RAII .. ne jen kvuli pameti, ale kvuli resourcum .. (obzvlaste interface k necemu externimu by mohlo mit znacny problemy s tim, ze se sice uklidi objekt, ale nevola se konkretni metoda na dejme tomu zavreni neceho otevreneho mimo javu)

Nahlásit jako SPAM
IP: 94.113.95.–
Program vždy dělá to co naprogramujete, ne to co chcete...
p3can
~ Anonymní uživatel
312 příspěvků
26. 6. 2014   #43
-
0
-

#41 Kit
dispose navrhovy vzor je uplne normalni navrhovy vzor pro správu prostredku. nvm co myslim pojmem madarska notace a taky opravdu nevim co myslis tim ze v jazycich s destruktorem to neresis ? to je pekny blabol. jednak pokud vim tak objekt musis sam uvolnit pres delete (v pripade c# pres dispose) a navic pokud v c++ zapomenes napsat delete tak dostanes memory leak coz neplati v pripade c# protoze ikdyz zapomenes na dispose tak se automaticky zavola destruktor (sice nejde urcit kdyz ale objekt se uvolni)

Nahlásit jako SPAM
IP: 77.92.213.–
Kit+11
Guru
26. 6. 2014   #44
-
0
-

#43 p3can
Zkus si v PHP tohle 

<?php
class Destruct {

    function __construct(){
        echo "Zavolán konstruktor třídy " . __CLASS__ . "\n";
    }

    function __destruct(){
        echo "Zavolán destruktor třídy " . __CLASS__ . "\n";
    }

    function __toString() {
        return __CLASS__;
    }
}

$obj = new Destruct();
echo "1. Mám tady objekt třídy " . $obj . "\n";
$obj = null;
echo "2. Mám tady objekt třídy " . $obj . "\n";

Destruktor se provede i když vypustíš poslední dva řádky. Do metody __destruct() můžeš umístit uvolnění externích zdrojů, odeslání signálů apod. V PHP se na to můžeš spolehnout, ale v C# a v Javě to musíš obsloužit jinak - mimo třídu.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Kit+11
Guru
26. 6. 2014   #45
-
0
-

#43 p3can
Maďarská notace je ten prefix "I" před "Dispose", tedy název "IDispose" používá maďarsou notaci. Kdysi to používal Fortran pro automatické nastavení typu proměnné podle jejího názvu. Většina jazyků se toho už zbavila, ale C# to stále používá.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
KIIV+42
God of flame
26. 6. 2014   #46
-
0
-

#45 Kit
opet jen cista formalita... aspon programator na prvni pohled vidi, ze to je Interface pro Dispose ... tezce pochybuju, ze by se podle toho ridil kompilator

Nahlásit jako SPAM
IP: 94.113.95.–
Program vždy dělá to co naprogramujete, ne to co chcete...
Kit+11
Guru
26. 6. 2014   #47
-
0
-

#46 KIIV
Je to formalita. Při programování se používá spousta formalit, které na kompilovaný kód nemají vliv. Například gettery a settery jsou pro kompilátor jen formalitami - výsledný kód vypadá tak, jako kdyby tam nebyly.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
KIIV+42
God of flame
26. 6. 2014   #48
-
0
-

jmenna konvence / gettery settery / mravenec unese padesatinasobek sve vahy.. 

asi uz musim skoncit v tomdle flamewaru .. nejak mi tu unikaj ty souvislosti

server.getDiskuze().getThread().getItem().setClosed(true); .. jako by to tam nebylo :D

Nahlásit jako SPAM
IP: 94.113.95.–
Program vždy dělá to co naprogramujete, ne to co chcete...
Kit+11
Guru
26. 6. 2014   #49
-
0
-

#48 KIIV
server.getDiskuze().getThread().getItem().setClosed(true);

Raději:

diskuse.close();

ať je to správně OOP :)

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
m4r100
Návštěvník
27. 6. 2014   #50
-
+1
-
Zajímavé

#15 Kit
Ano, tato konstrukce je v Javě 7.

Toto me vzdycky neskutecne pobavi. Nove funkcionality v Jave 7, super nove funkcionality v Jave 8... Vetsinu techto uzasnych novych funkcionalit ma C# (popr. VB) uz peknou radu let, zabudovanou primo do jadra jazyka.

To by mne zajimalo v kolika procentech projektu se tyto nove verze Javy pouzivaji. Vsechny zabehnute systemy se tezko budou aktualizovat. Takze se k temto "novym" vymozenostem stejne nedostanete v praxi.

Osobne mi pripada kod napsany v C# na prvni pohled prehlednejsi nez v Jave, C# nema tolik zbytecnosti. Mozna to je o zvyku, ale porovnejte sami na takovem jednoduchem prikladu.

public class Test {

  private String msg;
  public String getMsg() {
    return msg;
  }
  public void setMsg(string msg)
    this.msg = msg;
  }

  private String readMe;
  public String getReadMe() {
    return msg;
  }
  private void setMsg(string readMe)
    this.readMe = readMe;
  }
}

vs.

public class Test
{
  public string Msg { get; set; }
  public string ReadMe { get; private set; }
}

Pokud chcete videt novinky v .NET platforme a ten obrovsky rozdil oproti Jave, navstivte roslyn.codeplex.com

Nahlásit jako SPAM
IP: 89.176.251.–
Kit+11
Guru
27. 6. 2014   #51
-
0
-

#50 m4r10
Však v obou případech je kód nesmyslný. Takový kód by se vůbec neměl psát ani v jednom jazyku, protože je výsledkem tzv. anemického modelu. Java dělá dobře, když psaní takového prasekódu neusnadňuje.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
KIIV+42
God of flame
27. 6. 2014   #52
-
0
-

#51 Kit
ukazka, jak by to vsichni meli delat, by nebyla?

Nahlásit jako SPAM
IP: 62.168.56.–
Program vždy dělá to co naprogramujete, ne to co chcete...
Satik0
Stálý člen
27. 6. 2014   #53
-
+1
-
Zajímavé
Kit +

Musím říct, že i když Kit občas plácne něco, co je úplně mimo, tak diskuze s ním mě docela baví, sice to končí v lehce offtopic skoroflamu, který nikam nevede, ale člověk vždy získá pohled z úplně jiného úhlu problému :)

Nahlásit jako SPAM
IP: 86.49.188.–
Kit+11
Guru
27. 6. 2014   #54
-
0
-

#52 KIIV
Zkus si přečíst http://www.martinfowler.com/bliki/AnemicDomainModel.html , kde autor píše o tom, že anemické modely způsobují potřebu vytváření tzv. servisních vrstev, objekt si nedokáže udržet konzistenci a na práci s takovým objektem je nutné psát příliš mnoho duplicitního kódu, který se obtížně udržuje. Nejlépe je tu servisní vrstvu umístit přímo do kódu třídy, ale m4r10 tu servisní vrstvu neuvedl. Není co upravovat.

Uvedená třída má příliš primitivní rozhraní. Taková třída by vůbec neměla existovat, v podstatě jen reprezentuje strukturu. Když někde napíši, že třída by měla mít méně než cca 60 řádek, tak tím nemyslím 4 řádky ani 400 řádek, ale někde v rozmezí 20-60 řádek. Kratší jsou příliš hloupé, delší zase často obsahují příliš mnoho skrytých závislostí a špatně se testují.

Základní otázkou je: Co uvedená třída "Test" má dělat? Co představuje? Něco testuje? K čemu má takový test atributy "Msg" a "ReadMe", když s nimi nic nedělá? Je nějaká závislost mezi atributy "Msg" a "ReadMe"? Pokud ne, proč jsou v jedné třídě? Pokud ano, proč ta závislost není ošetřena? Když s nimi nic nedělá, tak je nepotřebuje a můžeme je z třídy vyhodit. Když je vyhodíme, tak třída zanikne.

Nahlásit jako SPAM
IP: 147.229.242.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
27. 6. 2014   #55
-
0
-

#54 Kit
tak to je samozrejme nesmysl.

1. m4r10 pouze poukazoval na rozdil mezi implementaci c# kodu a javy.

2. anemicky domain model se podle me tyka pouze urcite vymezene oblasti trid, ale napridklad pro komunikaci mezi serverem a klientem se pouzivaji DTO objekty. dalsi priklad uziti techto "prazdnych" trid je napr. pro definici zprav zasilanych pomoci publish-subscribe navrhoveho vzoru (napr. MVVMLight messanger)

Základní otázkou je: Co uvedená třída "Test" má dělat? Co představuje? Něco testuje? K čemu má takový test atributy "Msg" a "ReadMe", když s nimi nic nedělá?

Trida test muze byt TA zprava zasilana v messangeru. Property Msg a ReadMe jsou proste vlastnosti TE dane zpravy (doplnujici informace)

k #44

no jedna je to "nefer" porovnavat PHP ktery se pouziva jen na servery (a navic je interpretovany s vykonem nasobne nizsim nez JIT javy) s JAVA/C#/C++ ktere maji daleko sirsi vyuziti. navic co vim tak Garbage collector je v php pouzitelny az od verze 5.3+ ktera zaujima cca 40% serveru aktualne.

Nahlásit jako SPAM
IP: 77.92.213.–
Kit+11
Guru
27. 6. 2014   #56
-
0
-

#55 p3can
1. Rozdíl mezi implementací prasekódu C# a Javy.

2. Anemický doménový model by se neměl dělat vůbec. Snad jen jako návrhový vzor Messenger, ale i to je často na pováženou. Právě proto mě jeho použití jako ukázka zarazilo.

3. Ano, ale co ta třída dělá? Messenger je často považován za antivzor právě proto, že nic nedělá.

PHP používám i na klientské aplikace. Není to jedno? Výkon je téměř srovnatelný s Javou, záleží na konkrétní aplikaci a umění programátora. Jazyky Java/C#/C++ jsou univerzálnější, ale na hodně úloh je PHP lepší. Teď jsem zvědav, kdo sem pošle důkaz, že v cyklech je PHP 10× pomalejší než Java. O tom to přece není. Jinde zase vítězí PHP.

Garbage Collector v PHP nemusí být vůbec. Stačí mi fungující destruktory, které na ten GC nečekají, ale spouští se už v okamžiku, kdy je zrušena poslední reference na objekt. To v PHP funguje, ale v jazycích Java/C#/C++ ne.

PHP zdaleka není dokonalý jazyk, ale destruktory jsou jedna z mála věcí, které jsou v něm napsány lépe než v jazycích Java/C#/C++.

Nahlásit jako SPAM
IP: 147.229.242.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Satik0
Stálý člen
27. 6. 2014   #57
-
0
-

#56 Kit

PHP používám i na klientské aplikace.

Hodně štěstí v reálném světě s PHP aplikacemi na klientských strojích, kde porty blokuje kde co - od firewalu po Skype běžící na portu 80 :).

Jinde zase vítězí PHP.

Ukaž mi kód, kde je PHP rychlejší než C# / C++ / Java. A nebo uznej, že je to blábol (což je)  

Stačí mi fungující destruktory, které na ten GC nečekají, ale spouští se už v okamžiku, kdy je zrušena poslední reference na objekt. To v PHP funguje, ale v jazycích Java/C#/C++ ne.

Už tu několikrát bylo zmíněno, že např. v C# se na tohle používá kosntrukce using.

Nahlásit jako SPAM
IP: 86.49.188.–
Kit+11
Guru
27. 6. 2014   #58
-
0
-

#57 Satik
Co má PHP společného s portem 80? Na tom přece běží Apache. PHP žádné porty nepotřebuje.

Vzhledem k tomu, že knihovny PHP jsou z velké části napsány v C, tak třeba renderování obrázků bude minimálně srovnatelné s Javou. Podobně to bude i s operacemi map(), filter() a reduce(), které jedou v PHP velice rychle.

Umí ten using po skončení platnosti objektu třeba odeslat signál jiné aplikaci? Je garantováno, že ten signál odešle i když se aplikace následně ukončí?

Nahlásit jako SPAM
IP: 147.229.242.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Satik0
Stálý člen
27. 6. 2014   #59
-
0
-

#58 Kit
V PHP neprogramuji, ale předpokládal jsem, že musíš spustit nějakého Apache nebo něco podobného.

Ne na vše jsou knihovny, v reálném světě musíš občas napsat i nějaký algoritmus   

Ano, using ti zabezpečí, že ten signál odešleš hned při opouštění scopu a to i pokud došlo k chybě.

Nahlásit jako SPAM
IP: 86.49.188.–
Kit+11
Guru
27. 6. 2014   #60
-
0
-

#59 Satik
PHP není na Apache nijak závislé. Skript v PHP můžeš spustit úplně stejně jako v Pythonu, Javascriptu, Lua, Octave, Lispu, awk, SQLite, xsltproc, klientovi MySQL apod. Jednoduché skripty bývají provedeny v časech kolem 50 ms - včetně natažení běhového prostředí. PHP normálně funguje i interaktivně z příkazové řádky podobně jako shell, jen to prostě "není ono". PHP také (na rozdíl od shellu) neumí pracovat s více vlákny, ale můžu ho z toho shellu spustit vícekrát paralelně. Takhle jsem si vyzkoušel i úskalí současného zápisu z více vláken PHP do jednoho souboru.

PHP 5.4 už dokonce obsahuje i vlastní WWW server, můžeš ho pověsit na libovolný dostupný port. Mám takhle na pracovní stanici spuštěny 4 webservery, v každém mám jinou lokální webovou aplikaci. Bez Apache, jen samotné PHP.

Pokud algoritmy sestavuješ tak, že voláš knihovní funkce, bývá program i rychlý. Není důvod vynalézat kolo. Knihovní funkce bývají mnohem výkonnější, než nejrůznější frameworky, proto jim dávám přednost. Navíc knihovní funkce bývají mnohem lépe dokumentované, se stabilním rozhraním a také mnohem spolehlivější.

PHP používám na své klientské aplikace právě proto, že vývoj je mnohem jednodušší a rychlejší, než třeba v Javě. Hlavně proto, že obsahuje konstrukce, které třeba Javě nebo C# chybí - např. funkce jako parametr jiné funkce a již zmíněná trojice map/filter/reduce. PHP skripty (a jejich testy) během vývoje spouštím přímo ze svého editoru.

Nahlásit jako SPAM
IP: 147.229.242.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Satik0
Stálý člen
27. 6. 2014   #61
-
0
-

#60 Kit

Pokud algoritmy sestavuješ tak, že voláš knihovní funkce, bývá program i rychlý. Není důvod vynalézat kolo. Knihovní funkce bývají mnohem výkonnější, než nejrůznější frameworky, proto jim dávám přednost.

To platí možná v PHP pro jednoduché aplikace, ale při psaní čehokoliv většího (složitějšího) ti nestačí jen lepit dohromady knihovny a navíc i ty knihovny musel někdo napsat a použít nějaký algoritmus :)

Funkce jako parametr jiné funkce C# umí.

Nahlásit jako SPAM
IP: 86.49.188.–
Kit+11
Guru
27. 6. 2014   #62
-
0
-

#61 Satik
Bez knihoven by PHP byl vcelku bezvýznamný jazyk. Nedovedu si představit, že bych si do každé aplikace musel psát svůj ovladač databáze, i když to není těžké a jistě bych to zvládl. Myslím si, že ani v C# bys ho nechtěl psát, že raději použiješ ten z knihovny LINQ.

Funkce jako parametr jiné funkce C# umí.

Myslíš tím delegáty? Měl jsem na mysli funkci, kterou dáš jako parametr jiné funkce a voláš tu funkci zevnitř.

Nahlásit jako SPAM
IP: 147.229.242.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
27. 6. 2014   #63
-
+1
-
Zajímavé

#56 Kit

1. nevim co je na 8let starych auto properties prasekod ale jestli se nekomu chcou vypisovat pro primitivni clenske promene getery a setery tak je to asi masochysta.

3. messanger se pouzi napr. pro zasilani zprav pokud mezi ViewModelama v MVVM pokud mas vetsi system ktery se vyvyji postupne.

no jasne proc bysme delali desktopove aplikace v jazycich/platformech ktere jsou na to primo urcene kdyz to muzeme bastlit pomoci frameworku urceneho pro webove stranky

C# umi posilat funkci jako parametr vice zpusoby.

Nahlásit jako SPAM
IP: 77.92.213.–
Kit+11
Guru
27. 6. 2014   #64
-
0
-

#63 p3can
1. Psát gettery a settery je zbytečné a je zbytečné je i generovat. Proč ty atributy prostě nenechat privátní, aby na ně nikdo nemohl hrabat? Atributy přece nemají být veřejné ani prostřednictvím getterů či setterů. Mají být zapouzdřené do objektu - zvenčí neviditelné.

3. Vím, k čemu slouží Messenger. Běžně ho dodává např. PDO v PHP. Když však k tomu messengeru přidáš pár metod, máš z něho plnohodnotnou třídu, která ti data rovnou zpracuje do takového tvaru, jaký potřebuješ. A to se vyplatí.

Nahlásit jako SPAM
IP: 147.229.242.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
27. 6. 2014   #65
-
0
-

#64 Kit
1. tady asi nekdo nepochopil co je to property v c# :). v c++/jave pokud mas tridu TCPClient tak adresu serveru zjistis pres metodu string getIPAddress(), pripadne nastavis adresu pres void setIPAddress(string address), kde v seteru "musis zrusit stavajici pripojeni a vytvorit to nove". nemuzes jen tak vystavit string IPAddress protoze na nem neni mozne detekovat zmenu to asi chapes ze :). v c# se to napise tak ze si udelas string IPAddress {get{..} set{...}} kde definujes telo seteru a telo geteru. Jejich implementace muze byt libovolna. Vyhoda je potom v tom ze si schopny tyto property jednoduse provazat s GUI (pomoci bindingu) a GUI pak jednoduse vi jak ziskat danou hodnotu a jak danou hodnotu nastavit.

2. Pokud vim tak pokud mam 2 ViewModely (muzes chapat jako 2 obrazovky) trebas Clients a ClientDetail tak jsem schopny definovat si zpravu ClientAccountChange { string ID, double NewAccountBalance} kde v Clients se registruju pomoci metody Subscribe na tento typ zpravy a v ClientDetail pri zmene stavu uctu klienta poslu zpravu do messangeru pomoci metody Publish. tato cast systemu se potom zkompiluje a je nemena. pozdeji se rozhodnu ze pridam obrazovku ClientOrders kde budu chtit upravit stav jeho stav uctu, takze pouze zaslu zpravu pomoci metody Publish a system si stim poradi. (samozrejme ze postup de provest i pres sdilene service a spoustou jinych technik). ted teda nevim jak bych mel podle tebe nazacatku upravovat ten messanger kdyz ani nevim co budu v budoucnu delat ?

Nahlásit jako SPAM
IP: 77.92.213.–
sleepy
~ Anonymní uživatel
422 příspěvků
28. 6. 2014   #66
-
0
-

#50 m4r10
Mas v dvoch metodach rovanku signaturu to ti nepojde.

Nahlásit jako SPAM
IP: 158.195.197.–
Flowy0
Věrný člen
29. 6. 2014   #67
-
0
-

#65 p3can
naco by mal tcp client posielat adresu dalej? ip adresa je interny udaj ktory sluzi pre tcp spojenie a nevidim ziadny dovod aby ho poznal niekto vyssie ... ak mas tcp spojenie tak sa ma starat o vsetko co k tcp spojeniu patri ... pre kazde spojenie mas novu instanciu a tieto neni problem spravovat vyssie aj bez ip adresy

ak si tcp client nedokaze vyriesit vsetko co je ulohou tcp tak to neni tcp client ...

Nahlásit jako SPAM
IP: 84.47.11.–
https://github.com/Flowy
Kit+11
Guru
29. 6. 2014   #68
-
0
-
Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
29. 6. 2014   #69
-
0
-

#68 Kit

pokud vim tak tak cely clanek je pouze o tom ze by se nemelo delat to ze kazdy private field obalite do get/set ale o tom ze inteligentne uvazujete a obalujete pouze to co je nezbytne a zbytek zapouzdrujete "jinymy metodami nez get/set v ramci zachovani oop".


ps: neni nadto opirat se o 11 let stary clanek, ktery pojednava o nevhodnem pouziti getteru/setteru v souvislosti s properties, ktere vznikly rok po publikaci toho clanku clanku :).

#67 Flowy
zapomel sem napsat ze se jedna o ilustracni priklad ktery jsem si vymyslel pouze pro demonstraci property.

Nahlásit jako SPAM
IP: 77.92.213.–
Kit+11
Guru
29. 6. 2014   #70
-
0
-

#69 p3can
OOP je tady přes 40 let. Že Microsoft stále tlačí do C# procedurální metody programování ještě neznamená, že se mají používat.

Zkus se podívat, jaký názor na properties mají vývojáři v PHP. A to se o PHP hovoří jako o mizerném jazyku. Properties tam jsou také, ale vývojáři, který je použije, to je vždy vyčítáno.

Tím, že se gettery a settery (resp. properties) stávají součástí rozhraní třídy omezuje vývojáře v možnostech tuto třídu přestavět. Musel by změnit rozhraní, které je v daném případě velmi košaté. Zároveň omezují použití polymorfismu, protože by všechny třídy musely implementovat všechny gettery a settery z rozhraní i kdyby je nepotřebovaly.

Výsledkem pak je, že programy jsou plné zbytečných ifů a switchů - tedy místo OOP jen klasický procedurál.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
29. 6. 2014   #71
-
0
-

#70 Kit
neni nahodou cele ORM, GUI a treba cela architektura MVVM postavena na getterech/setterech? muzes uvest priklad tebou popsanych omezeni vyplivajaci s tech g/s ?

Nahlásit jako SPAM
IP: 77.92.213.–
Kit+11
Guru
29. 6. 2014   #72
-
0
-

#71 p3can
ORM už z principu nemůže být napsáno objektově, ale procedurálně. Navíc ORM je hodně kontroverzní a dle mého názoru by se nemělo používat vůbec.

Že tvůrci GUI použili procedurální techniky na nižší vrstvě ještě neznamená, že bychom je měli používat i na vyšších vrstvách. V systémových knihovnách se procedurální techniky používají běžně. V aplikacích by se však mělo používat OOP.

Příklady jsem už uvedl. Jak chceš dělat polymorfismus s gettery a settery?

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
29. 6. 2014   #73
-
0
-

podle tebe je naho* C#, Java, C++ cele ORM, GUI, + dalsich milion knihoven a pulka navrhovych a architektonickych vzoru. tak jo   

uznavam ze sem to spatne napsal. chtel jsem abys uvedl priklad kodu, kde neni mozne/ je silne omezeno pouziti polymorfismu.

Jak chceš dělat polymorfismus s gettery a settery?

normalne.

Nahlásit jako SPAM
IP: 77.92.213.–
Kit+11
Guru
29. 6. 2014   #74
-
0
-

#73 p3can
To vůbec netvrdím. Říkám jen, že v těchto objektových jazycích programátoři píší své aplikace z velké části procedurálně a málo objektově. V návrhových vzorech přece gettery ani settery nejsou.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
29. 6. 2014   #75
-
0
-

tak sem hod kod ktery napises dle oop a ktery si myslis ze nejde prepsat pomoci properties a ja ti ho prepisu (pokud to teda bude vubec mozne protoze opravdu na uplne vsechno nejdou nacpat properties)

Nahlásit jako SPAM
IP: 77.92.213.–
Kit+11
Guru
29. 6. 2014   #76
-
0
-

#75 p3can
Ještě než to sem hodím, tak si zkus udělat properties privátní. Properties by totiž neměly být veřejné, protože odhalují implementaci objektu a to je proti principům OOP.

Co třeba tuhle třídu v Javě?

https://gist.github.com/kitsaels/9587921

Hmm, koukám, že to nebyl nejvhodnější příklad. Zkusím vyhrabat jiný.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
29. 6. 2014   #77
-
0
-

   

    public interface IPlayer { }

    interface ICreep
    {
        string Name { get; }
        bool IsAlive { get; }
        Point Position { get; set; }

        void DoDamage(IPlayer p);
        void TakeDamage(int dam);

    }

    sealed class NormalCreep:ICreep
    {
        private int? _hp;
        private Point _position;

        public NormalCreep(string name)
        {
            Name = name;
            
        }
        public string Name { get; private set; }
        public bool IsAlive { get { return HP > 0; } }

        private int HP
        {
            get
            {
                if (_hp == null)
                    _hp = ExpensiveOperation();
                return _hp.Value;
            }

            set { _hp = value; }
        }

        public Point Position
        {
            get { return _position; }
            set
            {
                if (value == _position) return;
                _position = value;
                OnMove();
            }
        }

        private int ExpensiveOperation()
        {
            //fake implementation
            return 0;
        }

        private void OnMove()
        {
            throw new NotImplementedException();
        }

        public void DoDamage(IPlayer p)
        {
            throw new NotImplementedException();
        }

        public void TakeDamage(int dam)
        {
            HP -= dam;
        }
    }

property muze byt jak verejna tak privatni a muze mit ruzne oznacene i jednotlive modifikatory g/s.

Nahlásit jako SPAM
IP: 77.92.213.–
Kit+11
Guru
29. 6. 2014   #78
-
0
-

#77 p3can
Tohle ale dělá úplně něco jiného.

V OOP by property měly být pouze privátní. V C# je však můžeš mít i veřejné.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
29. 6. 2014   #79
-
0
-

#78 Kit
vubec nevim o cem mluvis a porad cekam na nejaky tvuj kod.

Nahlásit jako SPAM
IP: 77.92.213.–
Kit+11
Guru
29. 6. 2014   #80
-
0
-
Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Flowy0
Věrný člen
29. 6. 2014   #81
-
0
-

aky ma zmysel prepisovat nieco z jedneho jazyka do ineho? ... samozrejme ze vsetko sa da napisat v C ved aj JVM sa musi vykonavat v zdrojovom kode ...

Nahlásit jako SPAM
IP: 84.47.11.–
https://github.com/Flowy
Kit+11
Guru
29. 6. 2014   #82
-
0
-

#81 Flowy
Přepsal jsem to proto, abych ukázal, že to jde i bez properties, getterů a setterů.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
29. 6. 2014   #83
-
0
-

#82 Kit
ale ja sem nikdy nerikal ze properties jsou nejaka magie ktera "nejde prepsat". tos ty rikal ze properties a OOP se vylucuje, ze to nejde, ze je to necitelne, a ze je to zhouba sveta.

properties jsou pouze "zkracenim" geteru a seteru a toho se vyuziva jednak u databindingu

http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh464965.aspx

se kterym souvisi cela architektura MVVM, tak u spousty dalsich veci.

ps. toho prikladu sem si vsiml az ted (zrejme editace prispevku). ale je vtipne si vybrat jako "priklad oop / polymorfismu" enumy z javy ktere existuji v teto podobe asi jen v jave (enum s konstruktorem,metodama a fieldama). a k tomu jeste pouzit priklad ze stranek oracle vysekat z tama ty zle getery/setery tak aby mohla funkce main uprostred te tridy planet vypsat primo ty private fieldy   .

Nahlásit jako SPAM
IP: 77.92.213.–
Kit+11
Guru
29. 6. 2014   #84
-
0
-

#83 p3can
Ty jsi také použil ve svém rozhraní veřejné properties, které v Javě nejsou. Ten příklad byl první, který mi přišel pod ruku. Je to jedna z tříd mé simulace planetárního systému.

Na property se mi nelíbí zbytečná duplicita. Je jen na zvážení programátora, jestli použije property nebo metodu. Do značné míry jsou zaměnitelné, ale každé řešení má jiné rozhraní.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
29. 6. 2014   #85
-
0
-

#84 Kit
java nema zadne properties pokud vim. takze podobnost s

http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html

vcetne komentaru jednotek u hmotnosti a velikosti sou ciste nahodne   

jinak co je teda na mem kodu ktery je prospikovany properties z objektoveho hlediska spatne ? nebo cim jsem tam brutalne narusil ten polymorfismus ? protoze tys jasne tvrdil ze properties narusuji oop a nejde s nimy pracovat v poly.

Nahlásit jako SPAM
IP: 77.92.213.–
Kit+11
Guru
29. 6. 2014   #86
-
0
-

#85 p3can
Špatně je rozhraní. Něco máš přes property, něco přes metody. Když přidáš další typ protivníka, který bude mít nové vlastnosti, budeš muset rozšířit rozhraní a následně modifikovat všechny třídy, které to rozhraní používají.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
29. 6. 2014   #87
-
0
-

#86 Kit
No pokud mas blbe navrzene rozhrani tak to samozrejme musis prepisovat vzdy v kazdem jazyce. stim nijak nesouvisi C# properties, g/s nebo polymorfismus. nebo existuje jazyk ktery dokaze neco co bych neznal ?   

Nahlásit jako SPAM
IP: 77.92.213.–
Kit+11
Guru
29. 6. 2014   #88
-
0
-

#87 p3can
Právě ta jednoduchost použití properties svádí k tomu, že se hromada kódu, která má být uvnitř třídy, přemístí vně třídy do volajících tříd a s atributy pracuje přes veřejné properties, gettery nebo settery.

Ve tvé ukázce to vypadá ještě docela dobře.

Polymorfismus se nedá ukázat na jedné třídě. Řekněme, že bys přidal nějakému protivníkovi brnění. Při úderech by se mělo postupně rozbít brnění a teprve pak ubývat HP. Zůstalo by rozhraní stejné? Mělo by. Jenže pokud chceš podat informaci o stavu brnění, musíš rozhraní rozšířit a dostaneš se do problémů. Když přidáš mága, kterému při útoku bude ubývat mana, budeš mít další property a další rozšíření rozhraní.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
29. 6. 2014   #89
-
0
-

#88 Kit

Ve tvé ukázce to vypadá ještě docela dobře.

takze properties uz nejsou teda zhoubou a nekazi oop jo? a zalezi teda na programatorovi jak implementuje dany problem ? tyjo kdo by to cekal   

no ja vim ze se polymorfismus neda ukazat na jedne tride. ale pokud pisu primitivni hru tak vim co chci zobrazovat a to dam do interface. tridu mage a warrior muzu udelat i ted stimto interface pokud nechci zobrazovat dodatecne informace o nejakych specialitach.

Nahlásit jako SPAM
IP: 77.92.213.–
ekral
~ Anonymní uživatel
41 příspěvků
29. 6. 2014   #90
-
+1
-
Zajímavé

P#84 Kit
Na property se mi nelíbí zbytečná duplicita. Je jen na zvážení programátora, jestli použije property nebo metodu. Do značné míry jsou zaměnitelné, ale každé řešení má jiné rozhraní

No to neni pravda, v c# má to svoje jasná pravidla a i jmenné konvence.

Tady je dopouručení kdy používat properties a kdy ne. Ve stručnosti metody reprezentují akce a properties data:

http://msdn.microsoft.com/en-us/library/vstudio/ms229054(v=vs.100).aspx

In general, methods represent actions and properties represent data. Properties are meant to be used like fields, meaning that properties should not be computationally complex or produce side effects. When it does not violate the following guidelines, consider using a property, rather than a method, because less experienced developers find properties easier to use.

A tady je vysvětlení od Anderse Hejlsberga proč tam dali do c# properties a eventy:

http://www.windowsdevcenter.com/pub/a/oreilly/windows/news/hejlsberg_0800.html

But going back to these key component concepts, there's been a lot of debate in the industry about whether languages should support properties or events. Sure, we can express these concepts by methods. We can have naming patterns like a "get" block or a "set" block that emulate the behavior of a property. We can have interfaces and adapters that implement an interface and forward to an object. It's all possible to do, just as it's possible to do object-oriented programming in C. It's just harder, and there's more housekeeping, and you end up having to do all this work in order to truly express your ideas. We just think the time is right for a language that makes it easier to create components. Developers are building software components these days. They're not building monolithic applications or monolithic class libraries. Everyone is building components that inherit from some base component provided by some hosting environment. These components override some methods and properties, and they handle some events, and put the components back in. It's key to have those concepts be first class.

Nahlásit jako SPAM
IP: 195.113.99.–
Kit+11
Guru
29. 6. 2014   #91
-
0
-

#90 ekral
Ve stručnosti metody reprezentují akce a properties data

Hmm, jaký je rozdíl mezi akcí a daty? Obojí je zaslání zprávy objektu.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Kit+11
Guru
29. 6. 2014   #92
-
0
-

#89 p3can
Jenže já nechci rozšiřovat interface, ale chci zobrazovat dodatečné informace o těchto specialitách.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
30. 6. 2014   #93
-
0
-

Hmm, jaký je rozdíl mezi akcí a daty? Obojí je zaslání zprávy objektu.

Jo to je, ale jak to souvisí s tím že properties zpřehledňují nebo můžou zpřehledňovat práci s kódem. Jinak OOP je jenom jedno z paradigmat moderních jazyků. Úspěch jazyka se nepočítá podle toho jak moc dodržuje OOP nebo cokoliv jiného, ale jak je efektivní.

Osobně ti c# nenutím, pokud neumíš properties a nechápeš nebo nechceš chápat rozdíl mezi akcí a daty tak jak je to popsané na MSDN, tak to určitě neni jazyk pro tebe. Čistě subjektivně se mi prostě libí a je super že existuje i opensource implementace (Mono).

Nahlásit jako SPAM
IP: 195.113.99.–
p3can
~ Anonymní uživatel
312 příspěvků
30. 6. 2014   #94
-
+1
-
Zajímavé

#92 Kit
vykend konci takze uz to vzdavam. pises hnety. priznavam ze sem se pres vykend nudil a nechal se nachytat do trollování. az sem ti vsechno vyvratil tak proste pises furt dal nikde neuznas ze mas chybu jen odbocujes. ted tady resis interface pro ukazkovy priklad pro studenty stredni skoly.

Nahlásit jako SPAM
IP: 77.92.213.–
Kit+11
Guru
30. 6. 2014   #95
-
0
-

#94 p3can
Nic jsi mi nevyvrátil.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
30. 6. 2014   #96
-
+1
-
Zajímavé

Abych ale neodbíhal od tématu, tak můj pocit ze c# a .net je, že je to velmi progresivní a rychle se vyvíjející platforma. Java mi na druhou stranu příjde hodně konzervativní a elitářská. Javista se bude skoro do krve hádat, že properties jsou zlo, protože to není možná úplně čisté z hlediska OOP. Zatímco v .NETu jsou prostě programátoři rádi, že mají přehlednější kód. :NET mi prostě přijde jako vhodnější jazyk pro realisty a Java pro idealisty. Ale samozřejmě je to velké zjednodušení a zobecnění a osobní názor.

Nahlásit jako SPAM
IP: 195.113.99.–
Flowy0
Věrný člen
30. 6. 2014   #97
-
+1
-
Zajímavé
Kit +

#96 ekral
"prehladnejsi kod" (o tomto sa mozme tiez hadat pretoze zavadzas dalsi element ktory pre funkcnost nepotrebujes ako dokazuje java ... KISS) je podla teba dolezitejsi ako jednoduchost dalsieho rozsirenia?

Nahlásit jako SPAM
IP: 91.148.1.–
https://github.com/Flowy
ekral
~ Anonymní uživatel
41 příspěvků
30. 6. 2014   #98
-
+1
-
Zajímavé

#97 Flowy
Však proto jsem citoval co přesně píše o důvodech proč jsou v c# properties a eventy přímo autor jazyka Anderse Hejlsberga (a taky autor delphi a turbo pascalu):

"there's been a lot of debate in the industry about whether languages should support properties or events. Sure, we can express these concepts by methods .... It's just harder, and there's more housekeeping, and you end up having to do all this work in order to truly express your ideas. "

C# je prostě jazkyk navržený pro efektivní práci a ne pro jazykovou "čistotu".

Proč podle tebe brání properties dalšímu rozšiřování. Nebo co vlastně myslís tímto:

jednoduchost dalsieho rozsirenia

?

Nahlásit jako SPAM
IP: 195.113.99.–
Kit+11
Guru
30. 6. 2014   #99
-
0
-

#96 ekral
Properties nepřináší přehlednější kód, ale naopak zavádí "code smell".

Nahlásit jako SPAM
IP: 46.174.37.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
30. 6. 2014   #100
-
0
-

#99 Kit
No má to jasné jmenné konvence Prostě tam kde bys napsal GetVariable() nebo SetVariable(), tak použiješ property a má to i vlastní jmenné konvence. Určitě to jde zneužít, ale špatně se dá napsat i metoda GetVariable(). Podle mně to inteligetní vývojář zvládne a hlavně když používáš komponenty třetích stran tak je to opravdu přehlednější.

Ale jako tohle je už fakt offtopic. Oba jazyky c# i java jsou dost podobné a ty rozdíly nejsou nijak zásadní. Jenom v poslední době byl c# víc inovativní a java víc konzervativní a teprve ve verzi 8 zavedla třeba lambda experessions. Dobré je, že si každý může vybrat co mu víc vyhovuje a že neexistuje jenom jeden jazyk, ale že se ty jazyky vzájemně ovlivňují, nejdřív c# opisoval od javy, teď zase naopak java opisuje od c# a do budoucna to může být zase úplně jinak.

Nahlásit jako SPAM
IP: 195.113.99.–
Flowy0
Věrný člen
30. 6. 2014   #101
-
+1
-
Zajímavé
Kit +

#98 ekral
#86 Kit
ti to dokazal na priklade ... upravit interface znamena znicit kompatibilitu so starsim kodom (ci uz vlastnym alebo cudzim)

Nahlásit jako SPAM
IP: 91.148.1.–
https://github.com/Flowy
KIIV+42
God of flame
30. 6. 2014   #102
-
0
-

gettet/setter nic neporusuje.. kdyz se trefis do nejakyho dobryho nazvu, tak to, co zpristupnuje se muze klidne prejmenovat a nic se nedeje.. staci to upravit a rozhrani zustava stejny

zpristupnit primo atribut, tak uz ho zmenit proste nesmis

a to ze jedna pani povidala, ze gettery/settery by proste zakazala.. stejne jako ty internety, nic neznamena (jako vzdy, vseho moc skodi :))

Nahlásit jako SPAM
IP: 62.168.56.–
Program vždy dělá to co naprogramujete, ne to co chcete...
ekral
~ Anonymní uživatel
41 příspěvků
30. 6. 2014   #103
-
0
-

#101 Flowy

#98 ekral
#86 Kit
ti to dokazal na priklade ... upravit interface znamena znicit kompatibilitu so starsim kodom (ci uz vlastnym alebo cudzim)

jako ty myslíš to, že ukázal, že když máš špatně navržený interface, tak je ten interface nanic a nedá se s ním pracovat? Nechápu jaký je podle vás rozdíl mezi tím, jestli překrýváš (override) int GetVariable(); nebo int Variable { get; }. Podle mně to vyjde nastejno, u prvního vydedukuješ to, že je to getter z názvu metody a u druhého to víš přímo podle typu (a související jmenné konvence). Pokud jsou ale obecně gettery a settery zlo, tak je samozřejmě nemusíš používat ani v jave a v c# nemusíš používat property.

Jenom pro ujasnění, v c# můžeš normálně overridovat zvlášť getter a setter:

interface IDemo
{
        int Variable { get; }
}

class  Demo : IDemo
{
        public int Variable { get; private set; }
}

Nahlásit jako SPAM
IP: 195.113.99.–
ekral
~ Anonymní uživatel
41 příspěvků
30. 6. 2014   #104
-
0
-

Mám tam ještě chybu, měl to být:

interface IDemo
{
        int Variable { get; }
}

sealed class  Demo : IDemo
{
        public int Variable { get; private set; }
}

Nahlásit jako SPAM
IP: 195.113.99.–
Kit+11
Guru
30. 6. 2014   #105
-
0
-

#104 ekral
Otázkou ovšem zůstává: K čemu je to dobré? Tak leda k narušení konzistence objektu, protože pokud změním jeden atribut a nezměním jiný, který s ním souvisí, objekt se stane nekonzistentním.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
30. 6. 2014   #106
-
0
-

#105 Kit

Otázkou ovšem zůstává: K čemu je to dobré? Tak leda k narušení konzistence objektu, protože pokud změním jeden atribut a nezměním jiný, který s ním souvisí, objekt se stane nekonzistentním.

Setter má mít vliv pouze na jeden související field. Pokud toho dělá víc, tak to už není setter. Ale to pořád nevysvětluje jaký je takový rozdíl mezi tím, jestli napíšu int GetVariable() nebo int Variable { get; } ? Špatně to můžu navrhnout jak v prvním, tak ve druhém případě. Ale u property jde o to, že reflexe může odlišit property, field a metodu.

Nahlásit jako SPAM
IP: 195.113.99.–
Kit+11
Guru
30. 6. 2014   #107
-
0
-

#106 ekral
Mám v objektu dva atributy. Pokud změním jeden a nezměním druhý, objekt se stane nekonzistentním. Například změním IP adresu, ale nepřidělím číslo portu. Pokud se pokusím navázat spojení pomocí tohoto poloobjektu, tak selže.

Používání properties způsobuje, že objekt je po určitou část své existence nekonzistentní. Například  

Clovek adam = new Clovek();
adam.Jmeno = "Adam";

Mezi těmito dvěma řádky je objekt adam nekonzistentní - nemá jméno. To může mít vážné důsledky.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
30. 6. 2014   #108
-
0
-

#107 Kit
Mám v objektu dva atributy. Pokud změním jeden a nezměním druhý, objekt se stane nekonzistentním. Například změním IP adresu, ale nepřidělím číslo portu. Pokud se pokusím navázat spojení pomocí tohoto poloobjektu, tak selže.

Používání properties způsobuje, že objekt je po určitou část své existence nekonzistentní. Například  

Clovek adam = new Clovek(); adam.Jmeno = "Adam";

Mezi těmito dvěma řádky je objekt adam nekonzistentní - nemá jméno. To může mít vážné důsledky.

S tím souhlasím, ale za to nemůžou properties, ale špatný návrh. V prvním příkladu IP adresy a portu stačí mít třeba jako typ property kompozitní typ IP a port v jednom. V druhém případě kdy nechceš mít člověka bez jména, tak můžeš třeba povolit jen parametrický konstruktor s jménem.

Ale na tomto příkladu:

Clovek adam = new Clovek(); 
adam.Jmeno = "Adam";

nic nezmění, když použiješ obyčejnou metodu, pořád to bude stejně špatně. Já prostě tvrdím, že properties jsou v těch tvých přikladech uplně nevinně :D

Clovek adam = new Clovek(); 
adam.SetJmeno("Adam");
Nahlásit jako SPAM
IP: 195.113.99.–
Kit+11
Guru
30. 6. 2014   #109
-
0
-

#108 ekral
Však properties a gettery/settery jsou úplně stejně špatné. Má to vypadat takhle: 

Clovek adam = new Clovek("Adam");
Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
30. 6. 2014   #110
-
0
-

#109 Kit

Jo šak sem ti psal, že se to dá vyřešit parametrickým konstruktorem. Ale co tohle?

Clovek adam = new Clovek("Adam");
adam.ZmenJmeno("Eva");
Nahlásit jako SPAM
IP: 195.113.99.–
ekral
~ Anonymní uživatel
41 příspěvků
30. 6. 2014   #111
-
0
-

#109 Kit
Jo a co je špatného na getteru?

Clovek adam = new Clovek("Adam");
var jmeno = adam.GetJmeno();


nebo

Clovek adam = new Clovek("Adam");
var jmeno = adam.Jmeno;


Třeba chci objekt adam serializovat a nechci aby byla trida Clovek zavislá na žádné serializační technologii nebo knihovně?

Nahlásit jako SPAM
IP: 195.113.99.–
Kit+11
Guru
30. 6. 2014   #112
-
0
-

#110 ekral
To už je jiná. Metoda ZmenJmeno() změní jméno na základě nějakého dokladu a s nějakým zápisem do matriky (logu). Stav objektu je konzistentní před i po.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Kit+11
Guru
30. 6. 2014   #113
-
0
-

#111 ekral
Nejlépe asi bude, když se ta serializace injektuje přes parametr.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
30. 6. 2014   #114
-
0
-

#113 Kit

Jo to by šlo, otázka jestli to pak neřešit AOP pomocí atributů neobjektově. Ale z hlediska OOP je to injektování dobré řešení. Otázka ale je co s ViewModelem, který nemá referenci na view, prostě vůbec neví že nějaké view existuje a už vůbec nemá ani ponětí o tom jak by to View mohlo vypadat. Jediné co umí, tak poslat view přez prostředníka název property, kterou má aktualizovat a View má názvy propertiew, které má zobrazovat. Jak by jsi to přepsal bez getteru a setteru? Jenom připomínám že v tomto případě property  jsou opravdu jen "hloupá" data, které se mají zobrazit, prakticky je to model pro View. Příkazy se předvává ViewModelu pomocí commandů. Například příkaz ZmenJmeno by vzal Property Jmeno, které předtím změnilo view a zavolal privatni Metodu ZmenJmeno(Jmeno), která by už dělal to co jsi popsal (validace, logovaní, uložení atd.).

Nahlásit jako SPAM
IP: 195.113.99.–
Kit+11
Guru
30. 6. 2014   #115
-
0
-

#114 ekral
Architektonický vzor MVVM nepoužívám - možná se hodí pro práci s dalšími technologiemi od Microsoftu, což není můj případ. Místo toho se držím klasiky MVC, kde tyto požadavky řeší přímo model. Viewer sestaví dotaz, pošle ho modelu a ten dodá celý požadovaný strom dat naráz. Viewer tedy o vnitřní struktuře modelu nemá ponětí. Pouze ví, co od něj chce a model mu to dodá - nebo taky ne.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
30. 6. 2014   #116
-
0
-

#115 Kit

No MVVM je technologie Microsoftu. Výhoda je, že odděluje View od Modelu. Každé View má většinou jedna ku jedné svůj ViewModel. A View je nezávislé na modelu, který může být jeden pro všechny VM. Konkrétní View má k dispozici prostě jen přesně ty data, které potřebuje a nemůže se ani dostat k ničemu jinému. VM potom nevím vůbec nic o view, prostě ho to nezajímá. Celé je to založené na properties a notifikacích o změnách properties a podle mně je to ukázkový příklad toho, kde jsou gettery a settery užitečné.

Nahlásit jako SPAM
IP: 195.113.99.–
Kit+11
Guru
30. 6. 2014   #117
-
0
-

#116 ekral
To, co je v MVVM užitečné, je v MVC zbytečné. Pokud by některé úkony byly pro model příliš složité, předám mu ovladač přes DI. Ten pak funguje jako rozhraní mezi modelem a viewerem.

Ten mechanismus je docela podobný, ale gettery ani settery přitom nepotřebuji a všechny atributy mám stále privátní.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
30. 6. 2014   #118
-
0
-

#117 Kit

Ale to rozhraní musíš definovat předem. Ale ViewModel prostě předem neví jak bude vypadat View. Takže to tak nejde a s DI to prostě nevyřešíš.

Nahlásit jako SPAM
IP: 195.113.99.–
Kit+11
Guru
30. 6. 2014   #119
-
0
-

#118 ekral
Rozhraní je kontrakt, vždy ho musíš definovat předem. V MVC i v MVVM. Když do rozhraní nacpeš všechny properties, tak je tam máš také.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
30. 6. 2014   #120
-
0
-

#119 Kit

Ale to si nerozumíme. ViewModel vůbec neví jak bude vypadat konkrétní view, s každým view omunikuje spolu pomocí stejného interface, které má jediný event. Určitě je tam co vylepšovat, ale to už je na jinou debatu. Vysvětluju to jenom jako ukázku využití properties.

Nahlásit jako SPAM
IP: 195.113.99.–
Kit+11
Guru
30. 6. 2014   #121
-
0
-

#120 ekral
Jenže ViewModel má úplné rozhraní s Modelem. Má přístup ke všem jeho vlastnostem - má s ním tak těsnou vazbu, jako kdyby byl jeho součástí. Nebo se snad pletu?

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
1. 7. 2014   #122
-
0
-

MVVM puvodne vymyslel Microsoft ale momentalne je mozne jej vyuzit na ruzne typy projektu/platforem od desktopových (win,osx,linux) pres webove doplny (Silverlight), webove stranky a taky pro vytvareni aplikaci na mobilni telefony (WP8 android iOS). MVVM se sklada z View,Model,ViewModel a vetsinou i Binder. Model je jasny.

ViewModel je to nejdulezitejsi. Je to abstraktni vyjadreni toho co ma dany View umet. ViewModel obsahuje verejne pouze properties (to je to co chceme zobrazit na danem view) a commandy (akce, ktere bude uzivatel provadet na danem view). ViewModel nerika jak ma dane view vypadat pouze co ma obsahovat. View je konkretni implementace grafické reprezentace ViewModelu pro danou platformu (v ramci MVVM je mozne vytvorit jeden ViewModel a k tomuto ViewModelu je mozne vytvorit View vrstvu pro kazdou platformu jinou (pro android je to vetsinou Activita, pro iOS UIVIewController, pro WP8 Page, pro WPF Page)).

Spojeni mezi View a Viewmodelem obstaravá binder coz je nějaky framework. MS platformy obsahuji vlastni implementaci, ostatní platformy obsahuji custom implementaci. Binder je tenká mezivrstva usnadnujici napojení View na ViewModel. Samotna architektura MVVM nevyzaduje binder ale tento meziclanek velice vyzname omezuje mnozstvi "boilerplate" kodu.

Nahlásit jako SPAM
IP: 77.92.213.–
Kit+11
Guru
1. 7. 2014   #123
-
0
-

#122 p3can
ViewModel obsahuje verejne pouze properties a commandy...

No právě. Není toho nějak mnoho?

Vůbec ses nezmínil o vztahu mezi Modelem a ViewModelem. Vztah mezi Viewerem a ViewModelem je přece stejný jako v MVC mezi Viewerem a Modelem. To jsi ani nemusel popisovat. Jen to Microsoft udělal trochu komplikovanější.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
1. 7. 2014   #124
-
0
-

#123 Kit
MVVM není vynález Microsoftu, ale první implementace Presentation Modelu navrženého Fowlerem. Ale jo, napiš Fowlerovi, že jsi to šecko promyslel a že si jako osobně myslíš, že je to blbec a že ty mu dokážeš že MVC je lepší.

Prostě View nemá přístup k modelu a ViewModel není závislé na View. Výsledkem je že napíšeš VM a Model jednou a pak  doděláš View pro iOS, Andorid, W8.1, WP8.1, Xbox, ale taky i částečně pro OSX a Linux. A to všechno plně nativně! Jinak MVVM je i pro javascript a html (například knockout), není to jenom Microsoft Technologie.

Vztah VM a Modelu opravvdu MVVM moc neřeší, to už je na tobě, jak si to zorganizuješ.

Ale ještě jednou, jestli se ti to nezdá, tak to nepoužívej :D.

Nahlásit jako SPAM
IP: 195.113.99.–
Kit+11
Guru
1. 7. 2014   #125
-
0
-

#124 ekral
To vím, že MVVM vymyslel Fowler a Microsoft to jen zprznil.

Pokud VM a Model MVVM neřeší, tak je to z mého pohledu jeden blok a mám z toho polovinu MVC.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
1. 7. 2014   #126
-
0
-

#125 Kit

Tak ty něco neznáš a ani jsi to nepoužil, ale už víš, že to Microsoft udělal blbě :D. A už vůbec ti nevadí, že třeba MvvmCross není vůbec od Microsoftu, ale je to taky MVVM a taky používá properties.

Takže říkáš, že MVC ti řeší nečekaně jenom polovinu toho co MVVM, a co ta druhá polovina? Podle mně se ale asi bavíš o webovém MVC,  MVVM je ale přitom určený hlavně pro nativní klientské aplikace. 

Nahlásit jako SPAM
IP: 195.178.90.–
Kit+11
Guru
1. 7. 2014   #127
-
0
-

#126 ekral
Druhou polovinu přece v MVC řeší Controller, který prostřednictvím Modelu může modifikovat data.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
1. 7. 2014   #128
-
0
-

#127 Kit

Pomůžu si citací od Fowlera, popisuje to dost srozumitelně, nevím co k tomu dál už napsat, každému vyhovuje něco jiného, ale neměl by jsi svoji subjektivní oblibu MVC a neoblibu properties a MVVM prezentovat důkazy nějakého obecně platného tvrzení o MVVM.

The Presentation Model coordinates with the domain layer and provides an interface to the view that minimizes decision making in the view. The view either stores all its state in the Presentation Model or synchonizes its state with Presentation Modelfrequently... It's useful for allowing you to test without the UI, support for some form of multiple view and a separation of concerns which may make it easier to develop the user interface. ... Presentation Model allows you to write logic that is completely independent of the views used for display. You also do not need to rely on the view to store state. The downside is that you need a synchronization mechanism between the presentation model and the view. This synchronization can be very simple, but it is required. 

Nahlásit jako SPAM
IP: 195.178.90.–
ekral
~ Anonymní uživatel
41 příspěvků
1. 7. 2014   #129
-
0
-

prezentovat důkazy nějakého obecně platného tvrzení o MVVM.

tohle mělo být:

prezentovat jako důkazy nějakého obecně platného tvrzení o MVVM.

Nahlásit jako SPAM
IP: 195.178.90.–
ekral
~ Anonymní uživatel
41 příspěvků
1. 7. 2014   #130
-
0
-

Jo a ještě jedno doplnění k výhodam Presentation modelu proti MVC. Ale kdo ví, co vlastně myslíš pojmem MVC. Napiš prosím konkrétní technologie které používáš (jazyk, framework, atd.). Pojem MVC je moc obecný a většinou tím lidi popisují úplně rozdílné věci. 

Takže ještě jedna citace od Fowlera:

The Presentation Model works well also for another presentation logic problem - presentation state. The basic MVC notion assumes that all the state of the view can be derived from the state of the model. In this case how do we figure out which station is selected in the list box? The Presentation Model solves this for us by giving us a place to put this kind of state. A similar problem occurs if we have save buttons that are only enabled if data has changed - again that's state about our interaction with the model, not the model itself.

Nahlásit jako SPAM
IP: 195.178.90.–
Kit+11
Guru
1. 7. 2014   #131
-
0
-

#130 ekral

  1. Fowler píše o MVP jako o dalším architektonickém vzoru hned za MVC
  2. Nikde nevidím ani zmínku o public properties
  3. Nikde nevidím ani zmínku o MVVM

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
1. 7. 2014   #132
-
0
-

#131 Kit

MVVM je jedna z implementací PM v c# která používá public properties. Nepleť si PM s MVP! Další implementaci je třeba knockout pro javascript a typescript. Myslím ale že pojem MVVM se začal používat pro většinu mplementací PM.

Speciálně pro tebe jsem našel implementaci PM pro Javu Zx Framework, kde nečekaně zase používají public gettery a settery:

http://www.zkoss.org/zkdemo/getting_started/mvvm

Podívej se v tom tutoriálu hlavně na ViewModel.

Pak ještě napiš konkrétně co používáš ty, jako jaký zazyk, případně platformu pro to MVC.

Nahlásit jako SPAM
IP: 195.178.90.–
Kit+11
Guru
1. 7. 2014   #133
-
0
-

#132 ekral
PM se týká GUI. Řešíme práci s daty. Konkrétně Fowler si gettery a settery bere dost na mušku http://martinfowler.com/bliki/GetterEradicator.html a doporučuje se jim vyhýbat.

Používám nejčastěji PHP a Javu i další jazyky. Frameworkům se vyhýbám. Kvůli 50 ušetřeným řádkům vlastního kódu přece nebudu includovat 5000 řádků cizího kódu.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
1. 7. 2014   #134
-
-1
-
Mimo téma
Kit -

PM, MVC a MVP jsou všechno GUI architektury. Já řeším že MVVM je příklad, kde mají využití i gettery.

Však ten článek do Fowlera co posíláš potvrzuje, že jsou gettery i užitečné:

There are too many times when objects do need to collaborate by exchanging data, which leads to genuine needs for getters.

Nahlásit jako SPAM
IP: 195.178.90.–
Flowy0
Věrný člen
1. 7. 2014   #135
-
+1
-
Zajímavé
Kit +

#134 ekral
nikto nepovedal ze accessory su zbytocne ... ale v OOP nemaju co robit ... samozrejme kod sa musi podriadovat aj inym pravidlam ktore uz nemozu byt OOP ... drzat sa ale accessorov ako primarnej cesty nieje vhodne riesenie a moze priniest mnozstvo (zbytocnych - a co je hlavne - keby si sa im vyhol tak casovo narocnych) problemov

stavat jazyk s tym ze nevhodne cesty maju byt co najjednoduchsie je populisticke riesenie ... urcite to neni cesta ktora je vhodna pre pokrocile programovanie a moze ta od takehoto odradzat (ked to predsa funguje aj v assembleri tak preco nepisat takto ...)

Nahlásit jako SPAM
IP: 84.47.11.–
https://github.com/Flowy
Kit+11
Guru
1. 7. 2014   #136
-
0
-

#134 ekral
Krásně jsi tu větu vytrhl z kontextu. Co kdyby sis přečetl i zbytek toho článku?

MVC ani MVP nejsou GUI architektury. To si s něčím pleteš. Ano, tyto architektury se používají i v GUI, ale zdaleka to není jediné použití. MVC je princip, který vnitřně rozděluje doménu na data, accesory a mutatory.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
1. 7. 2014   #137
-
0
-

Vztah mezi Viewerem a ViewModelem je přece stejný jako v MVC mezi Viewerem a Modelem.... Jen to Microsoft udělal trochu komplikovanější.

Kdybys napsal jen ze V - VM je podobne V - C tak bych napsal ze asi tezko ze tomu nerozumis ale prirovnavat to k V - M a zakoncit to vetou ze to MS udelal slozitejsi kdyz ani nevis o cem blabolis ...  

To vím, že MVVM vymyslel Fowler a Microsoft to jen zprznil.

Bohuzel fowler nevymyslel MVVM ale dobry pokus.

Fowler píše o MVP jako o dalším architektonickém vzoru hned za MVC
Nikde nevidím ani zmínku o public properties
Nikde nevidím ani zmínku o MVVM

No este vedet jak je to vlastne s architekturama ze.

Připojen obrázek.

Řešíme práci s daty. Konkrétně Fowler si gettery a settery bere dost na mušku ...

No zase si to hezky prekroutil ... No jasne pokud ignorujes Microsoft, Xamarin, Apple (kde jsou property uvedeny v novem jazyce SWIFT, ktery nahrazuje "popularni" ObjectiveC), a celou oblast ORM + dalsi co me ted z hlavy nenapadne tak jasne muzes hrdine prohlasit ze te vlastne property nebo g/s a vubec nezajimaji   

Jinak k tvemu poznatku o ORM prikladam citaci z diskuze jednoho fora

Ale shodit tím kompletně ORM? A jak by si to tedy chtěl udělat?

Java jsou objekty. Databáze jsou relace. Asi není překvapení, že zkratka ORM znamená objektově relační mapování. No ale přece i když napíšu SQL dotaz, projdu ResultSet a výsledky uložím do Java objektu, tak také ale dělám ORM!

Rozdíl je, že Hibernate dělá ORM automaticky, jinak ho udělám ručně.

Závěrem, tvrdit tedy "ORM bych nepoužil" nedává smysl.

Otázka zní, "budu dělat ORM ručne, použiji na to nástroj. A pokud ano, tak který?".

a třešnička na závěr

MVC ani MVP nejsou GUI architektury. To si s něčím pleteš.

Diky za radu. Furt sem premyslel proc me nefunguje moje WebServisa a zjistil jsem ze me tam vlastne chybi cela vrstva View   

Nahlásit jako SPAM
IP: 77.92.213.–
ekral
~ Anonymní uživatel
41 příspěvků
1. 7. 2014   #138
-
0
-

#136 Kit
p3can ti to vysvětlil úplně luxusně. Já jenom dodám, že pokud teda odkazuješ na Fowlera, tak asi budeš překvapeny, že sám zahrnuje MVC do GUI architektur, pak se podívej jak a proč MVC vzniklo a nakonec se zamysli nad tím co znamená to View v MVC.

Co se týká getterů, tak opravdu se Kit dostal vlastní citací. Doporučuju ten článek přečíst kitovi a (taky Fowymu) ještě jednou, protože není o tom, že jsou gettery se nemají používat, ale uvádí kdy jsou vhodné a kdy ne. A ještě jednou, to co považuješ za vytržené z kontextu je prakticky hlavní myšlenka článku.

A good rule of thumb is that things that change together should be together. Data and the behavior that uses it often change together, but often you see other groupings that matter more.

což je zobecněn toho co jsem už citoval:

There are too many times when objects do need to collaborate by exchanging data, which leads to genuine needs for getters.

Jako já chápu vaši motivaci, ale situace není tak černobílá a properties mají svůj význam, jen je nutné je správně používat. S tím, že čistě puristický OOP návrh nemusí být ten nejlepší pro všechny případy. Sám si myslím, že properies s jasně danými pravidly v c#, jsou lepší variantou díky jasně daným pravidlům než gettery a settery bez pravidel například v jave.

Nahlásit jako SPAM
IP: 195.113.99.–
Kit+11
Guru
1. 7. 2014   #139
-
0
-

#138 ekral
Je vidět, že jsi ten článek od Fowlera četl, ale nepochopil. Zkus si přečíst jeho knihu Refactoring. S gettery a settery tam pracuje, aby vysvětlil, kdy se mají nebo nemají použít a proč. Kolem sebe vidím hromady kódu, ve kterém jsou gettery a settery (resp. properties) použity chybně.

Gettery, settery a properties nejsou přístupovými metodami k atributům objektu, ale k objektu samotnému.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
2. 7. 2014   #140
-
0
-

#139 Kit
Ten fowler tam úplně jasně píše, že gettery mají svoje uplatnění. Není to možné ani pochopit jinak, píše to tam dost explicitně.

Ale abych se ujistil, jakým způsobem interpretuješ psaný text, jaký je podle tebe význam těchto vět?

Allocation of behavior between objects is the essence of object-oriented design, so like any design, there isn't a hard and fast rule - rather a judging of trade-offs. Putting the behavior in the same class as the data, what Craig Larman calls "Information Expert", is the first choice to consider. But it isn't the only route. Layering often trumps this, many of the Gang of Four patterns separate data from behavior for particular needs. A good rule of thumb is that things that change together should be together. Data and the behavior that uses it often change together, but often you see other groupings that matter more.

Nahlásit jako SPAM
IP: 195.113.99.–
Kit+11
Guru
2. 7. 2014   #141
-
0
-

#140 ekral
Však je to prosté. OOP má svá pravidla, která stanovují chování mezi objekty, ale z každého pravidla mohou existovat výjimky. Základním pravidlem je umístit chování objektu dovnitř objektu. Pokud však máme více vrstev, můžeme toto pravidlo částečně porušit a tam, kde to potřebujeme, můžeme oddělit chování (metody) od dat, ale se souvisejícími daty (relací) bychom měli pracovat současně.

To znamená, že pokud v modelu mám zákazníky, ceníky a faktury, tak v obslužné vrstvě mohu pracovat zvlášť se zákazníkem, položkami ceníku, fakturou a položkami faktury. Neměl bych samostatně měnit jméno či příjmení zákazníka, protože tyto údaje spolu souvisí. Mohu mu však doplnit telefonní číslo s typem toho telefonního čísla (domů, do práce,...)

Například takto: 

customer.set(new Name("John", "Brown", "jr."));
customer.add(new PhoneHome("123456789"));
customer.add(new PhoneWork("923456789"));
bill.add(new BillItem("9780201485677", "Refactoring..."));
System.out.println(customer.name());
System.out.println(customer.phone());
System.out.println(customer.phoneHome());...atd.
Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
2. 7. 2014   #142
-
0
-
Nerozhodně
Kit -

#141 Kit
hej kamo si zabil    

nevim jak se ta tvoje nemoc jmenuje ale mel bys ses fakt zacat lecit je to fakt vazna mentalni porucha. za celou diskuzi si nikde nepripustil ze bys uvedl nepresnou informaci nebo se nedej boze zmylil. v prvni pulce prispevku pises lzi a v druhe polovine absolutni nesmysli. ale tim "prikladem" si fakt zabil.   

Nahlásit jako SPAM
IP: 77.92.213.–
Kit+11
Guru
2. 7. 2014   #143
-
0
-

#142 p3can
Co se ti na něm nelíbí? Nevidím žádný argument. V příkladu mám 4 settery a 3 gettery, které pracují s modelem.

Kontrolní otázka: Jak jsi ty pochopil význam těch několika vět z příspěvku #140 ekral?

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Flowy0
Věrný člen
2. 7. 2014   #144
-
0
-

ono to tu je z velkej casti argumentfree ...

Nahlásit jako SPAM
IP: 91.148.1.–
https://github.com/Flowy
KIIV+42
God of flame
2. 7. 2014   #145
-
+3
-
Zajímavé

#143 Kit
argumentu tu moc neni .. same pseudoargumenty jako:

odkazovani se na vyssi autoritu (ale zamlceni toho, ze pouziti getteru/setteru nevylucuje, kdyz to dava smysl),

vyhaneni kauzality do extremu "Kolem sebe vidím hromady kódu, ve kterém jsou gettery a settery (resp. properties) použity chybně." proto bys je kompletne zakazal (tady myslim neprehanim - takze by to mel byt jeste argument :D),

odbihani od tematu - cely c++ je spatne jen proto, ze nema GC, co na tom, ze je to relativne nizkourovnovej jazyk ne moc daleko od assembleru a nemit GC se s trochou snahy da bez problemu prezit (jen to predpoklada urcite schopnosti programatora)

nejspis by se toho naslo vic ale flamewary moc nectu :)

#142 p3can
ty tu mas samozrejme odskok k urazkam, coz je zbytecne.. (ja osobne tipuju, ze je to bude neco jako ucitel - taky nulova sebereflexe, nemoznost/neschopnost uznat jakoukoliv chybu a tak - ale muzu se samozrejme plest)

Nahlásit jako SPAM
IP: 62.168.56.–
Program vždy dělá to co naprogramujete, ne to co chcete...
Satik0
Stálý člen
2. 7. 2014   #146
-
0
-

#145 KIIV

ja osobne tipuju, ze je to bude neco jako ucitel - taky nulova sebereflexe, nemoznost/neschopnost uznat jakoukoliv chybu a tak

Bingo :)

Nahlásit jako SPAM
IP: 86.49.188.–
Kit+11
Guru
2. 7. 2014   #147
-
0
-

#146 Satik
#145 KIIV
Učitel by asi nenapsal "vykend". Pochybuji, že p3can je učitelem.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
2. 7. 2014   #148
-
0
-

#141 Kit

Však je to prosté. OOP má svá pravidla, která stanovují chování mezi objekty, ale z každého pravidla mohou existovat výjimky. Základním pravidlem je umístit chování objektu dovnitř objektu. Pokud však máme více vrstev, můžeme toto pravidlo částečně porušit a tam, kde to potřebujeme, můžeme oddělit chování (metody) od dat, ale se souvisejícími daty (relací) bychom měli pracovat současně.

No konečně se shodneme. Poslal jsi odkaz na článek od Fowlera, který gettery právě z toho důvodu obhajuje, Sám máš v příkladu getter. Explicitně tam píše:

There are too many times when objects do need to collaborate by exchanging data, which leads to genuine needs for getters.

A to přímo odpovídá co píše Anders Hejlsberg.

We just think the time is right for a language that makes it easier to create components. Developers are building software components these days. They're not building monolithic applications or monolithic class libraries. Everyone is building components that inherit from some base component provided by some hosting environment. These components override some methods and properties, and they handle some events, and put the components back in. It's key to have those concepts be first class.

Takže tadáááá :D, všechno do sebe zapadadá. Protože SW v dnešní době už není monolitický blok, ale napak je rozdělený do vrstev a komunikujících komponent, tak přesně tak jak píše Fowler, je dobré mít přímo podporu properties v jazyce.

Nahlásit jako SPAM
IP: 195.113.99.–
Satik0
Stálý člen
2. 7. 2014   #149
-
0
-

#147 Kit

Pokud jsi nepochopil, že ten text

(ja osobne tipuju, ze je to bude neco jako ucitel - taky nulova sebereflexe, nemoznost/neschopnost uznat jakoukoliv chybu a tak - ale muzu se samozrejme plest)

 se vztahuje na tebe, tak jsme možná u jádra pudla - problém s neporozuměním psanému textu :)

Nahlásit jako SPAM
IP: 86.49.188.–
ekral
~ Anonymní uživatel
41 příspěvků
2. 7. 2014   #150
-
0
-

#146 Satik
#145 KIIV

p3can měl z hlediska odbornosti vše vždy správně. Kde jste byli, když kit poslal článek který prý gettery kritizuje, když tam naopak Fowler dokazuje že gettery jsou opravdu užitečné. Kde jste byly, když kit  sice vůbec nevěděl jak prakticky funguje MVVM, ale už ho kritizoval protože je od Microsoftu. Kde jste byli, když si kit pletl PM a MVP. Kde jste byli když kit tvrdil, že MVC není GUI architektonický vzor? Kde jste byli, když Satik psal nesmysly o populitsitkých properies, když důvodem properties v c# jsou právě vrstvy sw, tak jak píše fowler?

Hlavně ale, když někdo napíše výkend, tak jste hned hrozně chytří. Nedivím se, že to p3can už nevydržel., ale učit by p3can stopro měl :).

Nahlásit jako SPAM
IP: 195.113.99.–
Satik0
Stálý člen
2. 7. 2014   #151
-
0
-

#150 ekral

Viz můj předchozí příspěvek ;)

Nahlásit jako SPAM
IP: 86.49.188.–
KIIV+42
God of flame
2. 7. 2014   #152
-
0
-

se koukam musim vyjadrovat naprosto explicitne: ten ucitel byl samozrejme na kita :D

Nahlásit jako SPAM
IP: 62.168.56.–
Program vždy dělá to co naprogramujete, ne to co chcete...
ekral
~ Anonymní uživatel
41 příspěvků
2. 7. 2014   #153
-
0
-

#150 ekral
Uff, no už mně to taky ujelo, taky sem pochopil že ten učitel je na p3cana. Kit mně právě vždycky překvapí tím, že často má pravdu a správný pohled, ale není to vždy a potom je ta diskuse složitá. Ale na druhou stranu je to docela inspirující.

Nahlásit jako SPAM
IP: 195.113.99.–
Satik0
Stálý člen
2. 7. 2014   #154
-
0
-

#152 KIIV

Však ten tvůj příspěvek je jasný, pokud si to člověk pořádně přečte - reagoval jsi v druhé osobě na p3cana, který reagoval na Kita a pak tu poznámku v závorce jsi psal ve třetí osobě - z toho je (alespoň pro mě) patrné hned, že ta poznámka v závorce byla na Kita.

Ale je pravda, že pokud má někdo horší jazykový cit, nemusí to v tom hned vidět :)

Nahlásit jako SPAM
IP: 86.49.188.–
Kit+11
Guru
2. 7. 2014   #155
-
0
-

#150 ekral
Ten Fowlerův článek jsem poslal zcela záměrně, protože to je jeden z mála jeho článků, kde gettery a settery připouští a zdůvodňuje proč.

There's some sense to this argument, and I certainly suggest that you shouldn't write accessors until you really need them, but it also brings in the danger of missing the point of encapsulation.

neboli že bychom neměli používat g/s, dokud je skutečně nepotřebujeme a že přináší rizika v porušení zapouzdření. Slovo "shouldn't" znamená "neměli bychom". Neznamená to "nesmíme", ale také to neznamená, že bychom to měli porušovat kdykoli se nám zlíbí a vždy bychom si tato rizika měli uvědomit.

BTW: Nemyslím si, že by to p3can nevydržel. Určitě šel spát a ráno se tady zase objeví.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Kit+11
Guru
2. 7. 2014   #156
-
-1
-
Mimo téma

#154 Satik
Vidím, že s chápáním psaného textu jsi na tom ještě hůř než já. Fak si myslíš, že jsem nepochopil, že je to mířeno na mne?

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Satik0
Stálý člen
2. 7. 2014   #157
-
0
-

#156 Kit

Pak nevím, proč jsi na to odpověděl to, co jsi odpověděl, ironie z toho moc cítit nebyla :).

Nahlásit jako SPAM
IP: 86.49.188.–
Kit+11
Guru
2. 7. 2014   #158
-
0
-

#157 Satik
Prostě ta ironie byla tak jemná, že jsi ji ani nepocítil. Zkus se s tím smířit.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
2. 7. 2014   #159
-
0
-

#155 Kit

neboli že bychom neměli používat g/s, dokud je skutečně nepotřebujeme a že přináší rizika v porušení zapouzdření. Slovo "shouldn't" znamená "neměli bychom". Neznamená to "nesmíme", ale také to neznamená, že bychom to měli porušovat kdykoli se nám zlíbí a vždy bychom si tato rizika měli uvědomit.

No jo, ale to že bysme je neměli používat zbytečně, přece nezmená, že bysme je neměli používat vůbec.

Už se opakuju, ale ještě jednou doplňuju jak to pokračuje. Jako uznat svou chybu, není ostuda.

I have a lot of sympathy with this motivation, but I fear that just telling people to avoid getters is a rather blunt tool. There are too many times when objects do need to collaborate by exchanging data, which leads to genuine needs for getters.

A nakonec ještě jednou závěr:

Allocation of behavior between objects is the essence of object-oriented design, so like any design, there isn't a hard and fast rule - rather a judging of trade-offs. Putting the behavior in the same class as the data, what Craig Larman calls "Information Expert", is the first choice to consider. But it isn't the only route. Layering often trumps this, many of the Gang of Four patterns separate data from behavior for particular needs. A good rule of thumb is that things that change together should be together. Data and the behavior that uses it often change together, but often you see other groupings that matter more.

Jinýma slovama, gettery mají v kódu své dané místo, Properties jsou v c# proto, protože je to od začátku navržený jazyk, který předpokládá, že moderní SW se skládá z různých více či méně závislých resp. nezávislých komponent a není to jen jeden dlouhý blok programu. Příkladem toho je MVVM.  Ale tahle debata je desítky let stará. Já ti tu jenom vysvětluji motivaci tvůrců c#, která je paradoxně podpořená tím co píše fowler v článku, který jsi sám poslal.

Pokud máš tvořit složitejší systém, který používá víc různých komponent od různých autorů, často v různých jazycích a různých platformách, tak si myslím, že je užitečné aby si objekty předávaly data. Properties tam potom mají své uplatnění s spousta programátorů jsou rádi, že je c# tímto způsobem navržený. Pokud píšeš sám monolitický SW bez jakýchkoliv externích komponent sám, tak chápu, že smysl properties nebo getterů nikde nevidíš.

Nahlásit jako SPAM
IP: 195.178.90.–
p3can
~ Anonymní uživatel
312 příspěvků
2. 7. 2014   #160
-
0
-

to KIIV:

flamewary moc nectu...

hlavne ze mas titul "God of flame"    (ironie)

jako fakt me namychne kdyz nekdo napise ze C#,MS,WIN, cokoli jineho co je komercni, je naho... a spatne a nerekne ani duvod nebo neco co se da povazovat za "logicky" argument.

tady vesmes obhajuju C# kdezto v jinem topicu (tu na foru, starem asi tyden) paradoxne pisu ze C# je nepouzitely pro "performance critical" aplikace.

to KIT:

ty fakt myslis ten kod vazne joo ? nejenom ze vubec nevis jak se pracuje s g/s ale v tom tvem kodu dokonce postradam zaklady logickeho mysleni. normalne se problem implementoval:

    public interface IEntity
    {
        //metoda vraci komplexni objekt ValidateResult coz je kolekce chyb a jejich popis
        object Validate();
    }
    public class Customer:IEntity
    {
        public string Name { get; set; }
        public string Surname { get; set; }
        public string Title { get; set; }
        public string HomeNumber { get; set; }
        public string WorkNumber { get; set; }
        public object Validate()
        {
            return null;
        }
    }


objekt muze skutecne existovat v tvem "nekonzistentnim stavu" ale pred kazdou dulezitou operaci se zavola validate ktere "zastavi" cinost pokud je objekt v nekonzistentnim stavu.

ale na druhou stranu tys vytvoril toto: (jedna z moznych implementaci tveho kodu)

    public class Name
    {
        private string name;
        private string surname;
        private string title;

        public Name(string name, string surname, string title)
        {
            this.name = name;
            this.surname = surname;
            this.title = title;
        }

        public override string ToString()
        {
            return name + surname + title;
        }
    }

    //nejasne jestli je phone base class
    public abstract class Phone
    {
        protected string number;

        protected Phone(string number)
        {
            this.number = number;
        }

        public override string ToString()
        {
            return number;
        }
    }

    public class PhoneHome : Phone
    {
        public PhoneHome(string number) : base(number)
        {
        }
    }

    public class PhoneWork:Phone
    {
        public PhoneWork(string number) : base(number)
        {
        }
    }

    public class Customer
    {
        private Name _name;
        private Phone home;
        private Phone work;

        public void Set(Name name)
        {
            this._name = name;
        }
        //nejasne jestli se jedna o pretizeni nebo o velky switch uvnitr add
        public void add(PhoneHome home)
        {
            this.home = home;
        }
        public void add(PhoneWork work)
        {
            this.work = work;
        }

        public string name()
        {
            return this._name.ToString();
        }
        public string phone()
        {
            return this.home.ToString();
        }
        public string phoneHome()
        {
            return this.work.ToString();
        }

    }

vynechal jsem radek s bill protoze tam byla nejasna vazba na ostatni objekty.

co se ovsem tyka tveho kodu tak bravo.

1. vymyslet kompozitni typ pro kazdou polozku je opravdu unikatni napad. takto znemoznil vyuzit standartni razeni/hledani pro typ string ktery si wrapnul do sve tridy ktera ted musi pretizit operatory porovnavani.

2. pojmenovat metody add,set nedava absolutne zadny smysl. clovek co by to po tobe celt nema sanci udelat s tvym kodem bez dokumentace cokoliv.

3. nevim jak je to v jave ale mam takovy dojem ze tim ze si nepouzil standartni jmene konvence getproperty setproperty, tak si narusil nejaky ten vnitrni framework, ktery umoznoval "jednoduche" sparovani modelu s view, coz znamena, ze musis napsat svoji vlastni mezivrstvu. (nejsem si jisty jak je to v jave, ale v .NET je to tak urcite)

4. kde me se podari zachytit problem pomoci 1-2 trid, ty pouzijest pretezovani, dedicnost a 4 a vice trid. myslim ze OOP neznamena cim vic trid tim lip   

Nektere veci v "moji implementaci tveho kodu"  jdou resit jinak ale nepredpokladam ze by to ubralo na komplexnosti reseni.

Tyjo doufam ze nejsi pan ucitel/profesor. Jednoho takoveho podobneho uz mame totiz ve Zline   

Nahlásit jako SPAM
IP: 77.92.213.–
KIIV+42
God of flame
2. 7. 2014   #161
-
0
-

#160 p3can
tak sem tu 6 let a teprve atakuju nejakejch 7000 zprav... to neni tak strasny :D

A to jak ty levely pojmenoval Curo, to uz moc neovlivnim :)

a ten kod je samozrejme luxus :) objekty za jakoukoliv cenu, ikdyz se dela jednoducha struktura (pripadne muze podedit od vsech tech class polozky primo do customera :))

Nahlásit jako SPAM
IP: 62.168.56.–
Program vždy dělá to co naprogramujete, ne to co chcete...
Kit+11
Guru
2. 7. 2014   #162
-
0
-

#160 p3can
Máš tam několik chyb

  1. Řazení ani vyhledávání nepotřebuji. Na to mám databázi
  2. Název set je pro setter (ano, občas ho také použiji), add je standardní název metody pro přidání do kolekce
  3. Použil jsem standardní názvy
  4. Neuvažuješ o tom, že by zákazník nemusel mít žádný telefon nebo mohl mít dva telefony do zaměstnání
  5. Počet tříd na malém příkladu je irelevantní. Třídy Name a Phone s podtřídami jsou recyklovatelné, použijí se tedy na více místech programu
  6. Metoda phone() a další podobné metody jsou úplné nesmysly. Proč by metoda phone() měla vracet string, když čísla telefonů jsou typu PhoneList? Vždyť ta metoda neví, že ta telefonní čísla budu chtít tisknout. To by se ta metoda musela jmenovat phoneString()

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
2. 7. 2014   #163
-
0
-

#162 Kit

Řazení ani vyhledávání nepotřebuji. Na to mám databázi

Co ? To snad nemyslíš vážně?

Nahlásit jako SPAM
IP: 195.178.90.–
Kit+11
Guru
2. 7. 2014   #164
-
0
-

#163 ekral
Viděl jsem už pár exotů, kteří si z databáze vytáhli celou tabulku a pak se ji teprve snažili řadit a prohledávat.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
2. 7. 2014   #165
-
0
-

#162 Kit
1. aha takze kdyz chci aby me program zobrazil zakazniky s prijmenim "novak" a pak kdyz me jich zobrazi v gui tabulce 15 pod sebou tak si uvedomim ze je chci seradit podle jmena tak podle tebe sou to 2 dotazy do db ? misto jednoho dotazu do db a zavolanim sort na vysledek ?

2. to znamena ze trida customer dedi od kolekce?

4,5 tyjo sry hned to upravim

muj kod:

    public interface IEntity
    {
        //metoda vraci komplexni objekt ValidateResult coz je kolekce chyb a jejich popis
        object Validate();
    }
    public class Customer:IEntity
    {
        public string Name { get; set; }
        public string Surname { get; set; }
        public string Title { get; set; }
        /// <summary>
        /// Contains phonenumbers separed by ; or ,
        /// </summary>
        public string HomeNumber { get; set; }
        /// <summary>
        /// Contains phonenumbers separed by ; or ,
        /// </summary>
        public string WorkNumber { get; set; }
        public object Validate()
        {
            return null;
        }
    }


sumary se zobrazuje v naseptavaci kdyz programujes jen kdyby nahodou :) (alternativne si u tech cisel muzes domyslet List<string>)

a tvuj upraveny kod (bohuzel si nas neobdaril svoji vizi jak by to melo vypadat takze prikladam svoji)

    public class Name
    {
        private string name;
        private string surname;
        private string title;

        public Name(string name, string surname, string title)
        {
            this.name = name;
            this.surname = surname;
            this.title = title;
        }

        public override string ToString()
        {
            return name + surname + title;
        }
    }

    //nejasne jestli je phone base class
    public abstract class Phone
    {
        protected string number;

        protected Phone(string number)
        {
            this.number = number;
        }

        public override string ToString()
        {
            return number;
        }
    }

    public class PhoneHome : Phone
    {
        public PhoneHome(string number) : base(number)
        {
        }
    }

    public class PhoneWork:Phone
    {
        public PhoneWork(string number) : base(number)
        {
        }
    }

    public class PhoneList : List<Phone> { }

    //toto ma dedit primo od nejake kolekce ?
    public class Customer
    {
        private Name _name;
        private PhoneList home;
        private PhoneList work;

        public Customer()
        {
            home = new PhoneList();
            work = new PhoneList();
        }

        public void Set(Name name)
        {
            this._name = name;
        }
        //nejasne jestli se jedna o pretizeni nebo o velky switch uvnitr add
        public void add(PhoneHome home)
        {
            this.home.Add(home);
        }
        public void add(PhoneWork work)
        {
            this.work.Add(work);
        }

        public Name name()
        {
            return this._name;
        }
        public PhoneList phone()
        {
            return this.home;
        }
        public PhoneList phoneHome()
        {
            return this.work;
        }

    }
Nahlásit jako SPAM
IP: 77.92.213.–
Flowy0
Věrný člen
2. 7. 2014   #166
-
0
-

#165 p3can
phonework and phonehome ... lol

Nahlásit jako SPAM
IP: 84.47.11.–
https://github.com/Flowy
Kit+11
Guru
2. 7. 2014   #167
-
0
-

#166 Flowy
No co? Ty názvy jsem vymyslel hodinu po půlnoci, tak se nediv. Stejně to p3can blbě implementoval. Máš nějaké vhodnější názvy pro tyto metody?

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
p3can
~ Anonymní uživatel
312 příspěvků
2. 7. 2014   #168
-
0
-

#167 Kit
tak nam ukaz jak bys to implementoval   

Nahlásit jako SPAM
IP: 77.92.213.–
ekral
~ Anonymní uživatel
41 příspěvků
3. 7. 2014   #169
-
0
-

#167 Kit

No co? Ty názvy jsem vymyslel hodinu po půlnoci, tak se nediv. Stejně to p3can blbě implementoval. Máš nějaké vhodnější názvy pro tyto metody?

No možná jestli spíš není problém v tom, jak doslova plýtváš s třídama a podle mně nadužíváš dědičnost. Třída PhoneHome a PhoneWork se podle mně nebudou výrazně lišit, nebo dokonce je máš úplně stejné.

Nezapomeň, že opravdu budeš muset řešit u každé vlastní nadefinované třídy:

  • testování rovnosti objektů (jak jinak zjistíš, jestli jsou dvě telefonní čísla stejné?),
  • porovnání objektů například kvůli řazení,
  • kopírování (deep vs shallow copy), případně přesouvání objektů (move v c++11), 
  • serializaci,
  • bindování například v MVVM,
  • a mnoho dalších věcí o kterých v době návrhu třídy ani nemusíš tušit.

A opravdu jsi si jistý, že budeš chtít pokaždé měnit konstruktor kvůli DI aby jsi tam přidal novou závislost a i tak bys mohl skončit s desítkou závislostí, tak aby byl tvůj objekt použitelný i v jiných knihovnách a komponentách?

Nahlásit jako SPAM
IP: 195.178.90.–
sleepy
~ Anonymní uživatel
422 příspěvků
3. 7. 2014   #170
-
0
-

Nechce sa mi vobec citat cely thread, ale posledny post mi neda: Co je na plytvani objektami zle? Viac pamate ako je pocet telefonnych cisel ti to bez tak nezabere. Neviem ako funguje PhoneHome, PhoneWork, ale extendoval by som ich z phonu, ak kazdy ma mat nejaku rozsirenu funkcionalitu. No ale k niektorym bodom:

  • Testovanie rovnosti definujes hned pre phone v metode equals tak, ze phonenumber == o.phonenumber
  • Ako chces radit telefonne cisla, mozes radit uzivatelov podla mena, ale toto je uplna zbytocnost co si napisal, mozno ak by si mal premennu zastihnutelnost a podla nej
  • Zalezi co chces od kial kopirovat
  • Serializable
  • nepoznam
  • daj dalsie

Napises jeden kostruktor a das tam zavislosti od, ktorych objekt zavisi. Tak nech napr. existuje objekt MessageSender a MessageReciever, ktory vie nejakym sposobom poslat a prijat sms (toto by mohlo byt pre objekt MobilePhone, tu uz sa hodi extendnut). Pouzijes di na to aby si mu tam vlozil objekt MessageSender a MessageReciever. Na normalny telefon (Phone) by sa zase mohlo dat volat cize by mal obsahovat objekt CallProvider, tieto 3 objekty by mohli byt singletony pre celu klientsku aplikaciu (cize nie je nutnost mat pre kazdy phone novu instanciu, lebo vacsinou jeden user nevie telefonovat viac jak na jedno cislo sucastne). Ospravedlnujem sa za chyby a mozno je to troska vytrhnute z kontextu, ale nedalo mi nereagovat. Inak s tou dedicnostou je pravda, tam je treba byt opatrny dedia sa len tried, ktore su urobene na to aby sa z nich dedilo. Na ostatne veci su wrappery, odporucam precitat J. Bloch  Effective java.

Nahlásit jako SPAM
IP: 158.195.206.–
ekral
~ Anonymní uživatel
41 příspěvků
3. 7. 2014   #171
-
0
-

#170 sleepy

Je to na delší vysvětlování, ale nejde o tuhle konkrétní třídu, kde je to samozřejmě jednoduché. U toho příkladu jsem právě kritizoval, že si kit hned udělal base class Phone a od ní dědí podle mně uplně zbytečně. Jinak nepíšu že je špatné plývání objekty, ale třídami a dědičností!!

Jinak tahle debata sklouzla k diskusi o getterech a properties. Kdy kit tvdí, že jsou nanic a díky použití správného návrhu je nemusíš používá, zatímco já, Fowler a další zase tvrdí, že to není tak jednouché není a že pro předávání dat mezi různými vrstavami, což je příklad třeba MVVM, jsou gettery a properties užitečné.

Jinak samozřejmě že, když je to tvůj kód, tak si můžeš pomocí DI vkládat různé komponenty. Ale co když to není tvůj kód a používáš už hotové komponenty od kterých nemůžeš dědit. a kit tvrdí, že nemůžeš použít getter, nebo obecně, že objekt nemá co zpřístupňovat svoje data ani pro čtení. Ale upřímně, mně osobně by se nechtělo měnit kód a vymýšlet nový interface a dělat DI pokaždé, když použiju novou komponentu.

Jinak další příklad je, že mám MVVM v c# a díky monu mi běží nativně na Androidu, ios, osx, linuxu, WP, W, WRT, Xbox atd. A pokaždké chci zobrazit ModelView na jiné technologii a předem ani nevím jaké techologie to budou, ale zároveň mají svoje specifika (pro android je to vetsinou Activita, pro iOS UIVIewController, pro WP8 Page, pro WPF Page). Takže MVVM to řeší tak, že definuje jednouché rozhraní pro notifikaci a data jsou vystavená pomocí properties nebo v jave pomocí getterů. DI je sice fajn, ale gettery tím nenahradíš, někdy jsou prostě situace, kdy si potřebuješ vystavit data pro čtení nebo pro zápis.

Jinak tady je ukázka MVVM pro javu, ale myslím, že jen pro jejich UI controly.

http://www.zkoss.org/zkdemo/getting_started/mvvm

Nahlásit jako SPAM
IP: 195.178.90.–
sleepy
~ Anonymní uživatel
422 příspěvků
3. 7. 2014   #172
-
-1
-
Mimo téma

#171 ekral
To hadam netvrdi, ze gettery su zle. Vsak to je jedina moznost ako komunikovat s danym objektom. Tam ani DI nepomaha, jedine co zostava je reflexia. Kamarat pise pluginy pre jednu nemenovanu hru, ktora vyuziva obfuskaciu a ukazoval mi tie vtipi (vlastne jedinu moznost ako to vyuzivat) ako niektore veci funguju: if(method.getName().equals("save")){...}. No to DI je prave dobre ak pouzivas niekoho ineho kod. Alebo ak vytvaras api, kniznicu. Mozes vtedy bez problemov testovat a pouzivat Mocked objekty. Nie si jednoducho odkazany na to aby si vedel co implementator pouzije a davas implementatorvi istu volnost. Keby v objekte neboli gettery, tak ten objekt je nepouzitelny. V jave je lepsie snazit sa vytvarat immutable objekty, maju svoje vyhody, ale v mnohych pripadoch sa to neda, alebo by to bolo prilis narocne a zbytocne. Napriklad vytvarat instanciu User za kazdym, ked chces zmenit jeho telefonne cislo. Ale za to telefonnec cislo mozes s kludnym svedomim urobit immutable, lebo v okamiziku ked ho zmenis je to uz ine telefonne cislo. S tou dedicnostou mas tiez pravdu. Dedit len to co sa dedit ma.

Nahlásit jako SPAM
IP: 158.195.206.–
ekral
~ Anonymní uživatel
41 příspěvků
3. 7. 2014   #173
-
0
-

#172 sleepy
No kit a flowy (omlouvám se satikovi, spletl jsem si nicky) to v tady tom vlákně tvrdí že gettery jsou přímo z programátorského pekla :D. I když flowy psal, že nejsou zlé až tak, ale jenom trochu. Jako všechno se dá použít špatně, dědičnost i gettery.

Píšeš to podle mně uplně přesně, jak s tím DI, tak gettery a souhlasím s tím   

Nahlásit jako SPAM
IP: 195.178.90.–
Flowy0
Věrný člen
3. 7. 2014   #174
-
+1
-
Zajímavé
Kit +

#173 ekral
pise uplne kraviny ... pre efektivne programovanie niesu accessory vobec potrebne a spomaluju/ztazuju pracu ... su situacie kedy su nutnostou (vo vecsine aplikacii) ale su to pripady kedy aplikacia komunikuje s okolim a tu sa vecsinou nedaju robit upravy cize ich implementacia neni problem aj v getteroch

sleepy ... len k tej volnosti ... oficialne sa to vola prenasanie zodpovednosti a neni to velmi vhodny vzor pre programovanie

Nahlásit jako SPAM
IP: 84.47.11.–
https://github.com/Flowy
ekral
~ Anonymní uživatel
41 příspěvků
3. 7. 2014   #175
-
0
-

#174 Flowy

No jasně, v nějakém vysněném světě, kde program nekomunikuje s okolím opravdu není potřeba mít gettery :D. S tím souhlasím, ale radši se řídím podle reality a ne podle ideálu.

Nahlásit jako SPAM
IP: 195.178.90.–
sleepy
~ Anonymní uživatel
422 příspěvků
3. 7. 2014   #176
-
0
-

#174 Flowy
Tak to mi vysvetli ako chces effektive pristupit k fieldom objektu, bez accesorov? Lebo vela krat dany objekt nevie s danym fieldom urobit to co potrebujes aby s nim urobil a bolo by len matuce keby to robit vedel. V okamziku, ked mas interfejsi a pod. hluposti mozes sa posunut na trosku vyssiu uroven programovania. A o tom zatazovani mi mozes rozpravat, ak to co sa deje s danym fieldom trva radovo o vela dlhsie ako samotny pristup. Hmm DI mozno nie je najlepsi model, ale ked robis na niecom vecsom tak si celkom rad, ze take nieco ako DI existuje. A kedze predpokladam, ze si pises testy, tak podobne.

Nahlásit jako SPAM
IP: 158.195.206.–
sleepy
~ Anonymní uživatel
422 příspěvků
3. 7. 2014   #177
-
0
-

Ospravedlnujem sa, ale take veci ako mat field nastaveny ako private som neuvazoval a ani to nepouzivam.

Nahlásit jako SPAM
IP: 158.195.206.–
Flowy0
Věrný člen
4. 7. 2014   #178
-
+1
-
Zajímavé
Kit +

#176 sleepy
okrem nejakych patternov neni dovod pouzivat accessory ... a vzory v ktorych sa pouzivaju su vecsinou tak prekrite ze to nerobi problem ... navyse pri komunikacii s okolim moc prilezitosti na zmenu neni a ked pride zmena tak sa vecsinou musi aj tak menit cela logika cize v tomto pripade to tiez neni problem ...

mne je jedno co pouzivas alebo nie ... ked zistis ze je to zle tak to aj tak nenapises

Nahlásit jako SPAM
IP: 84.47.11.–
https://github.com/Flowy
ekral
~ Anonymní uživatel
41 příspěvků
4. 7. 2014   #179
-
0
-

#178 Flowy

avyse pri komunikacii s okolim moc prilezitosti na zmenu neni a ked pride zmena tak sa vecsinou musi aj tak menit cela logika cize v tomto pripade to tiez neni problem ...

Tohle jde úplně proti veškerému vývoji v návrhu aplikací za posledních 30 let. Samozřejmě, že nemusíš a ani nechceš měnit aplikační logiku z důvodu jiné komunikace s okolím. 

Ale jinak souhlasím, pokud chceš pokaždé měnit aplikační logiku aplikace, když se změní komunikace s okolím aplikace, tak opravdu memusíš gettery ani properties používat. 

Nahlásit jako SPAM
IP: 195.113.99.–
Kit+11
Guru
4. 7. 2014   #180
-
0
-
Nerozhodně

#179 ekral
Tohle jde úplně proti veškerému vývoji v návrhu aplikací za posledních 30 let. Samozřejmě, že nemusíš a ani nechceš měnit aplikační logiku z důvodu jiné komunikace s okolím. 

Tohle jde úplně proti návrhovým principům SOLID. Konkrétní musí záviset na abstraktním, implementace musí záviset na rozhraní. Rozhraní je kontraktem mezi vrstvami aplikace.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
ekral
~ Anonymní uživatel
41 příspěvků
4. 7. 2014   #181
-
0
-

#180 Kit

Tohle jde úplně proti návrhovým principům SOLID. Konkrétní musí záviset na abstraktním, implementace musí záviset na rozhraní. Rozhraní je kontraktem mezi vrstvami aplikace.

Konečně se shodneme, jenom jsi to měl napsat přímo Flowymu. Jako měnit aplikační logiku pokaždé když se mění komunikace s okolím objektu je nejenom proti principům SOLID, ale i proti zdravému rozumu.

Jinak rozhraní je kontraktem mezi vrstvami aplikace a gettery nebo properties jsou součástí tohoto rozhraní, tím zase potvrzuješ užitečnost getterů, tak jak to popisuje i Fowler.

Nahlásit jako SPAM
IP: 195.178.90.–
Flowy0
Věrný člen
4. 7. 2014   #182
-
+1
-
Zajímavé
Kit +

#180 Kit
tymto by som to uzavrel ...

Nahlásit jako SPAM
IP: 91.148.1.–
https://github.com/Flowy
ekral
~ Anonymní uživatel
41 příspěvků
4. 7. 2014   #183
-
0
-

#182 Flowy

Pokud je závěr, že properties jsou užitečně v rozhraních mezi vrstvami a c# je jazyk navržený pro práci s komponentami, tak souhlasím.

Nahlásit jako SPAM
IP: 195.178.90.–
Flowy0
Věrný člen
4. 7. 2014   #184
-
0
-

ako chces ...

Nahlásit jako SPAM
IP: 84.47.11.–
https://github.com/Flowy
Zjistit počet nových příspěvků

Přidej příspěvek

Toto téma je starší jak čtvrt roku – přidej svůj příspěvek jen tehdy, máš-li k tématu opravdu co říct!

Ano, opravdu chci reagovat → zobrazí formulář pro přidání příspěvku

×Vložení zdrojáku

×Vložení obrázku

Vložit URL obrázku Vybrat obrázek na disku
Vlož URL adresu obrázku:
Klikni a vyber obrázek z počítače:

×Vložení videa

Aktuálně jsou podporována videa ze serverů YouTube, Vimeo a Dailymotion.
×
 
Podporujeme Gravatara.
Zadej URL adresu Avatara (40 x 40 px) nebo emailovou adresu pro použití Gravatara.
Email nikam neukládáme, po získání Gravatara je zahozen.
-
Pravidla pro psaní příspěvků, používej diakritiku. ENTER pro nový odstavec, SHIFT + ENTER pro nový řádek.
Sledovat nové příspěvky (pouze pro přihlášené)
Sleduj vlákno a v případě přidání nového příspěvku o tom budeš vědět mezi prvními.
Reaguješ na příspěvek:

Uživatelé prohlížející si toto vlákno

Uživatelé on-line: 0 registrovaných, 37 hostů

Podobná vlákna

Jak pokračovat s javou — založil Jan Klimeš

Jak začít s Javou pro mobily — založil beachboy

Pomoooc s javou — založil prosim moc o pomoooc

Problém s javou na serveru — založil biggycz

Moderátoři diskuze

 

Hostujeme u Českého hostingu       ISSN 1801-1586       ⇡ Nahoru Webtea.cz logo © 20032016 Programujte.com
Zasadilo a pěstuje Webtea.cz, šéfredaktor Lukáš Churý