/ Forside / Teknologi / Udvikling / Java / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Java
#NavnPoint
molokyle 3688
Klaudi 855
strarup 740
Forvirret 660
gøgeungen 500
Teil 373
Stouenberg 360
vnc 360
pmbruun 341
10  mccracken 320
Type casting problemer
Fra : Soren Staun Jorgense~


Dato : 24-04-01 20:31

Hej,

Lad os antage at følgende ligger fast:

public class KlasseA extends Object
{
...bla bla
}

public class KlasseB extends KlasseA implements KlasseC
{
...bla bla
}

public inteface KlasseC
{
...bla bla
}

Hvordan "type caster" man så KlasseA til KlasseB uden at det giver en
ClassCastException
- altså noget lignende (KlasseB)KlasseA ????

Venlig hilsen
Søren Staun Jørgensen
---
ssj@get2net.dk



 
 
Bertel Lund Hansen (24-04-2001)
Kommentar
Fra : Bertel Lund Hansen


Dato : 24-04-01 20:37

Soren Staun Jorgensen skrev:

>Hvordan "type caster" man så KlasseA til KlasseB uden at det giver en
>ClassCastException

Det gør man da vel ikke? Det ville stride mod min (evt.
mangelfulde) forståelse hvis en stamklasse kan typecastes til en
afledt klasse. Den har jo (formodentlig) flere metoder og
attributter.

--
Bertel
http://lundhansen.dk/bertel/   FIDUSO: http://fiduso.dk/

Soren Staun Jorgense~ (24-04-2001)
Kommentar
Fra : Soren Staun Jorgense~


Dato : 24-04-01 21:10


Bertel Lund Hansen <nospamto@lundhansen.dk> skrev

> Det gør man da vel ikke? Det ville stride mod min (evt.
> mangelfulde) forståelse hvis en stamklasse kan typecastes til en
> afledt klasse. Den har jo (formodentlig) flere metoder og
> attributter.
>

Ja, du har ret Måske er typecasting ikke det rigtige ord at bruge.

Mit problem er at KlasseA eksistere både på min server og klient, hvorimod
KlasseB og interface KlasseC kun eksistere på klienten. Når klienten
modtager KlasseA fra serveren, skulle den gerne "konverteres" til KlasseB,
som altså garanteret har KlasseC's metoder.

Den simple løsning ville selvfølgelig være at gemme KlasseA's instance i en
private variabel i KlasseB og så override alle KlasseA's metoder i KlasseB
til at get'te eller set'te i variablen. Jeg håbede bare på at en eller anden
smart programmør kunne et eller anden fikst lille constructor-trik så at
KlasseB "overtog" KlasseA's instance !

Venlig hilsen
Søren Staun Jørgensen
---
ssj@get2net.dk



Peter Lind (25-04-2001)
Kommentar
Fra : Peter Lind


Dato : 25-04-01 08:52


"Soren Staun Jorgensen" <ssj@get2net.dk> wrote in message
news:P3lF6.1130$S4.787692@news101.telia.com...
>
> Mit problem er at KlasseA eksistere både på min server og klient, hvorimod
> KlasseB og interface KlasseC kun eksistere på klienten. Når klienten
> modtager KlasseA fra serveren, skulle den gerne "konverteres" til KlasseB,
> som altså garanteret har KlasseC's metoder.

Ville den rigtigste løsning ikke være at lave en constructor i KlasseB, der
modtager et KlasseA objekt som argument ?
Denne KlasseB constructor skal så kalde en evt copy-constructor mht KlasseA
{ super( klasseAObjekt ); } eller også selv sætte alle (KlasseA) variable...

Iøvrigt, er der andre der ved om der findes nogle smarte (java-korrekte)
måder at lave sådan en copy-constructor på ?

mvh
Peter Lind



Ulrik Magnusson (25-04-2001)
Kommentar
Fra : Ulrik Magnusson


Dato : 25-04-01 10:43

Peter Lind wrote:

> "Soren Staun Jorgensen" <ssj@get2net.dk> wrote in message
> news:P3lF6.1130$S4.787692@news101.telia.com...
> > Mit problem er at KlasseA eksistere både på min server og klient, hvorimod
> > KlasseB og interface KlasseC kun eksistere på klienten. Når klienten
> > modtager KlasseA fra serveren, skulle den gerne "konverteres" til KlasseB,
> > som altså garanteret har KlasseC's metoder.

(hm, hvor kom dette citerede fra? Går sunsite nu amok igen?)

> Ville den rigtigste løsning ikke være at lave en constructor i KlasseB, der
> modtager et KlasseA objekt som argument ?
> Denne KlasseB constructor skal så kalde en evt copy-constructor mht KlasseA
> { super( klasseAObjekt ); } eller også selv sætte alle (KlasseA) variable...

Det lyder meget fornuftigt i mine ører.

> Iøvrigt, er der andre der ved om der findes nogle smarte (java-korrekte)
> måder at lave sådan en copy-constructor på ?

Man kan bruge clone() metoden. Iøvrigt er en fantastisk nyttig
(sikker, omend død-ineffektiv) klasse denne SerialCloneable,
som er angivet i Core Java 2:

public class SerialCloneable implements Cloneable, Serializable
{
public final Object clone()
{
try
{
ByteArrayOutputStream bout = new ByteArrayOutputStream();
ObjectOutputStream out = new ObjectOutputStream( bout );
out.writeObject(this);
out.close();
ByteArrayInputStream bin = new ByteArrayInputStream( bout.toByteArray() );
ObjectInputStream in = new ObjectInputStream( bin );
Object ret = in.readObject();
in.close();
return ret;
}
catch( Exception e )
{
// fejlhåndtering
}
}

når man så nedarver fra SerialCloneable, er man fri for at
implementere (og debugge) clone().

Ulrik Magnusson

--
"No method in our madness
just pride about our manner"
Adam & the Ants - "Kings of the Wild Frontier", do 1980
Visit my home page: http://www.geocities.com/ulrikm



Bertel Lund Hansen (25-04-2001)
Kommentar
Fra : Bertel Lund Hansen


Dato : 25-04-01 10:50

Ulrik Magnusson skrev:

>(hm, hvor kom dette citerede fra? Går sunsite nu amok igen?)

Nej, den lukker for "Sv:". Det er nok for klaringen på det
manglende indlæg (som jeg heller ikke har - fra samme server)

--
Bertel
http://lundhansen.dk/bertel/   FIDUSO: http://fiduso.dk/

Soren Staun Jorgense~ (25-04-2001)
Kommentar
Fra : Soren Staun Jorgense~


Dato : 25-04-01 15:41

>
> (hm, hvor kom dette citerede fra? Går sunsite nu amok igen?)
>

Den originale meddelelser er her - igen !

Søren Staun Jørgensen

>
> Bertel Lund Hansen <nospamto@lundhansen.dk> skrev
>
> > Det gør man da vel ikke? Det ville stride mod min (evt.
> > mangelfulde) forståelse hvis en stamklasse kan typecastes til en
> > afledt klasse. Den har jo (formodentlig) flere metoder og
> > attributter.
> >
>
> Ja, du har ret Måske er typecasting ikke det rigtige ord at bruge.
>
> Mit problem er at KlasseA eksistere både på min server og klient, hvorimod
> KlasseB og interface KlasseC kun eksistere på klienten. Når klienten
> modtager KlasseA fra serveren, skulle den gerne "konverteres" til KlasseB,
> som altså garanteret har KlasseC's metoder.
>
> Den simple løsning ville selvfølgelig være at gemme KlasseA's instance i
en
> private variabel i KlasseB og så override alle KlasseA's metoder i KlasseB
> til at get'te eller set'te i variablen. Jeg håbede bare på at en eller
anden
> smart programmør kunne et eller anden fikst lille constructor-trik så at
> KlasseB "overtog" KlasseA's instance !
>
> Venlig hilsen
> Søren Staun Jørgensen
> ---
> ssj@get2net.dk
>
>



Soren Staun Jorgense~ (25-04-2001)
Kommentar
Fra : Soren Staun Jorgense~


Dato : 25-04-01 15:45


Peter Lind <pl@edimatic.dk> skrev i en
nyhedsmeddelelse:VkvF6.59276$o4.5077799@news010.worldonline.dk...
>
> Ville den rigtigste løsning ikke være at lave en constructor i KlasseB,
der
> modtager et KlasseA objekt som argument ?
> Denne KlasseB constructor skal så kalde en evt copy-constructor mht
KlasseA
> { super( klasseAObjekt ); } eller også selv sætte alle (KlasseA)
variable...
>

Tjooo... Det er jeg også selv kommet frem til

Søren Staun Jørgensen

> Iøvrigt, er der andre der ved om der findes nogle smarte (java-korrekte)
> måder at lave sådan en copy-constructor på ?
>
> mvh
> Peter Lind
>
>



Ole Nielsby (25-04-2001)
Kommentar
Fra : Ole Nielsby


Dato : 25-04-01 01:28


Bertel Lund Hansen <nospamto@lundhansen.dk> skrev:

> Soren Staun Jorgensen skrev:
>
> >Hvordan "type caster" man så KlasseA til KlasseB uden at det giver en
> >ClassCastException
>
> Det gør man da vel ikke? Det ville stride mod min (evt.
> mangelfulde) forståelse hvis en stamklasse kan typecastes til en
> afledt klasse. Den har jo (formodentlig) flere metoder og
> attributter.

Nu er det jo ikke alt der er hvad det udgiver sig for at være.
I forhold til Java må man hele tiden holde sig for øje at en
variabels compile-time-type langt fra altid er identisk med
værdiens run-time-type, der både kan være null og en
subclass af compile-time-typen.

Explicit type-casting er groft sagt nødvendig i de tilfælde
hvor casting'en kan udløse en exception eller ændre værdien.

En undtagelse: et sikkert typecast kan gøres eksplicit for
at præcisere signaturen for et overloadet method call:

class Brik {}

....
void knald(Object o) {...klir...bang...krasj...}
void knald(Brik b) {sleep(100);}

....
Brik b=new Brik();

knald(b); // sleep(100);
knald((Object)b); // ...klir...bang...krasj...

(Ikke specielt nyttigt, men hvad....)





Ulrik Magnusson (24-04-2001)
Kommentar
Fra : Ulrik Magnusson


Dato : 24-04-01 20:37

Soren Staun Jorgensen wrote:

> Hej,
>
> Lad os antage at følgende ligger fast:
>
> public class KlasseA extends Object
> {
> ...bla bla
> }
>
> public class KlasseB extends KlasseA implements KlasseC
> {
> ...bla bla
> }
>
> public inteface KlasseC
> {
> ...bla bla
> }
>
> Hvordan "type caster" man så KlasseA til KlasseB uden at det giver en
> ClassCastException
> - altså noget lignende (KlasseB)KlasseA ????

Du laver et KlasseA objekt, checker med instancof, om det nu også er
sikkert og hvis det, konverterer du:

Eksempel 1:

KlasseA a = new KlasseB();//alle KlasseB objekter er også KlasseA
objekter
KlasseB b = (KlasseB)a;//måske ClassCastException, men i dette tilfælde
// véd vi at a er et KlasseB objekt

Eksempel 2:

void f( KlasseA a )// a er måske et KlasseB objekt
{
if( a instanceof KlasseB )//check om a nu også er af klassen KlasseB
{
KlasseB b = (KlasseB)a;// så kan vi konvertere sikkert
//brug b som KlasseB objekt
}
}

(Hvad bruges KlasseC til?)

Ulrik Magnusson

--
"Patriotism is the virtue of the vicious"
Oscar Wilde
Visit my home page: http://www.geocities.com/ulrikm



Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408929
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste