well played.

:o))))))))))))))))))

Hát ezen jót röhögtem :)

epic :)

ez hatalmas! :D

Brilliáns :-)))

Én .netben dolgozom, mégis röhögtem :-D

Marhaság.

A filmecske tenyleg nagyon jo. A masik oldalrol is jo letne latni egy ilyen szinvonalasat :).

királyos! a nagy bejelentésnél a windos hang nagyon ottvan:D

A zenéi: Amerikai szépség, Rekviem egy álomért, az utolsó pedig... mi is? (Nem ugrik be.)

@KaPé: Én sem írtam Java kódot csak .netet az utóbbi 5 évben, de (vagy épp azért) nagyon tetszett.

Hölgyeim és uraim, most látták bizonyítékát, hogy a menedzselt kód háborút a Microsoft nyerte. (Ha a közelmúltban próbálták letölteni a Java SE JDK 6-ot az Oracle csodálatos honlapjáról, és két-három próbálkozásból egyszer sikerült, már sejthették ezt az eredményt.)

Lenny Linux LOL :)

Directed by Alan Smithee, LOOOL!!

Azért jó, hogy Index címlap lett ebből, miközben az elmúlt három hétben már gyakorlatilag minden magyar informatikai oldalon és blogon felbukkant ez a videó, néhol többször is.

Mókás :)

Az viszont szomorú, hogy a java-nak lassan már csak ez marad, technikailag egyre nagyobb a lemaradása a .net-hez.

Ez elég szar volt. Az alapszituáció pont az, hogy a Java volt monopol-helyzetben a menedzselt-kód világában, és a .Net a rebbelis, nyíló értelem.

Persze erre mondhatnátok azt, hogy nem értem a viccet. De értem, csak ez nem az. :)

Egy kicsit régies felfogás. A Java nyilván "jobb" -főleg a tudományos számításokban - mint a csak Windows alatt használható gyerekes dolgok. Viszont szép lassan rá kellene szokni a Pythonra. (Vagy már rá kellett volna szokni fúkák, lehet a Jythonnnal kezdeni.)

A Java helyett Pythonnal kellett volna csinálni.

@Laslow: Turtles: Happy Together. Sorozatokban időnként hallható, de biztosan volt már több nagyjátékfilmben is.

@Poll: mármint a J2EE-nek technikailag nő a lemaradása ugye a .NET-hez, ezt akartad ugye mondani? Részleteznéd a lemaradás mibenlétét?

@NemoKapitany: na itt a másik szakértő. Java meg a tudományos számítások...

@Jacko__: igen, a Java volt először, aztán lett a J2EE, és a .NET a Microsoft próbálkozása volt a J2EE konkurrencia létrehozására.

Ha valaki hozzászól már szakértőként, ugyan vegye már a fáradtságot, és ne a Java nyelvet hasonlítsa a .NET-hez, léccilécci. :S

@saclos: igen, az elég kemény ütés volt, a felvásárlás. Bár mivel Larry Elisonnak nem szíve csücske a MS, és hülye lenne átengedni a piacot, valszeg marad minden a régiben.

Huhh... ez a norvég szöveg alatta nagyon gáz :-)

@Edgar: Köszönöm, azóta már sikerült megtalálnom. Az Egy szoknya, egy szoknya c. filmből ismertem.

@NemoKapitany: "A Java nyilván "jobb" -főleg a tudományos számításokban"

Tudományos számításokhoz csontra optimalizált Intel Compiler illik és nem tetűlassú managed bullshit.

Ahogy meg lehet saccolni az elmúlt évtizedekből, a hardvergyártás mind sebességben mind sokféleségben és mennyiségbe messze el fog húzni a szoftverfejlesztéstől. Ezt tekintve elvileg már a közeli jövőben a virtualizáció és az arra való fejlesztés nagyobb szerepet kap ami az Oracle és a Java területe.

Sayin Java is nice cos it works on all OS's is like sayin anal sex is nice cos it works on all genders

Hát nem könnyű oracle-nek lenni, java, virtualbox, solaris, mysql. Csupa kétes dolgon ülnek, erős riválisokkal.

itt balfaxkodik két gyártó, hogy melyiknek van jobb platormja, miközben az Apple mindent visz az új szifonnal.

DotNet vagy Java? Ma már nem ez a kérédés, hanem, hogy Apple vagy mi más!

@PuruttyaIrto: hogy ezen a blogon mennyi szakember van...

csak hogy tisztaba tegyunk par dolgot:
a .NET az egy virtualis gep, ami nagyon sokfele nyelven irodott programot tud futtatni, tobbek kozott VisualC++, C#, es a VisualBasic is .NET bytekodra fordul. nativ .NET bytekodban szerintem igen kevesen programoznak.
a Java egy programozasi nyelv, leginkabb a jvm nevu virtualis gepen fut, de lefordithato .NET platformra is, sot letezik olyan compiler is, ami nativ bytekodot fordit, persze ekkor a forditashoz hasznalt OS-en fog csak futni a kod.
az Apple pedig egy szoftver/hardver gyarto ceg, van sokfele termekuk, de virtualis gepet, adatbazis szervert nem gyartanak, ezenkivul sajat programnyelvuk sincs, ami szeles korben elterjedt volna.

szoval ha osszehasonlitani akarsz, akkor a jvm-et hasonlitsd ossze a .NET-tel, a Javat a C#-al, es kozben keress ezeknek megfelelo, Apple altal szallitott megoldast.

A Java tré. Nem vok programozó, csak időnként összeütök kisebb programocskákat ha szükségem van rá. Erre a .NET tökéletes. Express alatt elindítok egy Dialog projektet, rádobálom a szükséges vezérlőket, a megfelelő eseménynél beírom az elvégzendő dolgokat és csá. Kész az 1 MB-os progi amit mancika is tud használni. Win alá tökéletes.

@Mr. Finger: Ez hülyeség, de nagyon jól hangzik :-)

@kpityu2: Jé, 20 éve pont ezt mondták Delphi és C++ kapcsán. Ja, én nem vagyok asztalos, csak néha összeütök ezt-azt, erre a ... gép felesleges, nem értem minek gyártják. ???

@igazi hős: Aki win alá Javában fejleszt az mazochista. Lehet hogy linuxra és mobilra tökéletes, de win alatt nem ellenfele a .NET-nek.

@kpityu2: Lehet, hogy lerombolom a világképedet, de akik programokat írnak és nem programocskákat, azok szerveroldalra (is) fejlesztenek. Ott meg vagy MS az oprendszer vagy nem. Komolyabb hardveren a válasz jellemzően nem (bár egyértelműen zárkózik fel a MS).

Hehe...

@kpityu2: A tré talán erős kifejezés, de kliensoldalon vitathatatlanul +1. Én Javát szerettem volna, de első próbálkozásomat szárnyaszegte a TreeView, a másodikat pedig az XML kezelés. Lett helyette Visual C# Express, és újra arra koncentrálhattam, hogy mit csináljon a programom, nem pedig arra, hogy hogyan.

@saclos: Ja, és megpróbáltam portolni Linuxra, de belefutottam a WinForms nemtámogatottságába, valami ritka retek form designer formájában. Valaki azt mondta, az azóta elmúlt két év alatt a WinForms Monós támogatottsága sokat javult, de nem mostanában próbálom meg újra. Ja, hogy van Mono, tehát van .net, ami nem Windows alatt fut? Ennyit erről a filmről.

Phaidros, Martian:

Tipikus magyar "informatikai debilek" vagytok, akiknek - egyértelmű a szövegetekből - semmilyen képzettsége sincs.

A "tudományos számításokhoz csontra optimalizált Intel compiler" stb. Merrefelé vaze? Püspökladányban?

abszolút baromság:

Matlab, Octave, R, Maple, Python (numpy, scipy, matplotlib stb.) és csodálkozni fogsz, de még most is Fortran stb. ezekkel szoktak tud/mérnöki számításokat csinálni és Java-val vagy C++-al többnyire SWIG-gel összekapcsolni.
-------------------------------------------------
Phaidros:

Ide nincs is mit válaszolni, mert csak szellentettél egyet.

"Java és a tudományos számítások" írod: látszik hol élsz.

Volt már.
kocka.blog.hu/2010/07/01/java_vs_net

@NemoKapitany: fejlesztettél már 2D-s FFT-t realtime elvárásokkal? Nálunk sajnos elég hamar kiderült, nincs olyan, hogy "dobjunk össze valamit, úgyis elég erős a vas".
Persze kell a jó algoritmus (régebben használtam Fortrant is), különösen több magra érdekes... de az a lényeg, Java és .NET környezet nem igazán jött szóba.

Nagyon nagy cucc az a csaj seggén laptopozó csávó. Az nincs meg valakinek normális méretben?

Martian:

Most ennek mi az értelme? A kiindulásom az volt, hogy a Java(JDK) és .NET ellentétbe állítása nem elég helyes. Erre Te azt írod, hogy bizonyos esetekben egyik se ideális. És? Ki állította az ellenkezőjét?

A realtime alkalmazások mióta számítanak a tudományos számítások kategóriájába? Azok túlnyomórészt mérnöki számítások.

Ne vedd magadra, engem csak - feleslegesen - idegesít egy-két hozzászóló:

nem villamosmérnök_informatikus, mert ők már másodéven tanuják: Jelek és rendszerek, prediktív control stb. C++, Matlab, Octave

nem biológusok: genetikai programok; Octave, R, Sage

nem fizikusok: meg lehet nézni a Fortran könyvtárakat pl. a CERN honlapján

nem pénzügyi szakemberek: Statistica, R, Matlab (Finacial Toolbox) a tőzsdei számításokhoz és az elméleti kutatáshoz

Értelem nélkül - és jól látható képzettségi háttér nélkül - firkálgat itt a legtöbb emberke.

Persze lehet, hogy nekik van igazuk, végeredményben erre van ez a hely, irogatni, értelmezgetni "szabadon"; nem itt kell vitatkozni. Egészségükre.

@PuruttyaIrto: te jó ég... ezen a "hozzászóláson" a fejemet vertem a falba...

Azért a dologhoz hozzá kell tenni pár dolgot.

1. A SUN kb. a .NET feltűnéséig nem volt kimondottan az openszorsz híve, különös tekintettel a linuxra. Annyira nem, hogy a jre-ből és a jdk-ból nagyon-nagyon sokáig nem létezett hivatalos linuxos port. Az elsőt egy független szervezet hozta létre (blackdown.org), míg az első "hivatalos" portot a Borland valamikor a JBuilder első portolható verziójának kifejlesztése környékén. Szóval, igazán a SUN akkor kezdett el ebbe az irányba menni, amikor már látta hogy a linuxot igazán a JDK hiánya nem öli meg (és hogy nem igazán konkurencia neki az x86-os Solaris). Innentől kezdve ez a nagy legyünk nyíltak és szabadok duma elég vicces.

2. A SUN valóban nagy harcosa volt az openszorsznak a végére, csődbe is ment annak rendje és módja szerint. Az Oracle viszont nem annyira az ócsított dolgairól nevezetes.

Amúgy pedig a java nekem legalábbis erősen a C# nagypapájának tűnik. A javában már az elején volt pár érdekes tervezési koncepció (Pl. a property-k , operator overloading hiánya). Aztán a C# nyelvvel sokáig fej-fej mellett haladtak, bár a generics bevezetése már a javának nem annyira jól sikerült (csak nyelvi szinten valósította meg, bytecode szintén nem, így míg a C# kód sebességben is profitál a dologból, a java nem). Aztán a C# 3.0 a lambda expressions és az erre épülő LinQ bevezetésével szvsz fényévekre húzott el mellette. Innentől kezdve Pl. egy ORM esetén nem kell string alapon összerakni a szűrő feltételeket mint a HQL-ben illetve nem kell mindenféle Criteria API-hoz hasonló szerencsétlenségeket használni.

@kpityu2: Van Javára is Netbeans illetve Eclipse.
De az tény hogy valamit létrehozni javában kb. 5x annyi nyögvenyelősséget jelent. Ezért egy bank aminek nem tételek a fejlesztési költségek, viszont lényeges hogy 100 év múlva is változtatás nélkül használható legyen a cucc inkább Javában fejleszt. Egy kisebb cég mint amilyen nekem van, akinek az a lényeg hogy minél kisebb fejlesztési költséggel állítson elő minél jobb minőségű kódot, inkább C#-ban.

@scalos: a mono winform implementációja sokat fejlődött az utóbbi 1-2 évben, de még messze nem az igazi. Különösen a databinding és a grid része küzd hihívásokkal a stabilitás terén :-)

@kpityu2: "A Java tré. Nem vok programozó, csak időnként összeütök kisebb programocskákat ha szükségem van rá."

Na most mentél el anyádba. Mit fikázol, ha csak "néha összeütsz" valami szart? Beszarok.

@saclos: "...az XML kezelés"

JAXB-ről hallottál már? Szakirodalom?

Egyébként én is most tanulom a .NET-et, C#-ot a Java után. Tényleg jó cucc, de azt azért nem kéne elfelejteni, hogy a C# majdnem egy az egyben a Java koppintása. Na jó, a virtuális tagfüggvények, a LINQ, a bővítők, implicit lokális változók stb.stb. mind új dolog, de attól még egy hatalmas copy. A MS-nak volt ideje "felébredeni", és lopkodni, mert valljuk, be, hogy a Javahoz képest fáziskésésben vannak (vagy voltak?).

A .NET, C# is tényleg jó. A Javával viszont pont a nyelvet akarták lehülyíteni, hogy minél kevesebbett kelljen gondolkodni a fejlesztőnek, pl. ezért is minden tagfüggvény virtuális. De kinek mi tetszik.

De a MS tud óriási nagy szart is csinálni: lásd IE böngészők.

@mbazs: Nagy vonalakban minden koppintás. A java Pl. erős C++ utánérzés, csak kivettek belőle egy rakás dolgot (párat nem kellett volna). Ami nagyobb baj az, hogy egy rakás dolgot viszont nem tettek bele (Pl. property-k). Aztán amikor kiderült hogy ez mégiscsak kellene, jöttek a toldozások/foldozások. Pl. getter/setter függvények.

@mbazs: Ps. Jó böngészőt meg bárki tud csinálni aki elég pénzt tesz a dologba. A MS-nek ez nem volt érdeke, a guglinak meg igen. Így aztán szépen öntötte is a pénzt a Mozilla alapítványba. Mert mégiscsak jobb ha a csillogó szemű openszorszos fiúk ütik ki a csúnya gonosz Explorert és nem egy másik multi. Aztán amikor a mór megtette a kötelességét, a gugli szépen elzárta a pénzcsapot. A Mozilla pedig azóta mélyrepül.

@midnight coder:

Én úgy olvastam, hogy a C# property-k csak egyszerű "syntactic sugar" a getter/setter helyett. Bár tény, hogy többet kell gépelni:)

Amúgy van benne valami, a Javát is fejleszthetnék. Pl. az annotációk se olyan régiek, így tehetnének bele pl. lambdákat is. A C++-hoz meg ne is közelítsen, mert az már a másik véglet. Amikor 20 oldalon át fejtegetik, hogy hogyan is kell jó másoló konstruktort írni, az néha már sok.

Böngészők: erről a háborúról én nem tudok semmit, én csak azt látom, hogy az IE soha, egy büdös percig se akar normálisan, szabványosan működni.

@mbazs: A property ennél azért sokkal több. Pl. elég hülyén veszi ki magát, hogy egy vizuális tervezőben beállítod egy objektum Text tulajdonságát, de közbe olyanja nincs is neki, csak gettter/setter függvénye.

A C++-ból az operator overloading maradt ki, szerintem helytelenül. De maga a nyelv eléggé hasonlít (vezérlésátadás, oparátorok, stb).

Böngészők: ez azért elég gyakran úgy nézett ki, hogy a MS kitalált valamilyen elemet, ezt aztán a w3c "szabványosította", persze jó sóhivatalként még véletlenül sem azzal a szintaxissal ahogy a MS kitalálta, ez utóbbit pedig aztán a többi böngésző implementálta. Utána pedig a MS lett a gonosz inkompatilbilis.

Lehet nagy feneket keríteni, hogy kinek a szőke kinek a vörös de:
www.tiobe.com/index.php/content/paperinfo/tpci/index.html

