[JavaTech] return type override

[TörökTibor]

Hello,

Janos Domosi wrote:
> >  Ha csak ennyi
> > a problema 
> Na ez a tema erdekelne.  :)
> Esetleg egy bovebb kifejtes??

Haat.... elsosorban: a szerzok a jelek szerint nalam sokkal 
bovebb tapasztalattal rendelkeznek a biralat konkret targyaban.
Az indoklasok ugyanakkor szerintem nem igazan vannak a helyukon.
A pdf-ben felsorolt problemak kicsit kifogaskeresesnek 
tunnek. 

Anno meg a 80-as evek vege fele probaltam baratkozni az ICL
tranzakcios rendszerevel. No, az volt problemas rendszer:-) 
Leginkabb persze alig mukodott. Meg akik komolyan probaltak 
meggyurni azt a rendszert, ok is hasraestek leginkabb.


Mindenekelott, ugy tunik, hogy mar maga a cim sem jo.
OO frameworkkent biralja a javat, pedig a jelentosebbnek
tekintheto kifogasokat inkabb az elosztott rendszerekkel 
kapcsolatban mutatja be. 

Az elso, a return type-pal lehet, hogy jogos. De az egy 
generalis jellegu kerdes, es igy aligha indokolhatja a 
java alkalmatlansagat OO frameworkkent. OO nyelvkent 
esetleg, de nem biztos. Lasd a vegen.

Kapcsolodik a type checking. Egy interpretiv jelleget
is hordozo runtime kornyezetben mindenkeppen lesz valamennyi
runtime type ellenorzes es kezeles. Csokkentheto lenne,
de nem erzem kritikusnak, mert jol behatarolhato/korlatozhato
a problema helye. Valaki mutasson valoban kritikus peldat.
Ez is altalanos nyelvi jellegu problema, nem specifikus 
peldaul egy ebusiness, vagy egyeb, elosztott frameworkre.

RemoteException. Itt kezd igazan kibujni a szog a zsakbol.
A szerzok sajat, specialis szempontjaik alapjan emeltek
ki egyes problemakat. Ennek a problemanak az indoklasa
ranezesre hibas. Problemakent megnevezi a kod elhelyezesenek
modositasakor a hibakezeles atirasanak szuksegesseget.
Alap hibakent pedig _konkretan_ a Liskov megserteset
es _konkretan_ az Exception szarmaztatast jeloli meg. 

Megszunik-e a problema, ha RemoteException nem Exception-bol
szarmazik, hanem Throwable-bol vagy Error-bol? Nem.

Vajon milyen modulok athelyezesere gondolnak a szerzok? 
A tranzakcios rendszerek tenyleg latvanyosan lebegtetik 
ide-oda az egyes modulokat, de azert az esetek tulnyomo
tobbsegeben a modullokacio design dontes, es csak extrem
esetekben dontik el tesztek.

Source code. En is utalom, ha nincs source. De a peldak 
alapjan nagymeretu rendszerekrol van szo. Ezekhez altalaban
azert megszerezheto a source. Jo dragan. A source-futtathato
kod osszekotese egy altalanos celu rendszerben igenykent
nem igazan realis. Kulonosen a javanal, tekintettel peldaul
az Appletekre.

deprecated. Jogosnak latszik, de itt ismet a pontatlan cim
nem tetszik. Ez nyelvi problema. Szerintem kevesbe egeto
hiba, hiszen a java kommenteknek egyeb funkcionalitasa is 
van. Raadasul a (program) nyelv reszekent meg bizarrabbnak
latszik. Feljodes eseten mindenki oruletes forrasmodositasba
kezd, es pont elavult kodokat modosit? Akkor mar korrektebb 
lenne valami pragma-szeru megoldas.

Amiket felsoroltam, nagyreszt persze jelentektelen biralatok,
de hat az a cikkecske sem fogja felforgatnia a vilagot:-)


Konkretan a return type-rol nem igazan tudok hatarozott
velemenyt mondani. Engem nem zavar, de latom, hogy esetleg
lehet hasznos. Viszont kevesbe vagyok meggyozheto egyszeru 
peldakkal. Valami erosebb bizonyitas kellene. Pl. matekos 
bizonyitas. De ilyen asszem nincs. Vagy van?

udv: TT