---

Hej,

Hvis jeg nu har to klasser

public class X { ... }
public class Y extends X { ... }

og en testklasse
public class Test { ... objekt = new X(parametre) ... }

Hvordan kan jeg så skrive X's constructor, sådan at jeg afhængigt af
parametrene nogle gange får returneret et X-objekt og andre gange et
Y-objekt?

Mvh
--
Jonas Møller Larsen

---

Det kan du ikke.

Lav i stedet en Factory class der kan returnere X'er i forskellige
varianter (f.eks. nogle gange Y). Denne Factory kunne implementeres som
en eller flere statiske metoder på X.

-dennis


Jonas Møller Larsen wrote:

> Hej,
>
> Hvis jeg nu har to klasser
>
> public class X { ... }
> public class Y extends X { ... }
>
> og en testklasse
> public class Test { ... objekt = new X(parametre) ... }
>
> Hvordan kan jeg så skrive X's constructor, sådan at jeg afhængigt af
> parametrene nogle gange får returneret et X-objekt og andre gange et
> Y-objekt?
>
> Mvh

---

Dennis Thrysøe wrote:
>
> Det kan du ikke.
>
> Lav i stedet en Factory class der kan returnere X'er i forskellige
> varianter (f.eks. nogle gange Y). Denne Factory kunne implementeres som
> en eller flere statiske metoder på X.

Aha, tak for svaret. Hvordan kan jeg gøre, hvis jeg allerede har
oprettet et objekt og senere ønsker at få det til at skifte klasse,
f.eks (hvor Y er en subklasse af X)

X object = new Y();
object.simplify();

og dette skal få object's klasse til at blive X?

Mvh
--
Jonas Møller Larsen

---

Jonas Møller Larsen wrote:

> Dennis Thrysøe wrote:
>
>> Det kan du ikke.
>>
>> Lav i stedet en Factory class der kan returnere X'er i forskellige
>> varianter (f.eks. nogle gange Y). Denne Factory kunne implementeres som
>> en eller flere statiske metoder på X.
>
>
> Aha, tak for svaret. Hvordan kan jeg gøre, hvis jeg allerede har
> oprettet et objekt og senere ønsker at få det til at skifte klasse,
> f.eks (hvor Y er en subklasse af X)
>
> X object = new Y();
> object.simplify();
>
> og dette skal få object's klasse til at blive X?


Det kan man heller ikke.

Men du kan løse det ved hjælp af et andet gammelt design-trick: en
copy-constructor.

Du laver en constructor på X der tager én parameter af typen X.

Denne constructor skal være i stand til at oprette et X objekt ud fra
det givene objekt (som kan være et Y).

X object = new Y();
object = new X(object);

eller

X object = new Y();
object = X.simplify(object);

Problemet er, at for at være et typestærkt sprog skal et objekt have en
type. Denne skal være den samme i hele levetiden. Forestil dig hvad der
ville ske hvis noget kode havde en reference til noget, som det troede
var en ansat, men pludslig er det bare en person. Duer ikke.

-dennis

---

Dennis Thrysøe wrote:
> Men du kan løse det ved hjælp af et andet gammelt design-trick: en
> copy-constructor.

Jeg ønsker heller ikke at skulle bekymre mig om den slags detaljer ude i
min testklasse, så jeg har løst problemet ved at definere endnu en
klasse, som kan referere til både X- og Y-objekter. Fra testklassen
bruger jeg så denne "kunstige" klasse.

> Forestil dig hvad der ville ske hvis noget kode havde en reference til noget,
> som det troede var en ansat, men pludslig er det bare en person. Duer ikke.

Hvorfor ikke? Jeg synes også, det er en dårlig idee at definere kunstige
klasser, som egentlig ikke har noget med problemet at gøre. Er det en
begrænsning i sproget, eller er det bare mig, der tænker på den forkerte
måde?

Jeg synes f.eks., det ville være naturligt at sige

Ansat a = new Ansat(parametre);
a.fyr();

hvorefter a refererer til et Person-objekt men nu kun med oplysninger om
navn, alder osv. men ikke længere om ansættelsesforhold.

--
Jonas Møller Larsen

---

Jonas Møller Larsen wrote:
>
> Dennis Thrysøe wrote:
> > Men du kan løse det ved hjælp af et andet gammelt design-trick: en
> > copy-constructor.
>
> Jeg ønsker heller ikke at skulle bekymre mig om den slags detaljer ude i
> min testklasse, så jeg har løst problemet ved at definere endnu en
> klasse, som kan referere til både X- og Y-objekter. Fra testklassen
> bruger jeg så denne "kunstige" klasse.
>
> > Forestil dig hvad der ville ske hvis noget kode havde en reference til noget,
> > som det troede var en ansat, men pludslig er det bare en person. Duer ikke.
>
> Hvorfor ikke? Jeg synes også, det er en dårlig idee at definere kunstige
> klasser, som egentlig ikke har noget med problemet at gøre. Er det en
> begrænsning i sproget, eller er det bare mig, der tænker på den forkerte
> måde?
>
> Jeg synes f.eks., det ville være naturligt at sige
>
> Ansat a = new Ansat(parametre);
> a.fyr();
>
> hvorefter a refererer til et Person-objekt men nu kun med oplysninger om
> navn, alder osv. men ikke længere om ansættelsesforhold.

Så bliver du nødt til at returnere en reference til det reviderede
objekt.

Altså

Person p = a.fyr();
a = null;

Du kan hoppe lige så meget du vil op og ned, men du kan ikke ændre din
variabel inden fra dit objekt med mindre du laver nogen meget
besynderlige krumspring.

--
Thorbjørn Ravn Andersen "...sound of...Tubular Bells!"
http://bigfoot.com/~thunderbear

---

Jonas Møller Larsen <jml@ifa.au.dk> skrev i en
nyhedsmeddelelse:3A9A8CF5.2A1AE42D@ifa.au.dk...
> Dennis Thrysøe wrote:
> > Men du kan løse det ved hjælp af et andet gammelt design-trick: en
> > copy-constructor.
>
> Jeg ønsker heller ikke at skulle bekymre mig om den slags detaljer ude i
> min testklasse, så jeg har løst problemet ved at definere endnu en
> klasse, som kan referere til både X- og Y-objekter. Fra testklassen
> bruger jeg så denne "kunstige" klasse.
>
> > Forestil dig hvad der ville ske hvis noget kode havde en reference til
noget,
> > som det troede var en ansat, men pludslig er det bare en person. Duer
ikke.
>
> Hvorfor ikke? Jeg synes også, det er en dårlig idee at definere kunstige
> klasser, som egentlig ikke har noget med problemet at gøre. Er det en
> begrænsning i sproget, eller er det bare mig, der tænker på den forkerte
> måde?
>
> Jeg synes f.eks., det ville være naturligt at sige
>
> Ansat a = new Ansat(parametre);
> a.fyr();
>
> hvorefter a refererer til et Person-objekt men nu kun med oplysninger om
> navn, alder osv. men ikke længere om ansættelsesforhold.
>
> --
> Jonas Møller Larsen

Jeg tror, at jeg bliver nødt til at give dig medhold i, at du ikke tænker på
den rigtige måde i denne situation.
Når et objekt bliver oprettet, vil dette objekt tilhøre samme klasse gennem
hele dets levetid.

Hvis du f.eks. har følgende klasser:
class Person{}
class Ansat extends Person {}

....og du gerne vil holde styr på både Personer og Ansatte i samme kontekst,
så bør du kun operere med referencer af klassen Person.

I Person kan du - som Dennis Thrysøe skrev - så have en copy constructor ala
følgende:
Person(Person p) {
.....
}

Som kan kopiere alle data fra et Person objekt over i et andet Person
objekt. Denne constructor vil kunne kaldes med objekter af klassen Person -
og alle subklasser af Person, f.eks. Ansat.

Dette vil - hvis jeg har forstået din hensigter korrekt - løse dit problem.

Ellers kan jeg ikke holdes personligt ansvarlig

Venlig hilsen
Jan Uhre