[Java] Polymorfisme en Function overloading

[MBV]

Ik had vandaag ergens last van bij een parse tree verwerken (visitor pattern van JTB) in Java. Minimale* testcase:

Java:

//Hond.java
public class Hond {
    public String toString() {  return "Hond"; }
}

//Tekkel.java
public class Tekkel extends Hond {
    public String toString() {  return "Tekkel"; }
}

//JackRussel.java
public class JackRussel extends Hond {
    public String toString() {  return "JackRussel"; }
}

//Printer.java
import java.util.Vector;
public class Printer {
    public static void main(String[] args) {
        Vector<Hond> v = new Vector<Hond>();
        v.add(new Tekkel());
        v.add(new JackRussel());
        v.add(new Hond());
        
        Printer p = new Printer();
        for (Hond h: v) {   p.print(h); }
    }
    
    public void print(Hond h) {
        System.out.println("Hond is " + h.toString());
    }
    public void print(Tekkel t) {
        System.out.println("Tekkel is " + t.toString());
    }
    public void print(JackRussel j) {
        System.out.println("Jack Russel is " + j.toString());
    }

}

Verwachtte output:

code:

Tekkel is Tekkel
Jack Russel is JackRussel
Hond is Hond

Gekregen output:

code:

Hond is Tekkel
Hond is JackRussel
Hond is Hond

Er is uiteraard een workaround voor:

Java:

    public static void main(String[] args) {
//[knip]
        for (Hond h: v) {
            if (h instanceof Tekkel) {
                p.print( (Tekkel) h);
            }
            else if (h instanceof JackRussel) {
                p.print( (JackRussel) h);
            }
            else p.print(h);
        }
    }

Daar wordt de code nu niet bepaald leesbaarder van.

Hoe komt dit? En wat moet ik doen om een eindeloze if/elseif reeks overbodig te maken? Met 20 cases is dat niet echt leuk meer

_{*) Ja, met 2 klasses had het ook gekund}

[whoami]

Wat doet dit :

code:

public void Print( Hond h )
{
  p.print (h.GetType().Name + " is " + h.getType());
}

Maar daarmee los je waarschijnlijk je echte probleem niet op.

[RobIII]

Dit komt door "for (Hond h: v)", iedere kaar zal de variabele h in de lus dus sowieso gecast worden naar hond. Ik ben niet zo bekend met Java maar je zult inderdaad (ik vermoed dus met instanceof) even het type moeten onderzoeken.

[ Voor 43% gewijzigd door RobIII op 27-01-2009 17:33 ]

[whoami]

Dat je het in een Vector hond steekt, is geen probleem denk ik, aangezien een Hond ook een Tekkel is.
Echter, je haalt alles eruit als een Hond, en dan roep je de method aan die een 'Hond' print. Op dat moment is er helemaal geen polymorphisme van toepassing.

[RobIII]

whoami schreef op dinsdag 27 januari 2009 @ 17:31:
Dat je het in een Vector hond steekt, is geen probleem denk ik, aangezien een Hond ook een Tekkel is.
Echter, je haalt alles eruit als een Hond, en dan roep je de method aan die een 'Hond' print. Op dat moment is er helemaal geen polymorphisme van toepassing.

Dat zeg ik (en ja, ik heb de onzin even weggeëdit )

[farlane]

RobIII schreef op dinsdag 27 januari 2009 @ 17:21:
Nogal wiedes; je stopt alles in een Vector<Hond>, dan is niet meer bekend welk type het is behalve dat het een <Hond> is.

Het is wel degelijk bekend dat er soorten honden in de vector zitten, want de overloaded functie wordt wel goed op de juiste class aangeroepen. ( Het zijn references naar honden )

Volgens mij is het ook de bedoeling dat de class zelf de visit ( print ) aanroept op je visitor ( Printer )

[edit]

(en ja, ik heb de onzin even weggeëdit )

[ Voor 18% gewijzigd door farlane op 27-01-2009 17:39 ]

[kw4h]

RobIII schreef op dinsdag 27 januari 2009 @ 17:21:
Nogal wiedes; je stopt alles in een Vector<Hond>, dan is niet meer bekend welk type het is behalve dat het een <Hond> is. Dit komt sowieso door "for (Hond h: v)", iedere kaar zal de variabele h in de lus dus sowieso gecast worden naar hond. Ik ben niet zo bekend met Java maar je zult inderdaad (ik vermoed dus met instanceof) even het type moeten onderzoeken.

Nee, dit is waar polymorphisme voor bedoeld is.
Je roept een object aan alszijnde een Hond object - maar de echte implementerende klasse (bijv Tekkel) wordt aangeroepen.
Dus:

Java:

Hond h = new Tekkel();
System.out.println(h.toString()); // hier wordt de toString() methode van Tekkel aangeroepen

En dus is je methode 'public void print(Hond h)' gewoon geldig. Omdat een Tekkel object van een Hond afstamt, en dus alszijnde een Hond kan worden aangeroepen.

edit: betekent dus dat de ge-overloade functies 'print' overbodig zijn / worden genegeerd door Java

[ Voor 5% gewijzigd door kw4h op 27-01-2009 17:36 ]

[RobIII]

Jajajaja Ik had 't al weggeëdit. Blijft mijn statement vanaf de tweede zin dus nog wel staan.
Stelletje quoters

[ Voor 10% gewijzigd door RobIII op 27-01-2009 17:36 ]

[MBV]

whoami schreef op dinsdag 27 januari 2009 @ 17:21:
Wat doet dit :

code:

public void Print( Hond h )
{
  p.print (h.GetType().Name + " is " + h.getType());
}

Dat? "The method GetType() is undefined for type Hond", volgens mij ben je in de war met C#, o.a. aan de naamgeving te zien getClass() geeft "class Tekkel" terug.

Maar daarmee los je waarschijnlijk je echte probleem niet op.

MBV schreef op dinsdag 27 januari 2009 @ 17:06:
Ik had vandaag ergens last van bij een parse tree verwerken (visitor pattern van JTB) in Java.

Ik kan dus wel elk node-type wat in de syntax-tree van Java zit laten afhandelen door visit(Node n) met een gigantische if/elseif constructie, maar dat lijkt me nou niet echt netjes of overzichtelijk

whoami schreef op dinsdag 27 januari 2009 @ 17:31:
Dat je het in een Vector hond steekt, is geen probleem denk ik, aangezien een Hond ook een Tekkel is.
Echter, je haalt alles eruit als een Hond, en dan roep je de method aan die een 'Hond' print. Op dat moment is er helemaal geen polymorphisme van toepassing.

Hetzelfde effect krijg je als je getElement(i) gebruikt, dus ik weet niet precies wat je met 'eruit halen als hond' bedoelt. Ik begrijp het alleen nog steeds niet: ik heb een Tekkel, en ik verwachtte dat hij de overload met het 'beste' type pakt.

Ik/mijn collega moet dus op diverse plekken een if/elseif constructie met 20 opties schrijven?

[edit]pfft, dat gaat snel.

farlane schreef op dinsdag 27 januari 2009 @ 17:33:
Volgens mij is het ook de bedoeling dat de class zelf de visit ( print ) aanroept op je visitor ( Printer )

Eens. Maar in dit geval moet ik/mijn collega de waarde van bijvoorbeeld een variabele achterhalen, en daarvoor moet ik een 2e keer door de boom heen. In feite gaat het ook om een aanroep van analyze(...) ipv visit(...). Alternatief is returnen van een waarde met een member-variabele, wat in mijn ogen nog smeriger is Of 500+ 900 + 130 + 1800 regels code converteren van DepthFirstVisitor naar GJVisitor. Have fun

[ Voor 18% gewijzigd door MBV op 27-01-2009 17:50 ]

[whoami]

MBV schreef op dinsdag 27 januari 2009 @ 17:40:
[...]

Dat? "The method GetType() is undefined for type Hond", volgens mij ben je in de war met C#, o.a. aan de naamgeving te zien getClass() geeft "class Tekkel" terug.
[...]

Hey, ik type hier gewoon maar wat C# / pseudo-code hé, aan jou om het te gaan vertalen in jouw taaltje.

[momania]

MBV schreef op dinsdag 27 januari 2009 @ 17:40:
[...]

Ik/mijn collega moet dus op diverse plekken een if/elseif constructie met 20 opties schrijven?

Nee, je snapt het princiepe gewoon nog niet denk ik. Het idee van polymorphism is juist dat je met 1 class/interface (Hond) werkt en dat de behaviour afhangt van de implementatie (Tekkel/JackRussel).

Je itereert gewoon een Vector van Hond classes. Of dat nou een base class, interface of abstracte class is, whatever, het is een Hond. Dat de implementatie een Tekkel is of andere afgeleide van Hond is niet van toepassing in je loop. Als je een method aanroept vanuit je loop, moet het dus altijd een method zijn met Hond als parameter. (Als je de method "public void print(Hond h)" tijdelijk verwijderd, krijg je zelfs een compile error en een goede IDE zal je zeggen dat de andere methods nooit aangeroepen worden )

[MBV]

momania schreef op dinsdag 27 januari 2009 @ 18:03:
[...]

Nee, je snapt het princiepe gewoon nog niet denk ik. Het idee van polymorphism is juist dat je met 1 class/interface (Hond) werkt en dat de behaviour afhangt van de implementatie (Tekkel/JackRussel).

Flauw hoor, op de man spelen
Ik had hierboven al aangegeven wat de echte casus is. Er is een parse-tree met allemaal domme objecten (die alleen weten wat er boven en onder ze hangt), die door de visitor wordt bezocht om bijv. metrics uit te halen. Daarbij kan je de logica dus niet in de parse-tree stoppen, omdat die automatisch gegenereerd wordt, en omdat er meerdere visitors worden ontwikkeld (1 voor dependencies, 1 voor metrics, enzovoort).
En aan het einde van mijn vorige post had ik al toegegeven dat er een vrij grove ontwerpfout is gemaakt. Door omschrijven naar globale 'returns' in een soort van stack kan je daar het makkelijkste omheen programmeren, maar ook daar zal vrij veel tijd in gaan zitten.

En dat je de print(Hond h) niet mag weglaten had ik al op een andere manier verklaard: er zijn namelijk compilers die een waarschuwing of error geven bij deze situatie:

Java:

MyThing x;
switch (y) {
  case 1: x = new MyThing('foo'); break;
  case 2: x = new MyThing('bar'); break;
  System.out.println(x);
}

Ook al weet je dat y niks anders kan zijn. Je kan namelijk niet met de type checker controleren dat alle gevallen zijn afgedekt. Datzelfde probleem geldt ook als je print(Hond h) weglaat, ook al heb je alle gevallen afgedekt.

Maar goed, de compiler kijkt naar wat voor type het ding (volgens statische typeringen) op dat moment heeft. Fijn, weet ik dat ook weer. En helaas kan ik in Java geen trucje er omheen vinden

[RayNbow]

Java doet de dispatch louter op het eerste argument (i.e., this argument). De TS wil mogelijk Double Dispatch toepassen.

[MBV]

Yup, dat was de term waar ik naar op zoek was

[.oisyn]

RayNbow schreef op dinsdag 27 januari 2009 @ 18:51:
Java doet de dispatch louter op het eerste argument (i.e., this argument). De TS wil mogelijk Double Dispatch toepassen.

Neuh, de TS wil single dispatch, maar dan gewoon niet op 'this'

[ Voor 4% gewijzigd door .oisyn op 27-01-2009 19:33 ]

[momania]

MBV schreef op dinsdag 27 januari 2009 @ 18:39:
[...]

Flauw hoor, op de man spelen

Ik speel niet op de man, ik schrijf wat ik denk dat er mis is... ik miste idd de juiste context voor mijn antwoord, maar je voorbeeld was dan ook niet echt gerelateerd aan je context en dus verwarrend hier...

Wat mij nu wel gewoon duidelijk is is iig dat jouw probleem 1 uit duizenden is, nml: ontwerp fout + ontwikkel methode fout

Je bent bang om te veel te moeten refactoren, maar refactoren is key in software goed houden... tijd voor maken/nemen, en excuses als 'is geen tijd voor' is altijd onzin, maar meer een excuus dat je er te laat mee bent begonnen

[MBV]

.oisyn schreef op dinsdag 27 januari 2009 @ 19:29:
[...]

Neuh, de TS wil single dispatch, maar dan gewoon niet op 'this'

Ik gebruik 'this' helemaal niet Ook niet in de echte code, daar gaat het om een Node (of NodeList, of iets wat van Node overerft), en het probleem heeft helemaal niks met 'this' te maken.

momania schreef op dinsdag 27 januari 2009 @ 19:30:
Je bent bang om te veel te moeten refactoren, maar refactoren is key in software goed houden... tijd voor maken/nemen, en excuses als 'is geen tijd voor' is altijd onzin, maar meer een excuus dat je er te laat mee bent begonnen

