mennyivel jobb lenne..

ha Javaban a boxolt primitiv tipusok rendelkeznenek set metodusokkal is. igy kenyelmesen atadhatova valnanak mutable primitiv tipusok anonymous classoknak.

vagy nekem kerulte el vmi a figyelmem? (es nem olyan jo Long-ot AtomicLong -al helyettesiteni csak a "funkcionalis" feature-ert).

( sz | 2010. 05. 30., v – 19:46 )

Ezekszerint nem csak nekem van problémám ezzel :) Dehát biztos megvan erre is a logikus magyarázat, mint oly sok minden más Java agyzsugorra.

Autoboxingos érdekesség jut most eszembe hirtelen; annak idején te is hozzászóltál.

Meg ott van a többszörös öröklődés és az operator overloading hiánya, ami önmagában nem agyzsugor, de amikor egyszeri java coder próbálja megindokolni ezek hiányát egy c++-ról érkezőnek... na, az az.

Nem tudom. Talán azért, mert eleve olyan a kérdéssel jönnek oda, hogy pl. "te figy, miért nincs Java-ban többszörös öröklődés?"? Én nem zavartatom magam, és megmondom kerek-perec, hogy fogalmam sincs, de vannak, akik ilyenkor megpróbálják megindokolni. Meg aztán ott vannak azok is, akiket még kérdezni sem kell: elég csak a közelükben felsóhajtani, hogy "többszörös öröklődés de jól jönne most!", aztán ők ezt mintegy személyes sértésnek véve megmagyarázzák, hogy miért is jó az, hogy nincs.

Nekem úgy rémlik, hogy volt valami kvázi-hivatalos magyarázat arra, hogy miért nincs többszörös öröklődés, ami úgy többé-kevésbé logikusnak is hangzott, de én sem emlékszem már rá pontosan. Az egyetemen valahogy az attribútumok fizikai layoutjáról, meg ennek optimalizálási nehézségeiről magyaráztak valamit, de utóbb belegondolva azért ezek nem megoldhatatlan problémák. Kíváncsi vagyok, hogy ezt a magyarázatot szoktad-e hallani?
---
Internet Memetikai Tanszék

Itt félreértés lehet, nem azt mondtam, hogy az interfész workaround, hanem konkrétan a többszörös öröklődés "szimulálása" interfészekkel és egyebekkel az workaround. Az ok nyilvánvaló: csak az egyik szülő lehet osztály, ahonnan metódusok definícióit lehet örökölni, a többi csak interfész lehet, vagyis az azokban deklarált metódusokat mindig implementálni kell. Ha n darab többszörösen öröklött osztályban is ugyanaz az implementáció kell, akkor is, ha delegálni akarsz, akkor is. A gyerekosztály meg végül tele lesz mindenféle olyan metódusok definíciójával, amikre valódi többszörös öröklődés esetén semmi szükség nem lenne. Bár a gyakorlatban ez elég jól működik, a copy-paste-nek hála, de attól még workaround marad.

Copy-paste? Strategy, ill. template method tervezesi mintarol hallottal-e mar?
Az interfacek meg osztalyok kozott ne arra gondolj, hogy "itt metodusok orodkolnek es kesz", hanem azt fejezed ki, hogy egyfajta API-t megvalosit-e a komponensed vagy nem (minek a helyere illesztheto be). Az, hogy az adott interface-t belul milyen modon implementalod, senkit nem erdekel, mig oroklodesnel az orokolt adattagok miatt meg van kotve a kezed, az objektumod belso adatszerkezete adott. Korul kell nezni az olyan fogalmak kozott is, hogy value class, es hasonlok. A tobbszoros oroklodes helyett sokkal esszerubb es rugalmasabb tervezesi mintak allnak rendelkezesre, sot, altalaban az objektumkompoziciot elonyben reszesitik az oroklodes helyett, pont a rugalmassag miatt.