---

Hej gruppe,

jeg har siddet lidt og tænkt over en klasse af problemer, jeg støder ind
i. De er meget ens og jeg vil derfor nøjes med den jeg synes er mest
intuitiv.

Lad os forestille os at vi har et program med en masse tingester, der
flyver rundt og ramler ind i hinanden. Det man er interesseret i er at
simulerer resultatet af disse sammenstød på en realistisk måde. Hvis
hver tingest er repræsenteret af et objekt (af ikke nødvendigvis samme
klasse) ser man straks, at der er brug for n(n-1)/2 forskellige slags
sammenstødsmetoder, hvor n er antallet af forskellige type (klasser) af
tingester. Men hvor skal man gøre af dem? De hører "naturligt" til hos
hvert *par* af objekter/tingester, men dette virker som en lidt
mærkeligt måde at programmere på, især fordi at den giver en del
"par"-klasser selv for små n. F.eks. n=4->6 "par"-klasser.

Nogen der har alternative forslag?

mvh. Esben

---

Hej Esben

> Hvis
> hver tingest er repræsenteret af et objekt (af ikke nødvendigvis samme
> klasse) ser man straks, at der er brug for n(n-1)/2 forskellige slags
> sammenstødsmetoder, hvor n er antallet af forskellige type (klasser) af
> tingester. Men hvor skal man gøre af dem? De hører "naturligt" til hos
> hvert *par* af objekter/tingester, men dette virker som en lidt
> mærkeligt måde at programmere på, især fordi at den giver en del
> "par"-klasser selv for små n. F.eks. n=4->6 "par"-klasser.
>
> Nogen der har alternative forslag?

-med mindre at objekterne fusionerer når de mødes, så gætter jeg på at du er
interesseret i de to objekters måde at bevæge sig på bagefter. Eventuelle
tilstandsændringer i objektet kan flettes ind her.

alle objekter der er på banen skal have en metode hit(energi og retning),
der returnerer det ramte objektets nye retning og energi. (-og selvfølgelig
bevæger sig i denne retning efterfølgende)
Objekter der bevæger sig skal kunne opdage om de rammer noget.

-hvis problemet er mere genenrelt vil jeg anbefale at du kigger på hvilke
informationer klasserne har behov for at udveksle mellem hinanden.
håber du kan bruge det til noget.
mvh Jørn

---

Jørn Sibbern Askaa wrote:

> Hej Esben
>
>
>>Hvis
>>hver tingest er repræsenteret af et objekt (af ikke nødvendigvis samme
>>klasse) ser man straks, at der er brug for n(n-1)/2 forskellige slags
>>sammenstødsmetoder, hvor n er antallet af forskellige type (klasser) af
>>tingester. Men hvor skal man gøre af dem? De hører "naturligt" til hos
>>hvert *par* af objekter/tingester, men dette virker som en lidt
>>mærkeligt måde at programmere på, især fordi at den giver en del
>>"par"-klasser selv for små n. F.eks. n=4->6 "par"-klasser.
>>
>>Nogen der har alternative forslag?
>>
>


> -med mindre at objekterne fusionerer når de mødes, så gætter jeg på at du er
> interesseret i de to objekters måde at bevæge sig på bagefter. Eventuelle
> tilstandsændringer i objektet kan flettes ind her.
>
> alle objekter der er på banen skal have en metode hit(energi og retning),
> der returnerer det ramte objektets nye retning og energi. (-og selvfølgelig
> bevæger sig i denne retning efterfølgende)


Problemet er bare, at interaktionen mellem objekterne afhænger af hvilke
objekttyper (klasser) der støder sammen. Hvis objekterne f.eks. er
skumgummibolde og marmorkugler, så vil der være tre slags "hits":

skumgummibold+skumgummibold
marmorkugle+skumgummibold
marmorkugle+marmokugle

For at kunne simulerer et sammenstød skal et objekt altså have
infomation og kendskab til den anden type objekt, der stødes med. Ellers
ville jeg også sige at en hit(masse, hastighedsvektor, position) metode
på hvert objekt må være tilstrækkelig.

> Objekter der bevæger sig skal kunne opdage om de rammer noget.


Ja, dette problem er jo i virkeligheden af samme type. Hvis der både er
kugler og kasser er det jo tre forskellige kollisionsdetektionsrutiner,
der skal bruges.


> -hvis problemet er mere genenrelt vil jeg anbefale at du kigger på hvilke
> informationer klasserne har behov for at udveksle mellem hinanden.
> håber du kan bruge det til noget.

Ja, det er også sådan at jeg har lært det. Problemet er egentligt bare,
at jeg synes det er noget uelegant at skulle ændre på alle allerede
eksisterende objekter hvis jeg vil indføre et nyt. Derfor tænkte jeg på
at lave "par-klasser", der så hver havde en hitmetode og en
kollisionsdetektionsmetode. Men det giver på den anden side set en masse
klasser.

1000 tak for hjælpen,

mvh. Esben

---

>
> Problemet er bare, at interaktionen mellem objekterne afhænger af hvilke
> objekttyper (klasser) der støder sammen. Hvis objekterne f.eks. er
> skumgummibolde og marmorkugler, så vil der være tre slags "hits":
>
> skumgummibold+skumgummibold
> marmorkugle+skumgummibold
> marmorkugle+marmokugle
>

-for mig at se ligger opgaven stadig ikke i en blanding af objekter, men hos
de individuelle pårørende.
Hvis jeg rammer/bliver ramt af en anden, skal jeg afhængig af hvem den anden
er reagere forskelligt, derfor behøver jeg detaljeret information om hvordan
jeg skal opføre mig.

> For at kunne simulerer et sammenstød skal et objekt altså have
> infomation og kendskab til den anden type objekt, der stødes med. Ellers
> ville jeg også sige at en hit(masse, hastighedsvektor, position) metode
> på hvert objekt må være tilstrækkelig.
>
> > Objekter der bevæger sig skal kunne opdage om de rammer noget.
>
> Ja, dette problem er jo i virkeligheden af samme type. Hvis der både er
> kugler og kasser er det jo tre forskellige kollisionsdetektionsrutiner,
> der skal bruges.

klap hesten...
Bare start med at få en til at opdage hvis to objekter er inde i hinandens
sfære.
Viden er der brug for:
Der skal være en der ved hvor alle er, denne kan oplagt også være
kollisionsdetektor -den ved det hele -forudsat at alle objekter .fortæller
denne hvor de er.
Når man flytter sig, skal man så bare spørge samtidig om der er andre det
sted man er kommet til, hvis det er tilfældet, kan man vel bare få en
reference til den man rammer.

Her vil der givetvis komme nogle samtidighedsproblemer, om at objekterne
nærmest når at flette fuldstændig ind i hinanden, før nogen kan råbe op at
de er stødt sammen.


>
>
> > -hvis problemet er mere genenrelt vil jeg anbefale at du kigger på
hvilke
> > informationer klasserne har behov for at udveksle mellem hinanden.
> > håber du kan bruge det til noget.
>
> Ja, det er også sådan at jeg har lært det. Problemet er egentligt bare,
> at jeg synes det er noget uelegant at skulle ændre på alle allerede
> eksisterende objekter hvis jeg vil indføre et nyt. Derfor tænkte jeg på
> at lave "par-klasser", der så hver havde en hitmetode og en
> kollisionsdetektionsmetode. Men det giver på den anden side set en masse
> klasser.

jeg er stærkt imod ideen om at have en klasse der er en sammensmeltning af
flere klasser. Objektorienteringen ryger af h...... til hvis ikke alle
klasser er veldefineret. Et sammenstød der involverer mere en et objekt kan
vel godt resultere i metodekald i flere klasser.
Hvis du ikke vil ødelægge nogle fine klasser så lav nogle
interfaces/abstrakte superklasser, der implementerer kollisions-rutiner, og
flytte-rutiner

>
> 1000 tak for hjælpen,
selv tak
mvh Jørn

---

Jørn Sibbern Askaa wrote:

>>Problemet er bare, at interaktionen mellem objekterne afhænger af hvilke
>>objekttyper (klasser) der støder sammen. Hvis objekterne f.eks. er
>>skumgummibolde og marmorkugler, så vil der være tre slags "hits":
>>
>>skumgummibold+skumgummibold
>>marmorkugle+skumgummibold
>>marmorkugle+marmokugle
>>
> -for mig at se ligger opgaven stadig ikke i en blanding af objekter, men hos
> de individuelle pårørende.
> Hvis jeg rammer/bliver ramt af en anden, skal jeg afhængig af hvem den anden
> er reagere forskelligt, derfor behøver jeg detaljeret information om hvordan
> jeg skal opføre mig.


Så du foreslår noget i stil med
class SteelBall {
hit(SteelBall objekt) {}
hit(RubberBall objekt) {}
hit(Bomb objekt) {}
hit(SquishyGoo objekt) {}
[...]
addVelocityVector(Vektor v) {}
explode() { }
}

og tilsvarende for andre klasser? Jeg synes problemet med denne
angrebsvinkel er trefoldig:
(1) Antallet af metoder i hver klasse kan blive meget stor, hvilket
bryder med tommelfingerreglen om 3-7 metoder pr. klasse
(2) Alle klasser skal modificeres hver gang

(3) Alle klasser er stærkt koblet med alle andre klasser

Mens fordelene er :
(1) Ingen ekstra klasser. (og det er en stor fordel)
(2) Ingen par-klasser med meget få metoder (bryder med 3-7 metodereglen
hvis værd klasse blot har en hit-metode)


>>For at kunne simulerer et sammenstød skal et objekt altså have
>>infomation og kendskab til den anden type objekt, der stødes med. Ellers
>>ville jeg også sige at en hit(masse, hastighedsvektor, position) metode
>>på hvert objekt må være tilstrækkelig.
>>
>>
>>>Objekter der bevæger sig skal kunne opdage om de rammer noget.
>>>
>>Ja, dette problem er jo i virkeligheden af samme type. Hvis der både er
>>kugler og kasser er det jo tre forskellige kollisionsdetektionsrutiner,
>>der skal bruges.
>>
>
> klap hesten...


Klappe, klappe. Good boy


> Bare start med at få en til at opdage hvis to objekter er inde i hinandens
> sfære.
> Viden er der brug for:
> Der skal være en der ved hvor alle er, denne kan oplagt også være
> kollisionsdetektor -den ved det hele -forudsat at alle objekter .fortæller
> denne hvor de er.


Jeg havde nu mere forestillet mig at traversere lister, og så kalde hver
klasse med en detectCollision(Iterator detectFor) eller noget i den
stil. Så kan hver klasse se om den støder ind i nogen objekter. Jeg kan
ikke lide ideen om en klasser, der kender egenskaber for *alle*
objekter, men det er måske bare mig? Ville den klasse ikke blive hård at
vedligeholde?


> Når man flytter sig, skal man så bare spørge samtidig om der er andre det
> sted man er kommet til, hvis det er tilfældet, kan man vel bare få en
> reference til den man rammer.
>
> Her vil der givetvis komme nogle samtidighedsproblemer, om at objekterne
> nærmest når at flette fuldstændig ind i hinanden, før nogen kan råbe op at
> de er stødt sammen.


Plus at en sådan kollisionrutine vil håndtere tynde stænger meget
dårligt, da de kan risikere at nå forbi hinanden. Jeg ar bange for at
jeg blive nødt til at gå den hårde vej, men meget af matematikken er på
plads, og desuden er det min forte. Generelt vil jeg lave en rutine, der
givet en hastigheds og rotationsvektor og en Shape for to objekter kan
beregne når og hvis de støder sammen. Af performancehensyn skal alle
objekter nok have boundingboxes (eller måske bounding circles, det må
jeg tænke over)

[...]

>>Problemet er egentligt bare,
>>at jeg synes det er noget uelegant at skulle ændre på alle allerede
>>eksisterende objekter hvis jeg vil indføre et nyt. Derfor tænkte jeg på
>>at lave "par-klasser", der så hver havde en hitmetode og en
>>kollisionsdetektionsmetode. Men det giver på den anden side set en masse
>>klasser.
>>
> jeg er stærkt imod ideen om at have en klasse der er en sammensmeltning af
> flere klasser. Objektorienteringen ryger af h...... til hvis ikke alle
> klasser er veldefineret. Et sammenstød der involverer mere en et objekt kan
> vel godt resultere i metodekald i flere klasser.
> Hvis du ikke vil ødelægge nogle fine klasser så lav nogle
> interfaces/abstrakte superklasser, der implementerer kollisions-rutiner, og
> flytte-rutiner


Hmmm. Jeg har svært ved at følge dig her. En par-klasse (eller her, i
det konkrete tilfælde, interaktionsklasser) er da ganske veldefinerede.
Og jeg kan ikke se hvordan en abstrakt superklasse kan implementerer
meget mere end de mest grunlæggende rutiner, som f.eks. boundingbox-checket.


>>1000 tak for hjælpen,
>>
> selv tak

Det er skam meget værdsat

mvh. Esben

---

>
> Så du foreslår noget i stil med
> class SteelBall {
> hit(SteelBall objekt) {}
> hit(RubberBall objekt) {}
> hit(Bomb objekt) {}
> hit(SquishyGoo objekt) {}
> [...]
> addVelocityVector(Vektor v) {}
> explode() { }
> }

tja i det store hele, hvis nu alle disse objekter, havde en fælles super,
ville metode signaturen være forenklet til

hit(Dims objekt){}

her kan man så definere en default interaktion, der gør det lettere
implementere andre dimser senere. de specifikke metoder kunne være
hjælpemetoder, der ville gøre den centrale del af koden pæn

>
> og tilsvarende for andre klasser? Jeg synes problemet med denne
> angrebsvinkel er trefoldig:
> (1) Antallet af metoder i hver klasse kan blive meget stor, hvilket
> bryder med tommelfingerreglen om 3-7 metoder pr. klasse
Kan man ikke have nogle metoder explode(), bounce(), melt() mv. og så lade
sammenstødene resultere i en bestemt kombination af metoder?

> (2) Alle klasser skal modificeres hver gang
-derfor kunne en abstrakt superklasse sikre at alle dimser implementerede de
samme metoder
>
> (3) Alle klasser er stærkt koblet med alle andre klasser
ja, min svaghed, jeg understøtter ikke andet end hård aggregeringer.
>
> Mens fordelene er :
> (1) Ingen ekstra klasser. (og det er en stor fordel)
netop ahhhh
> (2) Ingen par-klasser med meget få metoder (bryder med 3-7 metodereglen
> hvis værd klasse blot har en hit-metode)
>
>
> >
> > klap hesten...
>
>
> Klappe, klappe. Good boy
*vrinsk*
>
>
> > Bare start med at få en til at opdage hvis to objekter er inde i
hinandens
> > sfære.
> > Viden er der brug for:
> > Der skal være en der ved hvor alle er, denne kan oplagt også være
> > kollisionsdetektor -den ved det hele -forudsat at alle objekter
..fortæller
> > denne hvor de er.
>
>
> Jeg havde nu mere forestillet mig at traversere lister, og så kalde hver
> klasse med en detectCollision(Iterator detectFor) eller noget i den
> stil. Så kan hver klasse se om den støder ind i nogen objekter. Jeg kan
> ikke lide ideen om en klasser, der kender egenskaber for *alle*
> objekter, men det er måske bare mig? Ville den klasse ikke blive hård at
> vedligeholde?

det er der sikkert, med tingene sat på spidsen, så kender den klasse der har
listen alle dimser i dit system. Jeg ser dimserne som selvstændige tråde der
bare bevæger sig i en retning, og i hvert "time step" fortæller big brother
om der er nogen på det felt hvor en dims er kommet til. hvis der er, kan
dimsen få en "offer" reference, og de kan lege sammen.

hvis den skal vide noget, så må det være hvor alle er, og hvis den skal vide
meget, skal den også vide hvor dimser er på vej hen.
>
>
> > Når man flytter sig, skal man så bare spørge samtidig om der er andre
det
> > sted man er kommet til, hvis det er tilfældet, kan man vel bare få en
> > reference til den man rammer.
> >
> > Her vil der givetvis komme nogle samtidighedsproblemer, om at objekterne
> > nærmest når at flette fuldstændig ind i hinanden, før nogen kan råbe op
at
> > de er stødt sammen.
>
>
> Plus at en sådan kollisionrutine vil håndtere tynde stænger meget
> dårligt, da de kan risikere at nå forbi hinanden.

hvis nu stregen havde en buffer, kunne big brother bare gøre opmærksom på at
man er tæt på

>Jeg er bange for at
> jeg blive nødt til at gå den hårde vej, men meget af matematikken er på
> plads, og desuden er det min forte. Generelt vil jeg lave en rutine, der
> givet en hastigheds og rotationsvektor og en Shape for to objekter kan
> beregne når og hvis de støder sammen. Af performancehensyn skal alle
> objekter nok have boundingboxes (eller måske bounding circles, det må
> jeg tænke over)
box/polygon finten er vel også det der ses i nymodens skydespil, hvor man
under ugunstige forhold kan stå inde i hinanden.


>
> [...]
>
> >>Problemet er egentligt bare,
> >>at jeg synes det er noget uelegant at skulle ændre på alle allerede
> >>eksisterende objekter hvis jeg vil indføre et nyt. Derfor tænkte jeg på
> >>at lave "par-klasser", der så hver havde en hitmetode og en
> >>kollisionsdetektionsmetode. Men det giver på den anden side set en masse
> >>klasser.
> >>
> > jeg er stærkt imod ideen om at have en klasse der er en sammensmeltning
af
> > flere klasser. Objektorienteringen ryger af h...... til hvis ikke alle
> > klasser er veldefineret. Et sammenstød der involverer mere en et objekt
kan
> > vel godt resultere i metodekald i flere klasser.
> > Hvis du ikke vil ødelægge nogle fine klasser så lav nogle
> > interfaces/abstrakte superklasser, der implementerer kollisions-rutiner,
og
> > flytte-rutiner
>
>
> Hmmm. Jeg har svært ved at følge dig her. En par-klasse (eller her, i
> det konkrete tilfælde, interaktionsklasser) er da ganske veldefinerede.
> Og jeg kan ikke se hvordan en abstrakt superklasse kan implementerer
> meget mere end de mest grunlæggende rutiner, som f.eks.
boundingbox-checket.

I min simple, men rare objektorienterede verden, kan jeg ikke lide tanken om
at man skal bruge hjælpe objekter til at udtrykke et givent fællesskab
mellem to klasser (jeg ville foretrække en højere kobling, hvis de da har
noget til fælles). Det kan godt være at jeg enten er for traditionel, eller
for moderne.

>
>
> >>1000 tak for hjælpen,
> >>
> > selv tak
>
> Det er skam meget værdsat
>
Det er det jo nok,
det er jo ren underholdning det her, man forestiller sig hvad det kunne føre
til med et rigtigt whiteboard og en stribe flasker med dug på siden...

god arbejdslyst

hilsen Jørn

---

Jørn Sibbern Askaa wrote:

>>Så du foreslår noget i stil med
>>class SteelBall {
>> hit(SteelBall objekt) {}
>> hit(RubberBall objekt) {}
>> hit(Bomb objekt) {}
>> hit(SquishyGoo objekt) {}
>> [...]
>> addVelocityVector(Vektor v) {}
>> explode() { }
>>}
>>
>
> tja i det store hele, hvis nu alle disse objekter, havde en fælles super,
> ville metode signaturen være forenklet til
>
> hit(Dims objekt){}
>
> her kan man så definere en default interaktion, der gør det lettere
> implementere andre dimser senere. de specifikke metoder kunne være
> hjælpemetoder, der ville gøre den centrale del af koden pæn
>


Ikke forstået :-/ Hvis vi nu bare siger at vi siger at Dims er
superklasse til alle mine objekter, og min SteelBall (som selvfølgeligt
nedarver fra Dims) bliver kaldt med hit(Dime objekt), så må SteelBall
skulle opfører sig forskelligt afhængigt af hvilken udnerklasse af Dims
den er blevet kaldt med. Men medmindre man bruge instaceof() eller
lignende (som jeg har ladet mig fortælle man skal undgå), hvordan skal
hit() så kunne vide hvad den skal gøre?


>>og tilsvarende for andre klasser? Jeg synes problemet med denne
>>angrebsvinkel er trefoldig:
>>(1) Antallet af metoder i hver klasse kan blive meget stor, hvilket
>>bryder med tommelfingerreglen om 3-7 metoder pr. klasse
>>
> Kan man ikke have nogle metoder explode(), bounce(), melt() mv. og så lade
> sammenstødene resultere i en bestemt kombination af metoder?


Jo, men det ændrer ikke ved at der er mange metoder, ejheller ved at
hvis jeg tilføjer en ny Dims, så skal alle andre Dims-objekter rettes.


>
>>(2) Alle klasser skal modificeres hver gang
>>
> -derfor kunne en abstrakt superklasse sikre at alle dimser implementerede de
> samme metoder


Ja, det er så dette jeg ikke forstår. Se ovenfor.


[...]


>>
>>Jeg havde nu mere forestillet mig at traversere lister, og så kalde hver
>>klasse med en detectCollision(Iterator detectFor) eller noget i den
>>stil. Så kan hver klasse se om den støder ind i nogen objekter. Jeg kan
>>ikke lide ideen om en klasser, der kender egenskaber for *alle*
>>objekter, men det er måske bare mig? Ville den klasse ikke blive hård at
>>vedligeholde?
>>
>
> det er der sikkert, med tingene sat på spidsen, så kender den klasse der har
> listen alle dimser i dit system. Jeg ser dimserne som selvstændige tråde der
> bare bevæger sig i en retning, og i hvert "time step" fortæller big brother
> om der er nogen på det felt hvor en dims er kommet til. hvis der er, kan
> dimsen få en "offer" reference, og de kan lege sammen.


Mens det er sandt at listen kender alle objekter, så kender den kun
objekterne på et meget højt plan. Mere specielt kun til deres eksistens
indenfor listens område (Sidstnævnte af performancehensyn). Mere konkret
kender listen kun til Dimser, men ikke noget til deres interne tilstande
(position, fart, bane e.t.c.) "Listen" kan så konceptuelt kalde hvert
par af Dimser med isHit(Dims dims). Men igen, måske hører det mere
hjemmme er par-klasser?


> hvis den skal vide noget, så må det være hvor alle er, og hvis den skal vide
> meget, skal den også vide hvor dimser er på vej hen.


