Err... niet specefiek genoeg.
Parametric polymorphism en Inclusion polymorphism ( degene die je bedoeld ) zijn beide een vorm van Universal polymorphism. Dat is polymorfisme welke op een oneindig aantal types werkt, welke iets gemeen met elkaar hebben. Het gedrag is wel gelijk.
Je hebt echter ook Ad-hoc polymorphisme, welke op
n
types werkt, waarbij
n
gelimiteerd is. Denk hierbij aan Coercion (conversie van types) en Overloading.
Deze methodes hebben vaak totaal verschillend gedrag en de types hebben geen relatie met elkaar.
Inclusion polymorphisme is de polymorphisme eis voor OO. Voor de duidelijkheid: Java ondersteund (1.4) MINDER polymorphisme als C++
Tot zover de types polymorphism gespecialiseerd door Cardelli en Wegner (85).
Er is echter nog veel meer flexibel te maken aan een class. Als je @ runtime methodes kunt gaan opzoeken, waarom dat niet members? Of base classes?
Het volgende komt uit Chen, Sun en Tang en heb ik pas gebruikt in een presentatie:
Java:
1
2
3
4
5
6
7
8
| interface Window { ... }
class SunWindow implements Window{ ... }
class MacWindow implements Window{ ... }
class WinWindow implements Window{ ... }
interface EditorWindow extends Window { ... }
class SunEditWindow implements EditorWindow{ ... }
//enz |
Nogal rottig om die implementatie 2x te gaan doen, plus dat het nu geen SunWindow meer is
Dat is te vervangen door
Java:
1
| class SunEditWindow extends SunWindow implements EditorWindow |
Wat ik nou niet echt heerlijk vind. Je hebt nu twee keer vastgelegd dat het een Window is, wat nou ook niet echt nodig is.
Waarom dat niet vervangen met een nieuw type polymorfisme:
Java:
1
2
3
4
5
6
7
8
| interface Window { ... }
class SunWindow implements Window{ ... }
class MacWindow implements Window{ ... }
class WinWindow implements Window{ ... }
interface EditorWindow virtual extends Window { ... }
class SunEditWindow implements EditorWindow<Window is SunWindow>{ ... }
//enz |
Dan zou SunEditWindow direct erven van Sunwindow.
Verder is ook nog polymorphisme mogelijk op members:
Java:
1
2
3
4
5
6
7
8
9
10
11
12
| class Motor{ ... }
class TurboMotor extends Motor{ ... }
class SuperMotor extends Motor{ ... }
class Auto {
protected Motor _m;
}
class TurboAuto extends Auto {
// _m is niet van type te veranderen.
// dus we moeten constant casten
} |
Zou het niet mooier zo kunnen:
Java:
1
2
3
4
5
6
7
8
9
10
11
12
| class Motor{ ... }
class TurboMotor extends Motor{ ... }
class SuperMotor extends Motor{ ... }
class Auto {
virtual protected Motor _m;
}
class TurboAuto extends Auto : Motor is TurboMotor{
// _m is van type te TurboMotor.
// dus we moeten niet casten
} |
Dit is allemaal te bereiken met simpele templates die kunnen werken met constraints. Leuke daarvan is dat Java dus deze vorm van polymorphisme wel ondersteund vanaf 1.5