String wrapper

Nem tudom hová tenni, itt majd jó helyen lesz:
http://pastebin.com/M5ZbD7xA

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

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

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

( fabian-bros | 2015. 08. 30., v – 12:19 )

Java kerdes:

ennek mi az effektje? 

this();

--------------------------------------
Unix isn't dead. It just smells funny.

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

( Exit | 2015. 08. 31., h – 17:20 )

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.

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

-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

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

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

> 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

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

"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™

> 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

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

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

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?

É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

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

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

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

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

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

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™