Lukekaa tarkkaan, törmäätte tähän joskus kuitenkin (example-kohta selventää ongelmaa, jos ei muuten tuttu):
http://en.wikipedia.org/wiki/Multiple_dispatch
Henkilökohtaisesti törmäsin aikoinaan ko. ongelmaan jo muutaman viikon C :n opiskelun aikana. Aluksi oletin että C hoitaa homman automaattisesti ajon aikana, koska sitä polymorfismia oli niin hehkutettu. Mitään siistiä ratkaisua en löytänyt, joka aiheutti "slarba otsassa"-ilmiötä, eteenkin kun Stroustrup lupaili kymmentä kivaa ja kahtatoista kaunista "klasikko" C ohjelmointi kirjassaan (jota käytin oppikirjana. http://www.huuto.net/fi/showitem.php3?itemid=52366529 Taidan poltaa ko. opuksen). Olisi ollut rehellistä kertoa ettei kieli tue muuta kuin "single dispatch":ä, mutta eihän sitä 942 sivuun mahtunut. Vituttaa vieläkin.
Ihmeellistä on Lispin pioneerisuus tässäkin tapauksessa ja johtavien OO-kielten (C , Java) alkeellisuus. (Lisää esim. http://www.paulgraham.com/icad.html kohta "What Made Lisp Different").
http://en.wikipedia.org/wiki/Multiple_dispatch
Henkilökohtaisesti törmäsin aikoinaan ko. ongelmaan jo muutaman viikon C :n opiskelun aikana. Aluksi oletin että C hoitaa homman automaattisesti ajon aikana, koska sitä polymorfismia oli niin hehkutettu. Mitään siistiä ratkaisua en löytänyt, joka aiheutti "slarba otsassa"-ilmiötä, eteenkin kun Stroustrup lupaili kymmentä kivaa ja kahtatoista kaunista "klasikko" C ohjelmointi kirjassaan (jota käytin oppikirjana. http://www.huuto.net/fi/showitem.php3?itemid=52366529 Taidan poltaa ko. opuksen). Olisi ollut rehellistä kertoa ettei kieli tue muuta kuin "single dispatch":ä, mutta eihän sitä 942 sivuun mahtunut. Vituttaa vieläkin.
Ihmeellistä on Lispin pioneerisuus tässäkin tapauksessa ja johtavien OO-kielten (C , Java) alkeellisuus. (Lisää esim. http://www.paulgraham.com/icad.html kohta "What Made Lisp Different").
Vastaukset 6
Vanhimmat
Mä oikeastaan olisin sitä mieltä että tuommoiseen joutuminen johtuu ainoastaan huonosta suunnittelusta... Ton saa aina jotenkin (helposti) kierrettyä.
Nojoo mutta lispi näyttää hanskaavan tommosen paremmin, totta...
"johtuu ainoastaan huonosta suunnittelusta..."
Ei johdu, oikeasti ei ole muita vaihtoehtoja. Pohdi tuota wikin esimerkkiä, niin huomaat/ymmärrät.
Otetaan Java-versio...
class Asteroid extends Thing {
public void collide_with(Thing other) {
}
}
Ton tilalle
class Asteroid extends Thing {
public void collide_with(Asteroid a) {
}
public void collide_with(SpaceShip a) {
}
}
Vaihtoehto? Kaks metodia juu, mutta ei taida olla hirveän paljoa työläämpää kirjoittaa kuin if-tarkistusta tuonne yhden metodin sisään.
No kokeilepas toimiiko. Tarkoitushan on että jossain vaihessa käydään luupissa läpi kaikki Thing-oliot. Eli jos ne on taulukossa niin tulisi jotain:
thing[i].collide_with(thing[j]);
kaikkeen ei oop-lähestymistapa ja esim. juuri tuossa esimerkissä voisi olla parempi käyttää ulkopuolista luokkaa joka handlaa törmäykset tyyliin
public class CollisionManager
{
static int handleCollision(Box v, Sphere v)
static int handleCollision(Box v, Polyhedra v)
static int handleCollision(Sphere v, Polyhedra v)
...
}
sen sijaan että kapseloi luokan sisälle oop-tyyliin
public class Box extends Obj3D
{
int handleCollision(Sphere v);
int handleCollision(Polyhedra v);
}
public class Sphere Obj3D
{
int handleCollision(Box v);
int handleCollision(Polyhedra v);
}
...
Joutuu kuitenkin käyttää "instanceof". (katso vastaus yllä). Vertaa polymorfismiin: http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming