- 6030999 blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Ez miert jo?
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
+1
---------------------------
Oszt jónapot!
- A hozzászóláshoz be kell jelentkezni
Én ezt sem értem miért jó:
public Betreff()
{
super();
}
- A hozzászóláshoz be kell jelentkezni
Van másik konstruktora, így a paraméter nélküli cuccot a ki kell írni.
Az ősosztály meg ki tudja, mit csinálna a konstruktorban. Szóval, akár még helyes is lehetne.
--
blogom
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy én tudom rosszul, de alapértelmezetten -- ha másképp nem nyilatkozik a programozó -- akkor nem az ős osztály paraméter nélküli konstruktora hívódik meg? (Ez alapján a
super()
szvsz felesleges...)
G.
============================================
"Share what you know. Learn what you don't."
- A hozzászóláshoz be kell jelentkezni
Teljesen korrekt, amit mondassz.
De ha nem írod ide ki a paraméter nélküli konstruktort, akkor ilyet nem tudsz:
Betreff wtf = new Betreff();
// hibás, a Betreffnek csak new Betreff("valamiString") konstruktora van
Ellenben lehet, hogy én simán akarok paraméter nélkül létrehozni ilyet. S hiába van a
ValueObject
-ben paraméter nélküli konstruktor, ha nem írom bele expliciten a
Betreff
-be, nem fordul az előző példasor.
Annyiban igaza van mn3monicnak, hogy ennyi is elég lenne (ha erre gondolt, sry)
public Betreff() {}
// ha egy konstruktor első hívása nem super, vagy this, automatikusan lesz egy super() hívás
De szerintem ez átláthatatlanabb, s inkább írjuk ki a supert az elejére.
--
blogom
- A hozzászóláshoz be kell jelentkezni
A super-ra gondoltam és szerintem meg inkább ne írjuk ki :)
- A hozzászóláshoz be kell jelentkezni
Van valami konkrét oka ennek, vagy csak esztétikailag így gondolod szépnek?
(nekem az egyetlen indokom az „így gondolom szépnek”, olvashatónak)
--
blogom
- A hozzászóláshoz be kell jelentkezni
Szerintem nagyban növeli azt a téveszmét, hogy ha nem írod ki, akkor az ős constructor ebben az esetben nem fut le. Szerintem pont amiatt rossz kiírni ilyen esetekben, mint ami szerinted pont hogy jó. Írjuk ki, ha okunk van rá. Szerintem. Compiler úgyis oda teszi :) dolgozzon csak, azért van :)
- A hozzászóláshoz be kell jelentkezni
És nem is immutable a setter miatt...
- A hozzászóláshoz be kell jelentkezni
Az csak hab a tortán.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Hát ezt nem tudtam én sem feldolgozni, s önsegítő terápiaként kiöntöttem a lelkemet a pastebinre.
_______Peter
I am a stone. I do not move.
- A hozzászóláshoz be kell jelentkezni
Jah, hogy ez itt a lelked. Ertem. Akkor bocsass meg. :D
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
Ha mar felraktad a pastebinre meg ide is, akkor nyilatkozhatnal hogy mit tudunk belole tanulni vagy egyaltalan mi celod volt :)
--
arch,debian,openelec,android
- A hozzászóláshoz be kell jelentkezni
A mese tanulsága: gyerekek, legyetek szívesek, véletlenül se írjatok a String osztálynak semmittevő wrappert, mert minek.
Különben az az elméletem, vagy nevezzük eredetmítosznak, hogy a szerző valami okos defenzív programozó blogon olvashatta, hogy ilyen látszólagos leszármazottakkal biztonságosabb kódot lehet elérni, mert véletlenül sem adják értékül például a vezetéknevet egy postai címnek. Vagy lehet, hogy a YAGNI-t úgy bontotta ki, hogy you ARE gonna need it.
Mint látható, most sem hagy nyugodni, magyarázatokat próbálok találni, elméleteket gyártok, ezért írtam akkor inkább ki, hogy le tudjam tenni, le tudjam zárni, tovább tudjak lépni...
Erősen kapcsolódik: http://dilbert.com/strip/2013-02-24
_______Peter
I am a stone. I do not move.
- A hozzászóláshoz be kell jelentkezni
Java kerdes:
ennek mi az effektje?
this();
--------------------------------------
Unix isn't dead. It just smells funny.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Meghivja a (feleslegesen deklaralt) default konstruktort ami meghivja a (feleslegesen odairt) super() -t. -> felesleges fecseges :)
Amugy ez az egesz osztaly semmi ertelmeset nem csinal raadasul azt se tudjuk hogy ezek az @Embeddable es @Immutable annotaciok honnan a gyikbol vannak mert ugye az import is ki van torolve.
--
arch,debian,openelec,android
--
arch,debian,openelec,android
- A hozzászóláshoz be kell jelentkezni
Nem akarom vedelmemben venni a kodreszlet szerzojet, de valoszinuleg azert irta ilyenre amilyen, hogy mukodjon egy relational db frameworkkel (pl hibernate vagy JPA). Szerintem ezert van setter is meg no-arg konstruktor is, mert azokat a framework hivotagtja amikor mondjuk a resultset egy sorat mappeli objektumra es megivja a default konstruktort (ami nem lenne publikus ha nem lenne kiirva), majd meghivja a settert hogy beallitsa az erteket.
- A hozzászóláshoz be kell jelentkezni
Borzaszto nepszokas egyebkent a private field es a gettersetter paros. Tudom hogy a JavaBeans eloirja es valakik ugy gondoltak 10 evvel ezelott hogy ez franko. Inkabb 100%ban feleslegesnek gondolnam. Sokkal rovidebb es egyertelmubb a public field es kb nem lattam az utobbi evekben olyan frameworkot vagy libet amit zavart volna.
--
arch,debian,openelec,android
- A hozzászóláshoz be kell jelentkezni
En ezert hasznalok Groovy-t, az ilyen getter-setter hulyeskedeseket az automatikusan megoldja, en meg ugy tudom ezeket hasnzalni, mintha public fieldek lennenek. Win-Win.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
Project Lombok
- A hozzászóláshoz be kell jelentkezni
Ez egy vélemény a millió másik közül. Sokmindenben egyetértek vele és sokmindenben nem. Szóval... és?
- A hozzászóláshoz be kell jelentkezni
-1
Első látásra a .NET-es Property tényleg kényelmesebb, de a Java-s getter/setter felállás is védhető. Szerintem ez szubjektív dolog.
A másik meg, hogy ha egy attribútumra validátort, lazy loadingot, vagy bármi mást szeretnél, a későbbiekben akkor a public fielddel átírod mindenhol? Vagy?
--
blogom
- A hozzászóláshoz be kell jelentkezni
> Első látásra a .NET-es Property tényleg kényelmesebb, de a Java-s getter/setter felállás is védhető. Szerintem ez szubjektív dolog.
Példát is mondanék: a set-get mutatja, hogy ott történik is valami ráadás az írás-olvasás mögött.
> A másik meg, hogy ha egy attribútumra validátort, lazy loadingot, vagy bármi mást szeretnél, a későbbiekben akkor a public fielddel átírod mindenhol? Vagy?
Tudtommal a refactor toolok ilyet tudnak.
- A hozzászóláshoz be kell jelentkezni
"Példát is mondanék: a set-get mutatja, hogy ott történik is valami ráadás az írás-olvasás mögött."
Pont az a gond, hogy az esetek 9x%-ában nem.
"Tudtommal a refactor toolok ilyet tudnak."
Sok szerencsét, ha valami publikus apit fejlesztesz. :) (Minden ilyen változás breaking change.)
- A hozzászóláshoz be kell jelentkezni
> Pont az a gond, hogy az esetek 9x%-ában nem.
Ez miért is gond?
> Sok szerencsét, ha valami publikus apit fejlesztesz. :) (Minden ilyen változás breaking change.)
Lehet naiv kis porbafingó kertitörpe vagyok, de rendesen megtervezve, bejelentve, időt hagyva ezek bele kellenének, hogy férjenek.
Az egyik legnagyobb hátránya a Javanak, szerintem, hogy a 15+ éves dolgokat, amiket egyszer elbasztak benne, a mai napig cipeljük magunkkal, csak mert az 1.0 ApiDocsban beleírtuk
--
blogom
- A hozzászóláshoz be kell jelentkezni
"Ez miért is gond?"
Mert ha nem történik semmi "extra", akkor miért is nem dolgozik a nyelv/compiler helyettem? Nem, az IDE kódgenerálása nem megoldás. A project lombok egy ügyes trükk a probléma megkerülésére, de más problémákat fog okozni.
- A hozzászóláshoz be kell jelentkezni
"de rendesen megtervezve, bejelentve, időt hagyva ezek bele kellenének, hogy férjenek"
Bele. De ha eleve nincs szükség változtatásra, azzal csak megkönnyíted azoknak a munkáját, akik az API-dat használják.
Egyébként egyetértek, a java (fejlesztőinek a) hülyesége hogy a mai napig nem lehet megoldani ezt a problémát úgy, ahogy más nyelvekben már rég meg van oldva...
- A hozzászóláshoz be kell jelentkezni
"Lehet naiv kis porbafingó kertitörpe vagyok, de rendesen megtervezve, bejelentve, időt hagyva ezek bele kellenének, hogy férjenek."
Aztán jön a gyakorlat és a PM, hogy ma csak azért is kirakunk valamit és leszarjuk, hogy 3 másik team függ tőlünk.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
ha egy csapat szar, akkor egy csapat szar.
a pm meg ugyanúgy része a csapatnak, mint a mérnökök
--
blogom
- A hozzászóláshoz be kell jelentkezni
> Példát is mondanék: a set-get mutatja, hogy ott történik is valami ráadás az írás-olvasás mögött.
Ez olyan, mint a fentebb említett
this()
, vagy
super()
hívás. Van, aki szerint ismerd ennyire a nyelvet, van, aki inkább jelölné. A setter-getter dologban, nálam belefér az utóbbi - el tudom fogadni a C#-féle Propertyket.
--
blogom
- A hozzászóláshoz be kell jelentkezni
Amúgy nekem is hóttmindegy általában.
Szerk:
getter-setter: https://www.youtube.com/watch?v=sTSQlYX5DU0
- A hozzászóláshoz be kell jelentkezni
private String akarmi;
getAkarmi() { ... }
setAkarmi() { ... }
VS
public String akarmi;
A ketto 100%ban ugyanazt tudja, es minden elkepzelheto szempontbol ugyanolyan erteku a kod, csak az utobbi sokkal rovidebb. Egy atlagos domain entityben tobb tucat vagy 100+ sor sporolhato meg. Raadasul ez a kod konvenciok alapjan generalhato, semmi erdemleges dolgot nem csinal.
Azt ne mondjuk hogy az elso OOP elvek szerint keszult mert a falra maszok instant.
A lombokot meg hagyjuk a rakba. Regen en is szerettem, de rajottem hogy jobb ertelmes kodot irni es kidobni a hackelest.
--
arch,debian,openelec,android
- A hozzászóláshoz be kell jelentkezni
Egy picit ellentmondanék.
Számomra van a két kód felhasználhatóságában szemléletbeli különbség.
Az első esetben az adott mezőbe történő érvényes és helyes adat beírásáról és kiolvasásáról a mezőhöz -- és az adott objektumhoz -- rendelt getter/setter páros gondoskodik. Amelyeknek akár különböző, egymástól eltérő láthatósága is lehet, sőt akár asszimetrikusan is megvalósíthatók, pl. az egyik el is maradhat, ahogy ez a már említett C# tulajdonságok is teszik.
A második kódrész esetén viszont az adott értéket az mezőbe juttató hívó eljárásnak/függvénynek kellene a helyes adatról gondoskodnia.
G.
============================================
"Share what you know. Learn what you don't."
- A hozzászóláshoz be kell jelentkezni
Egyetértek. Ráadásul ha Gyuszk évek óta nem látott olyan framework-ot ami megköveteli a getter settereket, akkor azóta nem foglalkozott JPA-val sem. Elég egy egyszerű lazy load és már kell a getter. Tracking kell, kell a setter. Vagy ezek már "hekkelések", mert proxy-zok, ne adj isten byte kódot módosítok?
- A hozzászóláshoz be kell jelentkezni
Én azt állítottam hogy a gettersetter azért nem kell mert konvenció alapján generált felesleges boilerplate maszlag, _kivéve ha valami értelmeset csinál_. Amennyiben odaproxyzol a getter metódus közepére, akkor az mást is csinál - nyilván nem kell kitörölni.
--
arch,debian,openelec,android
- A hozzászóláshoz be kell jelentkezni
{Szerk}
Rendben, semmi gond nincs azzal, hogy te nem használsz getter setter-t, én tudok így élni :)
- A hozzászóláshoz be kell jelentkezni
Oké, csak a gond akkor van, hogy ha utólag kell valami.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Szóval a feeling miatt getter-setterezünk, értem. Mert hogy a kettő identikus:
public void setBla(String bla) {
bla = bla;
}
objektum.bla = "bla";
Amennyiben az assignment mellett más is berakásra kerül a setterbe az más eset nyilván.
--
arch,debian,openelec,android
- A hozzászóláshoz be kell jelentkezni
Szerintem akkor le is zárhatjuk a témát, igen a feeling miatt, és igen, amit írtál, az aztán identikus, és még azt is csinálja amit gondoltál... (az ilyenek miatt jó pl használni a final-t)
- A hozzászóláshoz be kell jelentkezni
Szívem szerint minden lehetséges helyre írnék final -t de sajnos nem mindenhol szeretik :/
--
arch,debian,openelec,android
- A hozzászóláshoz be kell jelentkezni
Visszakérdezek: a
public
hozzáféréssel ellátott mezők (adattagok) esetén hogy biztosítható az OOP-ben levő információ rejtés (information hiding), azaz hogy az objektumba és az objektumból, csak annyi és olyan információ tudjon be- illetve kijutni, ami feltétlenül szükséges?
Ha az objektumot hívó eljárásnak kell ezekről gondoskodnia, akkor ha N db helyen hivatkozol az objektum mezőjére, akkor N-szer kell (illene) adatszűrést csinálnod, viszont ha az objektum ,,felel'' az adatforgalomért (getter/setter) akkor elég egyszer -- az objektum leírásában -- rendesen kidolgozni az adatforgalom-szabályozást. N vagy 1, melyik az egyszerűbb?
G.
============================================
"Share what you know. Learn what you don't."
- A hozzászóláshoz be kell jelentkezni
hagyd, nem fogja megérteni
btw, ő előre látja, hogy egy attribútumot valaha, a projekt jövője során szükséges lesz-e validálni - s akkor már előre getter/setter párost ír.
--
blogom
- A hozzászóláshoz be kell jelentkezni
gosh, mindjárt besírok.
- a private + gettersetter se rejt el semmit, ugye tudod hogy pontosan ugyanannyit enged kifelé mint a public field?
- igen, ha írunk bele értelmes kódot akkor legyen, de ha nem, akkor mi a búbánatnak generálunk naponta többmilliárd sornyi gettersettert a világba?
--
arch,debian,openelec,android
- A hozzászóláshoz be kell jelentkezni
lck
- A hozzászóláshoz be kell jelentkezni
"a private + gettersetter se rejt el semmit, ugye tudod hogy pontosan ugyanannyit enged kifelé mint a public field?"
^- "gosh, mindjárt besírok."
- A hozzászóláshoz be kell jelentkezni
Nagyjából okés, baj akkor van, ha kiadsz egy libet, ahol public egy adott field. Szépen elterjed, aztán kiderül, hogy kell valami validálás is. Ekkor kénytelen vagy törni az API-t (bejön a setter), amit meg csak a linuxosok szeretnek :-)
Amúgy a "merev" getter-setterezésnek én sem vagyok feltétlen híve, olvashatóbb tud lenni anélkül egy kód (abban a környezetben, ahol dolgoznom).
- A hozzászóláshoz be kell jelentkezni
"- igen, ha írunk bele értelmes kódot akkor legyen, de ha nem, akkor mi a búbánatnak generálunk naponta többmilliárd sornyi gettersettert a világba?"
Azert, hogy elrejtsuk az implementaciot. Mert lehet, hogy az a getter ma csak lokalis valtozoba ment, de lehet, hogy holnap egy API hivast ut le valahol.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
Csak egy egyszeru kerdes: Hogyan csinálsz interfacet belole utolag?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Úgy vettem észre az ilyen kérdésekre nem reagál :)
- A hozzászóláshoz be kell jelentkezni
su -c "make interface"
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
,,a private + gettersetter se rejt el semmit, ugye tudod hogy pontosan ugyanannyit enged kifelé mint a public field?''
Szvsz, ha és amennyiben Te írod azt a kódot, akkor biztosan.
Kicsit úgy érzem, hogy Te Igazi Programozó vagy, aki bármilyen programozási nyelven képes Fortran programkódot írni...
G.
============================================
"Share what you know. Learn what you don't."
- A hozzászóláshoz be kell jelentkezni
private int _quantity;
public int Quantity
{
get { return _quantity; {
set
{
if (value < 1) throw new ArgumentException("Quantity should be greater than 0!");
if (value != _quantity)
{
_quantity = value;
RaisePropertyChanged("Quantity");
}
}
}
(És akkor most belegondoltam, hogy hányszáz helyen kellett használnom a RaisePropertyChanged-et...)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
set/get|isX()-ben az a csodaszép, hogy ha reflection-t kell használni. Míg .NET-ben simán azt mondom, hogy én csak a propertykkel akarok foglalkozni, addig Java-ban erre mi a szép megoldás? :)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Introspector, beanInfo, propertyDescriptor, readMethod, writeMethod
- A hozzászóláshoz be kell jelentkezni
Jobb helyeken feltalálták erre a propertyket. Persze a C#-ot meg a Delphit le kell nézni, mert vannak bennük értelmes dolgok is.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Az egybol latszott, hogy ez valami JPA okorkodes, de a super() hivasra meg a this() hivasra nem feltetlen lenne szukseg, plusz az egesz osztaly felepitese valami elbokott gondolkodasmodot tukroz.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
Valoban. Ezert is irtam, hogy nem akarom vedelmembe venni se a szerzot, se a kodot.
- A hozzászóláshoz be kell jelentkezni