@mbazs: Látom jobban szereted a javát mint anyádat. :D

@félember: Ez nem a leggyakrabban használt programnyelveket méri, hanem a legproblémásabbakat :-).

@midnight coder:

"A C++-ból az operator overloading maradt ki" - gondolom Javát akartál írni.

Én ahogy eddig láttam, az operator overloading sokszor csak a káoszt növeli, C++-ban nagyon gusztustalan moperátortúlterhelés.ódon el lehet szúrni. És én úgy láttam, a .NET nyelvekben a C++-éhoz képest nagyon keményen le van butítva (csak statikus, csak 2operandusú, ha jól emlékszem)

@midnight coder:

"A property ennél azért sokkal több. Pl. elég hülyén veszi ki magát, hogy egy vizuális tervezőben beállítod egy objektum Text tulajdonságát, de közbe olyanja nincs is neki, csak gettter/setter függvénye."

Tökugyanaz a kettő, csak a C#-é logikusabb kinézetű. Ez kétségtelen.

@kpityu2: Nem, csak utálom azt, ha valaki 5 perc után lefikáz valamit. Persze fikázni könnyű, de a magyarok ebben is élen járnak, mint a rákban.

@NemoKapitany: Igazad van, elkanyarodtunk az eredeti topictól.

@PuruttyaIrto: gratulálok. :D

Gondolom akkor a telkók, a bankok, a gyárak majd összekötött Iphone-okat fognak használni háttérrendszerekre. :)

Mi lenne, ha kurvára nem vagy képben, akkor nem szólnál hozzá? Nehéz megállni, hogy hülyét csinálj magadból? Totál más téma, kisfiú, menj játszani a homokozóba.

@kpityu2: Igen, Win alá. Vagy az SWT ami Java-s, szintén. Swingen és AWT-n már rég túl vagyunk, ha asztali programról van szó. De ez távol áll az enterprise rendszerektől, és ott egyelőre nem ilyen egyértelmű a helyzet. Mivel a Sun "találta" fel nagyüzemben az alkalmazásszervert, az MS itt másodhegedűs az elterjedtség miatt. Az, hogy melyik jobb, az meg a vallásháborúk témája. :)

@NemoKapitany: banki informatikai fejlesztő vagyok, jelenleg projektet vezetek, lentről kezdve, mindent megtanulva. Azt hiszem, Te egyik sem vagy. :)

Ki fingott? :)

@mbazs: Ja, hallottam, meg SAX-ról is, meg XMLBeansról is, meg még 5-6 dologról, amit ez-az hekkelt össze, aztán ebből kettőt-hármat beemeltek a JDK-ba, mindegyik mellett megjegyezve, hogy akinek lejesítmény kell, az ne ezt használja, vaaan másik!

De gyakorlatban is meg lehet nézni a Java XML képességeit, elég betölteni 5-6000 ember havi béradatát az ABEV-be :) Külön ciki, amikor a hipi-szupi XSD alalapú ellenőrzéssel együtt a 6000. tétel feldolgozása, fél órával az indítás után jön rá, hogy a cég neve nem a megfelelő karakterkészlettel lett beírva :D

Milyen finom emberek vagytok ti, fejlett vitakultúrával.

@mbazs: Igen, picit beszedtem a fogalmazásgátlót: valóban azt akartam írni, hogy a C++-ból az operator overloading maradt ki.

Az ilyen "syntatic sugar" hivatkozás engem mindig idegesít egy kicsit. A property egyrészt átláthatóbbá teszi a kódot. Függvénnyel kiváltani kb. olyasmi, mintha a +, -, *, / operátorok helyett Add,Sub,Multiply, Divide függvények lennének, és egy a = b + 12-t úgy kellene leírni hogy a.Set(b.Add(12)). A dolog működne, az operátor csak "syntactic sugar", de azért nem kicsit olvasható jobban az operátoros változat. Kb. ugyanez a helyzet a propertykkel is. És ha jobban belegondolunk szinte az összes nyelvi elemmel assemblytől felfelé. OOP-hez hasonló dolgot is lehet csinálni OOP nélkül, lásd GTK+ C-s interfésze...