Det mener jeg ikke er nødvendigt, endsige ønskværdigt.

[...]

>>Jeg er bange for at
>>jeg blive nødt til at gå den hårde vej, men meget af matematikken er på
>>plads, og desuden er det min forte. Generelt vil jeg lave en rutine, der
>>givet en hastigheds og rotationsvektor og en Shape for to objekter kan
>>beregne når og hvis de støder sammen. Af performancehensyn skal alle
>>objekter nok have boundingboxes (eller måske bounding circles, det må
>>jeg tænke over)
>>
> box/polygon finten er vel også det der ses i nymodens skydespil, hvor man
> under ugunstige forhold kan stå inde i hinanden.


De spil opererer på meget anderledes præmisser; jeg tror ikke det i mit
tilfælde ville være væsentligt hurtigere. Jeg har ikke tænkt mig at
opererer med >1000 objekter, mens disse spil jo ofte arbejder med mere
end 1000 trekanter.

[...]

>>Hmmm. Jeg har svært ved at følge dig her. En par-klasse (eller her, i
>>det konkrete tilfælde, interaktionsklasser) er da ganske veldefinerede.
>> Og jeg kan ikke se hvordan en abstrakt superklasse kan implementerer
>>meget mere end de mest grunlæggende rutiner, som f.eks.
>>
> boundingbox-checket.
>
> I min simple, men rare objektorienterede verden, kan jeg ikke lide tanken om
> at man skal bruge hjælpe objekter til at udtrykke et givent fællesskab
> mellem to klasser (jeg ville foretrække en højere kobling, hvis de da har
> noget til fælles). Det kan godt være at jeg enten er for traditionel, eller
> for moderne.


Jeg synes nu at have lært at man altid skal bruge sådanne objekter hvor
man har en "mange til mange" korrespodance. Det er måske egentligt det
der er tilfældet her.

Der er jo kommet en hel lang debat ud af det her. En skam at der ikke er
flere :)

mvh. Esben

P.S: Selv om jeg kom til at cutte det tror jeg også dette kunne være
sjovt at være nogen stykker om. Men det sker jo sjældent i det private :-/

---

hej igen, undskyld svartiden.

> > tja i det store hele, hvis nu alle disse objekter, havde en fælles
super,
> > ville metode signaturen være forenklet til
> >
> > hit(Dims objekt){}
> >
> > her kan man så definere en default interaktion, der gør det lettere
> > implementere andre dimser senere. de specifikke metoder kunne være
> > hjælpemetoder, der ville gøre den centrale del af koden pæn
> >
>
>
> Ikke forstået :-/ Hvis vi nu bare siger at vi siger at Dims er
> superklasse til alle mine objekter, og min SteelBall (som selvfølgeligt
> nedarver fra Dims) bliver kaldt med hit(Dime objekt), så må SteelBall
> skulle opfører sig forskelligt afhængigt af hvilken udnerklasse af Dims
> den er blevet kaldt med. Men medmindre man bruge instaceof() eller
> lignende (som jeg har ladet mig fortælle man skal undgå), hvordan skal
> hit() så kunne vide hvad den skal gøre?
>

ja, alle subklasser af Dims, skal implementere metoden hit(Dims d){...}
-og dermed overskrive en eventuel default metode i superklassen.

abstract class Dims
{

public abstract String getType();

public void hit(Dims d)
{
if (dims.getType().equals(SteelBall))
{
...hvad nu end der ville være interessant
}

else if(hoppebold)

else
{
default metode, evt fuldstændig elastisk. eller lign
-sikrer at nye objekter har en adfærd til at starte med
}
}//end hit


}//end class

hvis alle obj implementerer denne klasse ligger hele systemets adfærd ved
kollision i en klasse, som alle skal nedarve fra for at være med i legen.
eventuel reaktion i den klasse der kalder hit(), kan gives med returtypen.
(som simpel type, der signalerer hvad gerningsmanden gør efterfølgende eller
et obj der pakker alle bevægelses attributter ind.)

Jeg kan heller ikke lide instanceof(), men det er mest fordi at det
medfølgende objekt kan være alt fra en JTable til et Class objekt. Med
klassen Dims, sikrer man sig at der ikke kan komme "Fremmede" objekter til.
Så kan jeg klare min egen getType(), der viser mig hvad der er med som
parameter.

>
>
> Mens det er sandt at listen kender alle objekter, så kender den kun
> objekterne på et meget højt plan. Mere specielt kun til deres eksistens
> indenfor listens område (Sidstnævnte af performancehensyn). Mere konkret
> kender listen kun til Dimser, men ikke noget til deres interne tilstande
> (position, fart, bane e.t.c.) "Listen" kan så konceptuelt kalde hvert
> par af Dimser med isHit(Dims dims). Men igen, måske hører det mere
> hjemmme er par-klasser?

Med denne meget lave kobling kommer der bare et meget stort antal metodekald
i hele systemet, hvor en stor del af kaldene ef overføldige. Om dette er en
stor ulempe ved jeg ikke. Det lyder til at virke.

> Jeg synes nu at have lært at man altid skal bruge sådanne objekter hvor
> man har en "mange til mange" korrespodance. Det er måske egentligt det
> der er tilfældet her.

Det har jeg ikke lært, men dermed ikke sagt at det er forkert, men jeg har
lavet relationsklasser en gang, og det faldt ikke udpræget i min lærers
smag, nærmest tværtimod...
(Ivar Jacobson inspireret lærer)

>
> Der er jo kommet en hel lang debat ud af det her. En skam at der ikke er
> flere :)
ja
Kom an skabs-systemudviklere, vi ved i er der!!!!

> P.S: Selv om jeg kom til at cutte det tror jeg også dette kunne være
> sjovt at være nogen stykker om. Men det sker jo sjældent i det private :-/

