Antwoord

In Java bepaalt het mechanisme van dynamische binding welk methode wordt aangeroepen tijdens de runtime, en niet tijdens de compileertijd. Het belangrijkste verschil met statische binding is dat private, static, final methoden statisch worden gebonden en in runtime niet worden overschreven (binding vindt plaats tijdens de compilatie), terwijl gewone instantie-methoden (inclusief overschreven methoden) dynamisch worden gebonden. Dit maakt polymorfisme mogelijk.

Voorbeeld:

class Animal {
    void makeSound() { System.out.println("Een geluid"); }
}
class Dog extends Animal {
    void makeSound() { System.out.println("Blaffen"); }
}
public class Test {
    public static void main(String[] args) {
        Animal a = new Dog();
        a.makeSound(); // Zal afdrukken: Blaffen (dynamische binding)
    }
}

Hier wordt de methode makeSound() dynamisch gebonden – de JVM bepaalt welk variant te roepen, alleen tijdens de uitvoering.

Kijk uit voor de valstrik

Vraag: "Als je een variabele van een interface of abstracte klasse declareert en er een instantie van een subklasse aan toekent, welke methode zal worden aangeroepen bij toegang tot de overschreven methode? Hoe bepaalt de compiler dit?"

Vaak gemaakt fouten: velen denken dat de methode wordt aangeroepen op basis van het type verwijzing tijdens de compileertijd, maar dit gebeurt door de JVM tijdens de runtime.

Correct antwoord: De JVM gebruikt het type van het werkelijke object om de methode aan te roepen (dynamische binding), en niet het type verwijzing.

Shape s = new Circle();
s.draw(); // será a chamada de draw() de Circle, en niet uit Shape

Voorbeelden van echte fouten door gebrek aan kennis van de nuances van het onderwerp

---

Verhaal

In een groot bankproject overschreef een ontwikkelaar de methoden toString() en equals(), in de veronderstelling dat als hij een variabele via een interface declareerde, de methode via de interface zou worden aangeroepen. Hierdoor vond de vergelijking van objecten onjuist plaats - er werden verwijzingen vergeleken, niet waarden, wat leidde tot onjuiste logica bij het vergelijken van klanten bij het zoeken naar duplicaten.

---

Verhaal

In een e-commerce project creëerde een ontwikkelaar een basisklasse Product en een afgeleide Klasse ElectronicProduct. In de array Product[] waren objecten van beide typen opgeslagen. Bij het weergeven van het product via een methode die was overschreven in ElectronicProduct, werd alleen informatie van de basisklasse weergegeven, omdat de statische methode was aangeroepen! De fout werd opgemerkt voor de publicatie.

---

Verhaal

In een project voor transportmodellering werd het Factory-patroon gebruikt. De ontwikkelaar merkte niet dat hij met velden werkte en niet met methoden: het aanspreken van een veld van de afgeleide klasse leidde tot het teruggeven van de waarde van de basisklasse, en niet van de overschreven, omdat velden niet polymorf zijn! Het systeem berekende de routes onjuist, waarbij aan alle objecten het type "Transport" werd toegewezen.