Psst, ik ben er niet mee begonnen, ik zag de paar duizend regels vorige week voor het eerst En het is al een stuk beter dan de rest van de programma's die hier rondzwerft En wat is er gebeurd met "If it ain't broke, don't fix it"?

[ Voor 8% gewijzigd door MBV op 27-01-2009 19:46 ]

[MrBucket]

Het kan natuurlijk zo:

Java:

//Hond.java
public class Hond {
    public String getName() { return "Hond"; }
    public String toString() {  return "Hond"; }
}

//Tekkel.java
public class Tekkel extends Hond {
    public String getName() { return "Tekkel"; }
    public String toString() {  return "Tekkel"; }
}

//JackRussel.java
public class JackRussel extends Hond {
    public String getName() { return "Jack Russel"; }
    public String toString() {  return "JackRussel"; }
}

//Printer.java
import java.util.Vector;
public class Printer {
    public static void main(String[] args) {
        Vector<Hond> v = new Vector<Hond>();
        v.add(new Tekkel());
        v.add(new JackRussel());
        v.add(new Hond());
        
        Printer p = new Printer();
        for (Hond h: v) {   p.print(h); }
    }
    
    public void print(Hond h) {
        System.out.println(h.getName() + " is " + h.toString());
    }
}

Maar dat zal dan wel niet corresponderen met je 'echte' probleem...
_{En jongens, wees een beetje lief voor elkaar}

[.oisyn]

MBV schreef op dinsdag 27 januari 2009 @ 19:45:
[...]

Ik gebruik 'this' helemaal niet Ook niet in de echte code, daar gaat het om een Node (of NodeList, of iets wat van Node overerft), en het probleem heeft helemaal niks met 'this' te maken.

Duh, daarom zeg ik ook dat het single dispatch is. Als je ook 'this' had gebruikt dan was het idd double dispatch geweest, wat RayNbow noemde. Alleen veruit de meeste OO talen ondersteunen alleen dispatch op 'this'. Jij wil niet dispatchen op 'this', maar op een andere parameter. Dat gaat dus niet automatisch, en daarvoor zul je ofwel met if-statements aan de gang moeten, ofwel de dispatch zo herschrijven dat je wel 'this' gebruikt (zoals het visitor pattern doet). Een derde optie is trouwens het gebruik van reflection, maar of je daar nou zo vrolijk van wordt...

[ Voor 13% gewijzigd door .oisyn op 27-01-2009 20:01 ]

[kasper_vk]

Je zou natuurlijk ook een échte Visitor implementatie kunnen toepassen

Dus zoiets als

Java:

interface HondVisitor {
    public void visit(Hond h);
    public void visit(Tekkel t);
    ...
}
class Printer implements HondVisitor {
    public void visit(Hond h){
        this.out.print("Hond is een " + h.toString());
    }
    public void visit(Tekkel t){
        this.out.print("Tekkel is een " + h.toString());
    }
    ...
}

//En dan de échte Visitor 'truuk' (die de gewenste 'double dispatch' voor je realiseert)
class Hond {
    ...
    public void accept(HondVisitor visitor){
        visitor.visit(this);
    }
}
class Tekkel extends Hond{
    ...
    public void accept(HondVisitor visitor){
        visitor.visit(this);
    }
}

//En dan werkt je loopje precies zoals je in de TS aangeeft dat je zou willen:
public void mainOfzo() {
    ...
    Printer printer = new Printer(System.out);
    for (Hond h : honden) {
        h.accept(printer);
    }
}

De lol is dus dan de visitor.visit(this) in Hond en Tekkel voor de 2e dispatch zorgen: het type van this is immers altijd bekend en Java (de compiler of de JRE, welke weet ik ff niet meer) heeft dus vooraf al bedacht dat de accept(HondVisitor visitor) methode in Tekkel de methode visit(Tekkel t) in de visitor gaat aanroepen (en dus niet visit(Hond)).

Zie ook:[alg] preview visitor artikel

[MBV]

@.iosyn: Je zou dispatchen op de parameter via reflection kunnen doen, met double dispatch kom je een paar voorbeelden tegen (voorbeelden zijn dan collisions in spellen etc). Ik ga er even aan kijken, maar misschien wordt het toch wel refactoring.

kasper_vk schreef op dinsdag 27 januari 2009 @ 22:15:
Je zou natuurlijk ook een échte Visitor implementatie kunnen toepassen

Dus zoiets als
[knip code]

