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

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? :-)

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)

#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.

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.

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, ...).

#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ří.

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

#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.

#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

#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í :)

#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í.

#11 Kit
Destruktory nejsou ani v C#

Odkdy? :)

http://msdn.microsoft.com/cs-cz/library/66x5fx1b.aspx

#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.

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

#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.

#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#?

#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

#17 KIIV
V Jave neznamenkova cisla nejsou :) 

#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?

#18 Satik
V Jave neznamenkova cisla nejsou :)

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

#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

#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á :)

#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.

#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++.

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

#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.

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.

#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ě.

#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.

#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.

#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 :-)

#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

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 :-)

#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é.

#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.

#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..

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

#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.

#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á.

#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.

#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íš.

#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)

#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)

#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.

#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á.

#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

#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.

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

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

Raději:

diskuse.close();

ať je to správně OOP :)

#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

#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.

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

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 :)

#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.

#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.

#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++.

#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.

#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čí?

#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ě.

#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.

#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í.

#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ř.

#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.

#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í.

#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 ?

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

#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 ...

#65 p3can
Property, které jsou v C# vyzdvihovány, jsou v jiných jazycích zatracovány. Měly by být zatraceny i v C#, protože narušují správné pochopení OOP. Je to jen nevhodně používaný syntaktický cukr.

http://www.javaworld.com/article/2073723/core-java/why-getter-and-setter-methods-are-evil.html

#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.

#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.

#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 ?

#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?

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.

#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.

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)

#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ý.

    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.

#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é.

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

#79 p3can
Ta třída Planety ti nejde otevřít?

Zkusil jsem tu tvou třídu přepsat do Javy. Moc se mi nelíbí, stále je tam moc zbytečností.

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

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 ...

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

#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   .

#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í.

#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.

#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í.

#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 ?   

#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í.

#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.

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.

#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.

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

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).

#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.

#94 p3can
Nic jsi mi nevyvrátil.

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.

#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?

#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

?

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

#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.

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

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 :))

#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; }
}

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; }
}

#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.

#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.

#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.

#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");

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

Clovek adam = new Clovek("Adam");

#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");

#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ě?

#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.

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

#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.).

#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.

#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é.

#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í.

#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šíš.

#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é.

#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.

#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?

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.

#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ší.

#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.

#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.

#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. 

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

#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. 

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.

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.

#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

#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.

#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.

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.

#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 ...)

#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.

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   

#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.

#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.

#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.

#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.

#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.   

#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?

ono to tu je z velkej casti argumentfree ...

#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)

#145 KIIV

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

Bingo :)

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

#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.

#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 :)

#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 :).