Másrészt a property egy fontos nyelvi elem: képessé teszi az objektumot arra, hogy egy mezőjének változásának hatására valamit cselekedjen, valamint hogy egy adatmezője értékét algoritmussal állítsa elő.

Ez azért fontos, mert segíti az adatelrejtést: az objektumot használó programnak nem kell tudnia hogy ez az adatmező belül mit csinál, Pl. hogy egy függvény állítja elő az adott értéket vagy egy belső mezőből jön elő.

A getter/setter esetén ez az adatelrejtés sem érvényesül. Valami vagy függvény, vagy nem.

@midnight coder: A property semmi különös, egy kényelmi elem, default implementációt ad a get/set metódusokra. C++-ban is mindent el lehetett rejteni getX/setX metódusokkal (vagy számított elemnél simán X()), sőt ortodoxok szerint nincs olyan, hogy publikus member (ebből következően property sem). Egyébként hány %-ban írsz "{get;set;}" törzsű propertyt? 95? 99? Most gyorsan belekerestem egy programomba: 100-ból 2 a "valódi" propertyk aránya.
Továbbmegyek, mivel a a property segíti, hogy funkció helyett adatban gondolkodj, ezért káros lehet.

@igazi hős: Az operátorok is csak kényelmi elemek, helyettük írhatnál Add, Sub, stb függvényt.

És pont az a lényeg, hogy ahol ez van, ott a meghívónak semmi köze ahhoz hogy az adott mező hogyan kap értéket, vagy hogy az objektum mit csinál vele ha megkapja. Pont ez az adatok elrejtésének elve. Az objektum fekete doboz. A getter/setter függvény pedig ezzel megy szembe.

@midnight coder: Ha nem adattároló objektumról van szó, akkor a hívónak semmilyen mezőről nem kell (sőt igazából nem szabad tudnia). Ezek szerint ennek a property is szembe megy. Ha tényleg le akarták volna választani, akkor nem lenne default implementáció. Így viszont a public member egy szebb megfogalmazása lett belőle, ami lehetőséget ad az adatelrejtésre, de kicsit sem kényszerít.

A legtöbb objektum adattároló is. Azért objektum és nem csak egy kupac függvény. Egy label-nek is van tárolt adata: Pl. a megjelenített szöveg, vagy a kiírás színe. Ezek ugyanúgy adatok mint az üzleti objektumban a számlaszám. És ugyanúgy illetlenség őket függvényeken keresztül állítgatni.

@saclos: akárcsak a .NET keresztplatform képességeit. De tényleg ne keverjük a dolgokat, mert tévedésbe visz. A .NET az összes MS nyelvvel megy, de nem igazán cross-platform, a J2EE meg Java-s, és cross-platform. És a J2EE a legkevésbé desktop célú, bár az SWT már azért odaver. De jelen pillanatban nem éppen oda tartunk, hogy letöltött programokat futtassunk a gépünkön, konkrétan az ABEV is nonszensz, kb. 15 éve volt korszerű megoldás.

Nem a Java XML képességeivel van a gond, hanem számításigényes, gyors választ igénylő desktopra nem használunk Java-t, hacsak nem az az egyetlen nyelv, amit ismerünk, mert könnyű megtanulni és használni, és van barátunk a kormányzatban. :)

@midnight coder: Igen egy objektumnak vannak tárolt adatai, ez az ő állapota. És vannak tulajdonságai, amiket lekérdezhetsz és beállíthatsz. A kettő közötti összefüggés a programozó "intim magánügye" kéne hogy legyen. Persze egy szigorú osztályt írni mindig több munka, pláne ha olyan mély rendszertervet sem csináltunk. Akkor lesz minden public és kerül néhány megjegyzés a doksiba (amit persze nem olvas el az akinek szól), hogy mit hogyan kéne használni.

@igazi hős: A belső adatok azonban valamilyen formában ki kell hogy legyenek vezetve a külvilágba. Egy számla üzleti objektum Comment mezője is efféle dolog, vagy egy Label objektum Text mezője. Ezeket értékadással állítgatod. Az hogy ez a dolog aztán belül property vagy sima mezei publikus változó már a megvalósítástól függ, és akár változhat is, ha egyszer csak csinálni kell valamit az objektumnak ha valaki megváltoztatja a comment mezőt, vagy épp kivételt kell dobnia ha valaki azt írja bele hogy hülye a főnök. A publikus property-k és tagfüggvények pedig normál esetben általában azért kommentezve vannak, ez igen jól van kitalálva a C# nyelvben (és igen jó támogatása van a visual studióban).

@midnight coder: Nem értünk egyet, de ezt természetes. Miért kéne egy számla egy megjegyzését (vagy bármely adatát) módosítani? Mi az a funkció az üzleti modellben, ami ezt igényli?

Pl. mert egy bejövő számlán Jucika utólag jött rá, hogy elírt egy összeget. De lehet módosítandó objektum egy ügyfél entitás is, aminek Pl. megváltozott a címe.

@midnight coder: Tökéletes a példád, hogy mit nem szabad. Amennyiben valaki elírt egy összeget és azt a számlát már kontírozták, akkor olyan művelet nincs, ami módosítana egy értéket. (Nem felel meg a jogszabálynak.) Pláne nem Jucika által elérhető művelet.

@igazi hős: Ez a kontírozás előtt van.

@midnight coder: Ezt mi biztosítja, ha ez nem egy önálló művelet, hanem egy tulajdonság (member vagy property itt mindegy) módosítása?

@phaidros: Az ABEV eredetileg Delphiben volt megírva, a linsucknyikok verték a palávert, hogy az állam nem írhatja elő Windows használatát, keresztplatformos legyen. Lett. Nem mintha a másik nem futott volna Wine alatt, annak a 10 könyvelőnek a kedvéért, akik extra kínzást írtak elő maguknak.

Ugye, nem arra gondolsz, hogy pár tízezer try-fail nyomtatványkitöltő próbálkozásait egy központi rendszernek kéne lekezelnie, webes felületen keresztül?

na ez a blog sem a regi mar... :-p

Az adat objektum felírása természetesen már önálló művelet. De az, hogy én az objektum mennyiség mezőjébe beírom hogy nem 2 hanem 3 az már nem művelet hanem egyszerű értékadás. Persze ez igazából nem a property-re példa, hanem hogy egy objektumnak igenis illik hogy legyen publikus adattartalma.

Az már külön szépség hogy a property lehetővé teszi, hogy Pl. az adott mezőbe ne kerülhessen illegális érték, vagy hogy ha megváltoztatom egy mező értékét akkor a tőle függő mezők értéke is automatikusan változzon.

@midnight coder: "hanem hogy egy objektumnak igenis illik hogy legyen publikus adattartalma." Először azt akartam írni, hogy ez baromság, de finomítok: egy objektumnak nincs "adattartalma", csak tulajdonságai és műveletei. Amikor egy valódi propertyt csinálsz (azaz a törzse nem sima {get; set;}), akkor végre csinálsz egy műveletet értékadás helyett. Aztán ha továbbgondolod, akkor rájössz, hogy a legtöbb publikus membered/propertyd felesleges.

Az állapotának reprezentációját tartalmazó memóriaterületet hívom én adattartalomnak. És néha teljesen felesleges még propertyt csinálni is: ha az adott mező csak adat (Pl. egy számla commentje) akkor bőven elég ha publikus string. Nyugodtan írhatom hogy számla.Comment = "Hülye a főnök"; ez csak annyiban változtatja meg az objektum állapotát hogy a benne tárolt adat változott. Aztán, ha olyat szeretnék, hogy számla.Kelt = DateTime.Now.Date(); akkor ott már lehet olyat csinálni hogy ellenőrzöm hogy a dátum megfelel-e a szabályoknak, és Pl. készpénzfizetéskor kimenő számlánál ha nem a mai dátum akkor dobhatok kivételt. Más kérdés hogy az üzleti objektumban szerencsésebb a property, mert azt lehet adatkötni. De egy mezei, belső használatú objektumnál sima adatmezőt használok az ilyenre.