De lol is dus dan de visitor.visit(this) in Hond en Tekkel voor de 2e dispatch zorgen: het type van this is immers altijd bekend en Java (de compiler of de JRE, welke weet ik ff niet meer) heeft dus vooraf al bedacht dat de accept(HondVisitor visitor) methode in Tekkel de methode visit(Tekkel t) in de visitor gaat aanroepen (en dus niet visit(Hond)).

Zie ook:[alg] preview visitor artikel

Yup, zo werkt de JTB-visitor. En dat geeft dus aan dat we de code moeten herschrijven, de 'mooie' truc om dat in sommige gevallen te omzeilen werkt blijkbaar niet Ach ja, al doende leert men

[redfox314]

MBV schreef op dinsdag 27 januari 2009 @ 17:06:
Ik had vandaag ergens last van bij een parse tree verwerken (visitor pattern van JTB) in Java. Minimale* testcase:

Java:

//Printer.java
import java.util.Vector;
public class Printer {
    
//.....

    public void print(Hond h) {
        System.out.println("Hond is " + h.toString());
    }
    public void print(Tekkel t) {
        System.out.println("Tekkel is " + t.toString());
    }
    public void print(JackRussel j) {
        System.out.println("Jack Russel is " + j.toString());
    }

}

Dit schrijven is eigenlijk hetzelfde als een grote elsif structuur. Elke keer als er een soort hond bijkomt moet je een nieuw functietje schrijven. De klasse weet zelf beter wel soort hond hij is. In principe kan je in je functiebody voor hond h.getClass().getSimpleName() gebruiken. Of dit nu zo wenselijk is weet ik niet zo. Ik denk dat je je visitor-pattern nog eens moet herbekijken: je wijkt namelijk op een subtiele manier af van het visitor pattern. De verschillende soorten klassen die je wilt bezoeken hebben daar namelijk niets met elkaar te maken.


*EDIT* blijkt al herhaling laat het toch staan...


psst: GAMMA E. et al., Design Patterns. Elements of Reusable Object-Oriented Software, 1995, Addison Wesley. hoort in de boekenkast van elke software developer.

[MBV]

redfox314 schreef op dinsdag 27 januari 2009 @ 22:26:
[...]


Dit schrijven is eigenlijk hetzelfde als een grote elsif structuur. Elke keer als er een soort hond bijkomt moet je een nieuw functietje schrijven. De klasse weet zelf beter wel soort hond hij is. In principe kan je in je functiebody voor hond h.getClass().getSimpleName() gebruiken. Of dit nu zo wenselijk is weet ik niet zo. Ik denk dat je je visitor-pattern nog eens moet herbekijken: je wijkt namelijk op een subtiele manier af van het visitor pattern. De verschillende soorten klassen die je wilt bezoeken hebben daar namelijk niets met elkaar te maken.


*EDIT* blijkt al herhaling laat het toch staan...


psst: GAMMA E. et al., Design Patterns. Elements of Reusable Object-Oriented Software, 1995, Addison Wesley. hoort in de boekenkast van elke software developer.

Inderdaad, dit lijkt op een grote elseif structuur. Maar als jij iets beters weet om de parse-tree van pak-em-beet een Cobol, Java en PL/SQL programma te verwerken, dan houd ik me aanbevolen.

Boek staat in de kast (al 3 jaar ), ik zal hem binnenkort weer eens doorbladeren. Inmiddels wat meer geleerd, dus ik zal de concepten wat beter kunnen plaatsen. Op het HBO vond ik dat nog lastig, de Visitor is me iig niet bijgebleven ('t is ook de laatste uit het boek )

[farlane]

Dit schrijven is eigenlijk hetzelfde als een grote elsif structuur.

Het idee achter het visitor pattern is het uitbreiden van een class met operations zonder dat de class zelf aangepast hoeft te worden, dus je zult ergens die specifieke operations moeten implementeren.

Het mooie van deze constructie is dat als geen implementatie schrijf (vergeet) voor een bepaalde class in mijn interface/concrete visitor ik een compiler error krijg, terwijl je met een if/elseif aan het zoeken komt.

[MBV]

Wat nog mooier is: JTB genereert de default-structuur om depth-first door de boom heen te gaan, je hoeft dus alleen de functies te overriden voor constructies waar je echt wat mee gaat doen.
_{Nee, het is niet de bedoeling dat je de gegenereerde klasse copy/paste en daarna aanpast}