måske en slags sommerseminar for systemudviklere, eller hvordan?


Hav det pænt, og god fornøjelse.
hilsen Jørn

---

Jørn Sibbern Askaa wrote:

> hej igen, undskyld svartiden.
>
>


[...]

>>Ikke forstået :-/ Hvis vi nu bare siger at vi siger at Dims er
>>superklasse til alle mine objekter, og min SteelBall (som selvfølgeligt
>>nedarver fra Dims) bliver kaldt med hit(Dime objekt), så må SteelBall
>>skulle opfører sig forskelligt afhængigt af hvilken udnerklasse af Dims
>>den er blevet kaldt med. Men medmindre man bruge instaceof() eller
>>lignende (som jeg har ladet mig fortælle man skal undgå), hvordan skal
>>hit() så kunne vide hvad den skal gøre?
>>
>>
>
> ja, alle subklasser af Dims, skal implementere metoden hit(Dims d){...}
> -og dermed overskrive en eventuel default metode i superklassen.
>
> abstract class Dims
> {
>
> public abstract String getType();
>
> public void hit(Dims d)
> {
> if (dims.getType().equals(SteelBall))
> {
> ...hvad nu end der ville være interessant
> }
>
> else if(hoppebold)
>
> else
> {
> default metode, evt fuldstændig elastisk. eller lign
> -sikrer at nye objekter har en adfærd til at starte med
> }
> }//end hit
>
>
> }//end class
>
> hvis alle obj implementerer denne klasse ligger hele systemets adfærd ved
> kollision i en klasse, som alle skal nedarve fra for at være med i legen.
> eventuel reaktion i den klasse der kalder hit(), kan gives med returtypen.
> (som simpel type, der signalerer hvad gerningsmanden gør efterfølgende eller
> et obj der pakker alle bevægelses attributter ind.)


Det er faktisk en god ide. Jeg kan godt lide ideen med getType(). På den
måde kan man have en switch (getType()) {...}, hvilket ville være
hurtigt og effektivt. Lad mig straks starte forte :) Jeg kan endda
defaulte til et fuldstændigt elastisk stød (f.eks.)


> Jeg kan heller ikke lide instanceof(), men det er mest fordi at det
> medfølgende objekt kan være alt fra en JTable til et Class objekt. Med
> klassen Dims, sikrer man sig at der ikke kan komme "Fremmede" objekter til.
> Så kan jeg klare min egen getType(), der viser mig hvad der er med som
> parameter.



Ja, det er en god ide.


>>Mens det er sandt at listen kender alle objekter, så kender den kun
>>objekterne på et meget højt plan. Mere specielt kun til deres eksistens
>>indenfor listens område (Sidstnævnte af performancehensyn). Mere konkret
>>kender listen kun til Dimser, men ikke noget til deres interne tilstande
>>(position, fart, bane e.t.c.) "Listen" kan så konceptuelt kalde hvert
>>par af Dimser med isHit(Dims dims). Men igen, måske hører det mere
>>hjemmme er par-klasser?
>>
>
> Med denne meget lave kobling kommer der bare et meget stort antal metodekald
> i hele systemet, hvor en stor del af kaldene ef overføldige. Om dette er en
> stor ulempe ved jeg ikke. Det lyder til at virke.


Antallet af metodekald er egentligt ikke større. Hvis vi nu for
simpelthedens skyld siger at listen inkluderer alle n objekter ville det
medfører (n-1)*n/2 kald. Hvis vi har et stort objekt der kender alle
objekterne skal den udfører lige så mange tests. Det kan man så forbedre
ved at dele listen op i flere områder.

!-----+-----!
! a ! b !
!-----+-----!
! c ! d !
!-----+-----!

Der er så lidt fnadder med objekter der lapper ind i flere lister, men
jeg tror det lettest løses ved at sætte objekterne i begge lister. I så
fald bliver antallet af test (best case)
((n-1)*n/2)/4+4.

idet hvert objekt kun skal testes med en 1/4 del af objekterne. Til
gengæld er der fire ekstra tests (mod indelingen. I virkeligheden
overdriver jeg lidt her, men skidt nu med det.) Worst case er
selvfølgeligt at alle ligge i krydset, hvorved vi får alt for mange
tests. Jeg vil se på hvor tit det sker før jeg gør noget ved det :)

>>Jeg synes nu at have lært at man altid skal bruge sådanne objekter hvor
>>man har en "mange til mange" korrespodance. Det er måske egentligt det
>>der er tilfældet her.
>>
> Det har jeg ikke lært, men dermed ikke sagt at det er forkert, men jeg har
> lavet relationsklasser en gang, og det faldt ikke udpræget i min lærers
> smag, nærmest tværtimod...
> (Ivar Jacobson inspireret lærer)


Tjah. Det kommer nok an på situationen. Men mon dog man ønsker en
situation, hvor objekter fra to klasser alle skal holde på en liste af
objekter fra en den anden klasse? Der vil en relationsklasse nok være at
foiretrække... (jeg kan ikke huske hvad vores instruktør hed (det var et
kursus). Jeg er matematiker og ikke datalog, så jeg har først lært teori
efter studiet.)


> måske en slags sommerseminar for systemudviklere, eller hvordan?




> Hav det pænt, og god fornøjelse.

tak og i lige måde.

---

Esben Mose Hansen wrote:
> Lad os forestille os at vi har et program med en masse tingester, der
> flyver rundt og ramler ind i hinanden. Det man er interesseret i er at
> simulerer resultatet af disse sammenstød på en realistisk måde.

Hvad skal der ske hvis to objekter støder sammen?

--
Jonas Kongslund, http://kongslund.dk

---

Jonas Kongslund wrote:

> Esben Mose Hansen wrote:
>
>>Lad os forestille os at vi har et program med en masse tingester, der
>>flyver rundt og ramler ind i hinanden. Det man er interesseret i er at
>>simulerer resultatet af disse sammenstød på en realistisk måde.
>>
>
> Hvad skal der ske hvis to objekter støder sammen?
>


Der er mange muligheder, men man kunne forestille sig flere ting:
*fuldstændig elastisk stød* --- begge objekter får tilført en
hastighedsvektor vinkelret på sammenstødspunktet-

*fuldstændig uelastisk stød* --- objekterne hænger sammen, fortsætter
med samme hastighed

*eksplosion* --- det ene eller begge objeter splittes i flere dele, hvis
nye hastighed bliver fundet på en mere eller mindre tilfældig måde.

Find selv på flere Det er jeg prøver at illustrere er mere et
"pattern" end en konkret problemstilling. Selvom jeg idag bare er
interesseret i fuldstændig elastiske stød, kunne jeg godt tænke mig i
fremtiden at uvide det med en eller flere af ovenstående --- og måske
med noget jeg slet ikke har tænkt på endnu.

mvh. Esben

P.S: Tak for interessen!

---

Esben Mose Hansen wrote:
> Der er mange muligheder, men man kunne forestille sig flere ting:
> *fuldstændig elastisk stød* --- begge objekter får tilført en
> hastighedsvektor vinkelret på sammenstødspunktet-
>
[...snip...]

Kan man forvente at det system, du ønsker at lave har et fast antal
hændelsestyper (f.eks. fuldstændig elastisk stød)?

Opførslen for to objekter, der støder sammen er dermed afhængig af to
ting:
- hændelsestypen
- objekternes type

Den sidste faktor er træls idet man bliver nødt til at give systemet
informationer for hver mulig kombination af objekttyper, men man kommer
ikke uden om det. To mulige måder, som du selv foreslog, er enten at
lægge informationerne i det enkelte objekt eller lave parklasser. Første
løsningsmulighed giver en stærk kobling, som gør systemet svært at
udvide, mens den anden også bidrager med en masse ekstra klasser.

Hvis den enkelte hændelsestype kan laves tilstrækkelig generel, så må
det være muligt at parametrisere den med regler for de
tilstandsændringer der skal ske, såfremt to objekter af type t1 og t2
støder sammen. Dermed kan du lagre reglerne for hver hændelsestype i en
matrix, hvilket vil gøre udvidelse af systemet mere smertefrit.

--
Jonas Kongslund

---

Jonas Kongslund wrote:

> Esben Mose Hansen wrote:
>
>>Der er mange muligheder, men man kunne forestille sig flere ting:
>>*fuldstændig elastisk stød* --- begge objekter får tilført en
>>hastighedsvektor vinkelret på sammenstødspunktet-
>>
>>
> [...snip...]
>
> Kan man forvente at det system, du ønsker at lave har et fast antal
> hændelsestyper (f.eks. fuldstændig elastisk stød)?


Lidt enkere end det, endda, fordi jeg forestille mig at to objekters
sammenstød altid giver samme hændelse, i.e. der findes en afbildning af
ObjekttyperxObjektyper->Hændelser.


> Opførslen for to objekter, der støder sammen er dermed afhængig af to
> ting:
> - hændelsestypen
> - objekternes type


Det er lidt mere generalt, men ja.


> Den sidste faktor er træls idet man bliver nødt til at give systemet
> informationer for hver mulig kombination af objekttyper, men man kommer
> ikke uden om det. To mulige måder, som du selv foreslog, er enten at
> lægge informationerne i det enkelte objekt eller lave parklasser. Første
> løsningsmulighed giver en stærk kobling, som gør systemet svært at
> udvide, mens den anden også bidrager med en masse ekstra klasser.


Det var også min konklusion. Jeg håber nogen giver mig uret :)


> Hvis den enkelte hændelsestype kan laves tilstrækkelig generel, så må
> det være muligt at parametrisere den med regler for de
> tilstandsændringer der skal ske, såfremt to objekter af type t1 og t2
> støder sammen. Dermed kan du lagre reglerne for hver hændelsestype i en
> matrix, hvilket vil gøre udvidelse af systemet mere smertefrit.


Jeg det ville jeg kunne gøre, og det bliver nok sådan det komme til at
ske. Men man drømmer jo altid om at finde den perfekte løsning


1000 tak for råd&vejledning!


mvh. Esben

---

"Esben Mose Hansen" <esbenSLETMIG@oek.dk> skrev i en meddelelse
news:3B12A73F.9030904@oek.dk...
> Jonas Kongslund wrote:
>
> > Esben Mose Hansen wrote:
> >
> >>Der er mange muligheder, men man kunne forestille sig flere ting:
> >>*fuldstændig elastisk stød* --- begge objekter får tilført en
> >>hastighedsvektor vinkelret på sammenstødspunktet-
> >>
> >>
> > [...snip...]
> >
> > Kan man forvente at det system, du ønsker at lave har et fast antal
> > hændelsestyper (f.eks. fuldstændig elastisk stød)?
>
>
> Lidt enkere end det, endda, fordi jeg forestille mig at to objekters
> sammenstød altid giver samme hændelse, i.e. der findes en afbildning af
> ObjekttyperxObjektyper->Hændelser.
>
>
> > Opførslen for to objekter, der støder sammen er dermed afhængig af to
> > ting:
> > - hændelsestypen
> > - objekternes type
>
>
> Det er lidt mere generalt, men ja.
>
>
> > Den sidste faktor er træls idet man bliver nødt til at give systemet
> > informationer for hver mulig kombination af objekttyper, men man kommer
> > ikke uden om det. To mulige måder, som du selv foreslog, er enten at
> > lægge informationerne i det enkelte objekt eller lave parklasser. Første
> > løsningsmulighed giver en stærk kobling, som gør systemet svært at
> > udvide, mens den anden også bidrager med en masse ekstra klasser.
>
>
> Det var også min konklusion. Jeg håber nogen giver mig uret :)
>
>
> > Hvis den enkelte hændelsestype kan laves tilstrækkelig generel, så må
> > det være muligt at parametrisere den med regler for de
> > tilstandsændringer der skal ske, såfremt to objekter af type t1 og t2
> > støder sammen. Dermed kan du lagre reglerne for hver hændelsestype i en
> > matrix, hvilket vil gøre udvidelse af systemet mere smertefrit.

Problemet kommer jo når det skal være generelt - dvs når du ikke vil lave
alt for meget ekstra fordi du indfører en GummiBoldMedGlimmer underklasse
til klassen GummiBold, og det i øvrigt ikke påvirker kollisionen.

Antag vi har klassehierarkier Dims->A->AA og Dims->B->BB
Når nu en AA og en BB støder sammen, skal vi altså lede efter mapninger for
AA + BB, A + BB, Dims + BB, AA + B, AA + Dims, A + B, A + Dims, Dims + B og
Dims + Dims

Og det er jo ikke oplagt hvad der er den "bedste match" - er det A + BB
eller AA + B? Vi ønsker vel atlid at der vælges
ens og at valget ikke afhænger af hvad der kommer først. Sagt på en anden
måde: mapning(X,Y) == Mapning(Y,X) for alle X og Y.

En simpel måde at løse det på ville være at lave en hashtabel, der brugte
et sorteret par af klasser som index og gav en hændelse som resultat - men
det løser stadig ikke problemet med hvordan man vælger hvilken rækkefølge
kombinationerne af forældreklasser skal gennemløbes. Desuden er det vel ret
meget overhead.

God fornøjelse

Niels Harremoës

---

Niels Ull Harremoës wrote:

>>>Den sidste faktor er træls idet man bliver nødt til at give systemet
>>>informationer for hver mulig kombination af objekttyper, men man kommer
>>>ikke uden om det. To mulige måder, som du selv foreslog, er enten at
>>>lægge informationerne i det enkelte objekt eller lave parklasser. Første
>>>løsningsmulighed giver en stærk kobling, som gør systemet svært at
>>>udvide, mens den anden også bidrager med en masse ekstra klasser.
>>>
>>Det var også min konklusion. Jeg håber nogen giver mig uret :)
>>
>>>Hvis den enkelte hændelsestype kan laves tilstrækkelig generel, så må
>>>det være muligt at parametrisere den med regler for de
>>>tilstandsændringer der skal ske, såfremt to objekter af type t1 og t2
>>>støder sammen. Dermed kan du lagre reglerne for hver hændelsestype i en
>>>matrix, hvilket vil gøre udvidelse af systemet mere smertefrit.
>>>
>
> Problemet kommer jo når det skal være generelt - dvs når du ikke vil lave
> alt for meget ekstra fordi du indfører en GummiBoldMedGlimmer underklasse
> til klassen GummiBold, og det i øvrigt ikke påvirker kollisionen.


Det ville være rart, ja.

>
> Antag vi har klassehierarkier Dims->A->AA og Dims->B->BB
> Når nu en AA og en BB støder sammen, skal vi altså lede efter mapninger for
> AA + BB, A + BB, Dims + BB, AA + B, AA + Dims, A + B, A + Dims, Dims + B og
> Dims + Dims
>
> Og det er jo ikke oplagt hvad der er den "bedste match" - er det A + BB
> eller AA + B? Vi ønsker vel atlid at der vælges
> ens og at valget ikke afhænger af hvad der kommer først. Sagt på en anden
> måde: mapning(X,Y) == Mapning(Y,X) for alle X og Y.
>
> En simpel måde at løse det på ville være at lave en hashtabel, der brugte
> et sorteret par af klasser som index og gav en hændelse som resultat - men
> det løser stadig ikke problemet med hvordan man vælger hvilken rækkefølge
> kombinationerne af forældreklasser skal gennemløbes. Desuden er det vel ret
> meget overhead.
>

Overhead'en til "hits" i ovennævnte problem er selvfølgelig lille, men
uacceptable i "collisiondetection". Men det er da en idet at bruge en
hashtable. Noget at tænke over, i hvert fald. Ang. hvilke man vælger kan
man jo sige, at man altid vælger det yderste led i
nedarvningshierakiet. Ang. symmetri mapning(X,Y)=mapning(Y,X) kunne man
vel blot lave tabellen symmetrisk. For at opsummere ville tabellen
opfylde symmetri egenskaben samt at mapning er en afbildning af en
produktmængde. (og altså ikke en delmængde af en produktmængde.)

Dette kunne man klarer ved at erklærer en getKey() metode i klaasen
Dims. Hvis man vil med i hashtabellen må man implementere denne metode,
ellers nedarver man bare. Så må man så bare spørge først den ene part i
et par af Dims'er om denne har en metode til at håndtere intekraktionen
(hit, f.eks.). Hvis den ene part ikke har må man spørge den anden. Hvis
denne part heller ikke har smider man en exception, defaulter eller hvad
man nu kan finde på. Man kunne f.eks. vandrer opad i nedarvninghierakiet.

Det synes jeg faktisk er den bedste løsning endnu! Det begynder at
ligne noget

Tak for iput!
/
mvh. Esben

---

Esben Mose Hansen <esbenSLETMIG@oek.dk> writes:

> Nogen der har alternative forslag?

Måske et Visitor pattern:
http://c2.com/cgi/wiki?VisitorPattern
http://www.javaworld.com/javaworld/javatips/jw-javatip98.html