Aztán persze vannak az üzleti objektumnak valódi függvényei is, Pl. olyan hogy Update ami felírja őt az adatbázisba. Ez valóban függvény, míg a számla.Kelt = DateTime.Now; egy sima értékadás. Ez javában számla.setKelt(new Date()); lenne, azaz függvényhívás, holott valójában logikailag értékadási műveletről van szó. Ha pedig a számla.setComment("Hülye a főnök"); műveletet nézed, ez kimondottan hülyén néz igy ki, mivel valójában a Comment mezőnek akartam csak értéket adni és nem függvényt hívni.

Azaz szvsz el kell különíteni azt amikor az objektum egy-egy tulajdonságának értéket adok, azaz számla.Comment="Ez van"; vagy az objektumot felkérem valamilyen művelet végrehajtására (Pl. számla.Update()). A property azt teszi (egyebek közt) lehetővé, hogy a tulajdonságnak értékadás mögé függvényt csempésszünk, ami ésszel használva nagyon hasznos lehet. Lásd a fenti ellenőrzéses példa.

Aztakurva milyen oltások mennek itt:D Én rohadtul nem értek a szgéphez, még informatikai debil se vagyok:( Így lövésem nincs mi a java meg a .NET, meg úgy általában, hogy itt miről folyik a vita. Mindenki megnyugodhat, h van aki nála is gyökerebb a gépekhez, vagy programozási nyelvhez v nemtom mi ez.Ide lőjetek!

@Áramvonalas Földműves: Semmi gond ezzel, a számítógépprogramozás ugyanúgy egy szakma mint a vakbél kioperálása. És ha két doki vitatkozna azon hogy merrefelé a legcélszerűbb lyukat vágni az ember hasába, abba meg nagy valószínűséggel az igazi hős és a midnight coder nevű nick nem tudna érdemben megszólalni (ez utóbbi 100%-ban biztosan nem :-)).

ez a kommentáradat nekem mindig az informatikusbulit juttatja eszembe :) frostshock.eu/wp-content/uploads/buli.jpg

@midnight coder: "Az állapotának reprezentációját tartalmazó memóriaterületet hívom én adattartalomnak." Biztos nem véletlenül választottad a nickedet, valószínűleg programozás elméleti könyv még nem volt a kezedben. Az állapottér (az objektum lehetséges állapotainak halmaza) nem egy adott méretű memóriadarab által felvehető értékek halmaza, de még csak nem is valahány típus értékhalmazának Descartes szorzata. Az ilyet ugyanis nincs értelme osztálynak/objektumnak hívni, hisz semmilyen pluszt nem ad a benne tárolt adatokhoz képest. (C++-ban van struct és class, és bár a struct egy olyan osztály aminek minden eleme publikus, de jól kifejezi a különbséget.)

Egy osztályt illetve egy objektumot nem csak egyféle szempontból lehet nézni. És az hogy hogy nézel egy objektumra alapjában véve attól függ hogy mit csinálsz vele. Másképp tekintünk egy ügyviteli rendszer üzleti objektumára aminek azon kívül hogy feltöltöd adatokkal max. némi validáció és egy-két számítás a dolga, és másképp egy játékprogram belső állapotát reprezentáló objektumra.

Egyébként a javával pont ez volt a bajom: akik tervezték csak a gyönyörszép elméletet tartották szem előtt, aminek az lett a vége hogy egy adott dolgot 2x annyi meló megcsinálni vele mint C# alatt. Ezt tükrözi hogy nincs property, hogy a generikusok csak utólag lettek beletákolva amikor a C# már megcsinálta (más kérdés hogy a C# többi nyelvi újdonságát mint Pl. a lambda expressions-t már nem volt erőforrás beimplementálni). Nem programozók tervezték hanem tudósok. A C# pedig attól lett jó, hogy olyasvalaki tervezte (Anders Hejlsberg) aki programot is írt már életében.

@midnight coder: "Egy osztályt illetve egy objektumot nem csak egyféle szempontból lehet nézni." Értelmetlen amit írsz! Az osztály maga a művelethalmaz: miből mit csinál. Nem a név, nem az adatok, hanem a funkciók. Nem lehet többféleképpen nézni. Egy tojás egy tárgy, lehet többféleképpen nézni: nekem vacsora, másnak dobófegyver.