Dynamic ve Static Binding | Ücretsiz Java Programlama: Sıfırdan İleri Seviyeye Kursu

Binding Nedir?

Binding, bir metot çağrısının hangi metot gövdesine bağlanacağının belirlenmesidir. obj.method() yazdığında, JVM hangi sınıftaki method()'u çalıştıracak? İşte bu bağlama işlemine binding denir.

Bunu bir telefon rehberi gibi düşün. "Ali'yi ara" dediğinde, telefonun Ali'nin numarasını rehberde bulması gerekiyor. Bazen numara önceden belli (static), bazen araya göre değişiyor (dynamic). Binding de tam bu: metot isminden gerçek koda ulaşma süreci.

İki türü var:

Static Binding (Early Binding) — derleme zamanında belirlenir
Dynamic Binding (Late Binding) — çalışma zamanında belirlenir

Static Binding (Compile-Time Binding)

Static binding'de hangi metodun çağrılacağı derleme zamanında kesinleşir. Compiler referans tipine bakarak kararı verir.

Şu durumlarda static binding olur:

private metotlar
static metotlar
final metotlar
Overloaded metotlar (hangi overload çağrılacak)

class Calculator {
    // Overloaded metotlar — static binding
    int add(int a, int b) {
        return a + b;
    }

    double add(double a, double b) {
        return a + b;
    }
}

Calculator calc = new Calculator();
calc.add(3, 5);      // int versiyonu — derleme zamanında belli
calc.add(3.0, 5.0);  // double versiyonu — derleme zamanında belli

Compiler parametre tiplerine bakarak hangi add() metodunun çağrılacağını belirler. Runtime'a bırakmaz.

Static metotlar:

class Parent {
    static void greet() {
        System.out.println("Parent greet");
    }
}

class Child extends Parent {
    static void greet() {
        System.out.println("Child greet");
    }
}

Parent p = new Child();
p.greet(); // "Parent greet" — referans tipi Parent, static binding

Static metotta nesnenin gerçek tipi önemli değil. Compiler referans tipine (Parent) bakıp karar verir.

Dynamic Binding (Runtime Binding)

Dynamic binding'de hangi metodun çağrılacağı çalışma zamanında belirlenir. JVM nesnenin gerçek tipine bakarak karar verir.

Override edilmiş instance metotları dynamic binding kullanır.

class Animal {
    void speak() {
        System.out.println("...");
    }
}

class Dog extends Animal {
    @Override
    void speak() {
        System.out.println("Hav!");
    }
}

class Cat extends Animal {
    @Override
    void speak() {
        System.out.println("Miyav!");
    }
}

Animal a1 = new Dog();
Animal a2 = new Cat();

a1.speak(); // "Hav!"   — runtime'da Dog olduğu anlaşılır
a2.speak(); // "Miyav!" — runtime'da Cat olduğu anlaşılır

Compiler sadece "Animal'da speak() var mı?" kontrol eder. Hangi versiyonun çalışacağı runtime'da belirlenir.

Compile-Time vs Runtime — Karşılaştırma

class Shape {
    void draw() {
        System.out.println("Drawing shape");
    }

    static void info() {
        System.out.println("Shape info");
    }
}

class Circle extends Shape {
    @Override
    void draw() {
        System.out.println("Drawing circle");
    }

    static void info() {
        System.out.println("Circle info");
    }
}

Shape s = new Circle();

s.draw(); // "Drawing circle" — Dynamic binding (override)
s.info(); // "Shape info"     — Static binding (static metot)

Özellik	Static Binding	Dynamic Binding
Ne zaman?	Derleme zamanı	Çalışma zamanı
Neye bakılır?	Referans tipi	Nesne tipi
Hangi metotlar?	private, static, final, overloaded	Override edilmiş instance metotlar
Performans	Daha hızlı	Biraz yavaş (ama JVM optimize eder)
Polimorfizm	Yok	Var

Method Dispatch Mekanizması

JVM'in dynamic binding'i nasıl gerçekleştirdiğini anlayalım. Bu mekanizmaya method dispatch denir.

Static dispatch (compile-time):

Compiler referans tipine bakar
O tipteki metot tablosunda arar
Bulursa bytecode'a yazar

Dynamic dispatch (runtime):

JVM nesnenin gerçek sınıfını tespit eder
O sınıfın metot tablosuna bakar
Metodu bulur ve çalıştırır
Bulamazsa superclass'a bakar (zincir yukarı gider)

Animal a = new Dog();
a.speak();

// JVM'in iç süreci:
// 1. a referansının gösterdiği nesne → Dog instance
// 2. Dog sınıfında speak() ara → BULDUM
// 3. Dog.speak() çalıştır

Eğer Dog speak() override etmeseydi:

// JVM'in iç süreci:
// 1. a referansının gösterdiği nesne → Dog instance
// 2. Dog sınıfında speak() ara → YOK
// 3. Superclass Animal'da ara → BULDUM
// 4. Animal.speak() çalıştır

Virtual Method Table (vtable) Konsepti

JVM dynamic dispatch'i verimli yapmak için Virtual Method Table (vtable) kullanır. Her sınıfın bir vtable'ı vardır ve bu tablo metotların gerçek adreslerini içerir.

Animal vtable:
┌──────────────┬─────────────────┐
│ speak()      │ → Animal.speak  │
│ eat()        │ → Animal.eat    │
│ toString()   │ → Object.toString│
└──────────────┴─────────────────┘

Dog vtable:
┌──────────────┬─────────────────┐
│ speak()      │ → Dog.speak     │  ← Override edildi
│ eat()        │ → Animal.eat    │  ← Miras alındı
│ toString()   │ → Object.toString│
│ fetch()      │ → Dog.fetch     │  ← Yeni metot
└──────────────┴─────────────────┘

Dog nesnesi oluşturulduğunda, JVM Dog'un vtable'ına bakar. speak() çağrılınca tabloda Dog.speak adresi bulunur ve o çalıştırılır.

Bu mekanizma sayesinde dynamic dispatch O(1) karmaşıklıkta çalışır — her metot çağrısında tüm kalıtım zincirini aramaz, doğrudan tablodaki adrese gider.

💡 İpucu: vtable konsepti Java spesifikasyonunda doğrudan tanımlı değil — bu bir implementasyon detayı. Ama HotSpot JVM ve diğer büyük JVM'ler bu yaklaşımı kullanır.

Alanlar (Fields) Her Zaman Static Binding

Önemli: alanlar (instance variables) her zaman compile-time binding kullanır. Polimorfizm alanlarda çalışmaz.

class Parent {
    String type = "Parent";

    String getType() {
        return type;
    }
}

class Child extends Parent {
    String type = "Child"; // Shadowing — override değil!

    @Override
    String getType() {
        return type;
    }
}

Parent p = new Child();
System.out.println(p.type);      // "Parent" — static binding (alan)
System.out.println(p.getType()); // "Child"  — dynamic binding (metot)

Aynı nesne, alan erişiminde "Parent" diyor, metot çağrısında "Child" diyor. Çünkü alanlar referans tipine, metotlar nesne tipine göre çözülür.

⚠️ Dikkat: Alanlarda shadowing çok kafa karıştırıcıdır. Best practice: alanları private yap, getter/setter ile eriş. Böylece polimorfizm düzgün çalışır.

Private Metotlar ve Binding

Private metotlar override edilemez ve her zaman static binding kullanır.

class Parent {
    private void secret() {
        System.out.println("Parent secret");
    }

    void callSecret() {
        secret(); // Her zaman Parent.secret() çağrılır
    }
}

class Child extends Parent {
    // Bu override DEĞİL — yeni bir metot
    private void secret() {
        System.out.println("Child secret");
    }
}

Parent p = new Child();
p.callSecret(); // "Parent secret" — private metot static binding

callSecret() içindeki secret() çağrısı her zaman Parent.secret()'e gider çünkü private metotlar compile-time'da bağlanır.

Final Metotlar ve Binding

Final metotlar override edilemez, bu yüzden JVM onları static binding ile çözer. Bu bir performans optimizasyonudur.

class Base {
    final void process() {
        System.out.println("Processing...");
    }
}

class Derived extends Base {
    // @Override void process() { } // HATA! final metot
}

JVM final metotları inline edebilir — metot çağrısı yerine metot gövdesini doğrudan yerleştirir. Bu özellikle sık çağrılan küçük metotlarda performans kazancı sağlar.

Overloading ve Overriding Birlikte

Bir sınıfta hem overloading hem overriding olabilir. Hangisinin ne zaman devreye girdiğini ayırt etmek önemli.

class Printer {
    void print(String text) {
        System.out.println("Text: " + text);
    }

    void print(int number) {
        System.out.println("Number: " + number);
    }
}

class ColorPrinter extends Printer {
    @Override
    void print(String text) { // Override — dynamic binding
        System.out.println("Color text: " + text);
    }

    void print(double decimal) { // Overload — static binding
        System.out.println("Decimal: " + decimal);
    }
}

Printer p = new ColorPrinter();
p.print("hello");  // "Color text: hello" — dynamic binding (override)
p.print(42);        // "Number: 42"        — static binding (overload, Printer'da)
// p.print(3.14);   // HATA! Printer referansında print(double) yok

İki aşamalı süreç:

Compile-time: Hangi overload? → Referans tipine (Printer) bakılır
Runtime: Hangi override? → Nesne tipine (ColorPrinter) bakılır

Binding Kararı Akış Şeması

Bir metot çağrısında JVM şu mantığı izler:

obj.method() çağrıldı
    │
    ├─ method static mi?
    │   └─ EVET → Static binding (referans tipine bak)
    │
    ├─ method private mı?
    │   └─ EVET → Static binding
    │
    ├─ method final mı?
    │   └─ EVET → Static binding (JVM optimize eder)
    │
    └─ Hiçbiri değil → Dynamic binding (nesne tipine bak)

Performans Açısından

Static binding, dynamic binding'den daha hızlıdır çünkü çözümleme derleme zamanında yapılır. Ama modern JVM'ler dynamic binding'i çok iyi optimize eder:

Inline caching: Aynı tip tekrar gelirse önceki çözümlemeyi hatırla
Devirtualization: JVM sadece tek bir implementasyon olduğunu tespit ederse, dynamic çağrıyı static'e çevirir
JIT compilation: Sık çağrılan metotları native koda derle

Pratikte bu performans farkı ihmal edilebilir. Doğru tasarım yapmak, mikro-optimizasyondan çok daha önemli.

Gerçekçi Örnek: Ödeme Sistemi

class PaymentProcessor {
    // static metot — static binding
    static String generateId() {
        return "PAY-" + System.currentTimeMillis();
    }

    // instance metot — dynamic binding adayı
    void process(double amount) {
        String id = generateId();
        System.out.println(id + " Processing: " + amount);
    }

    // final metot — static binding
    final void validate(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("Invalid amount");
        }
    }

    // private metot — static binding
    private void logInternal(String msg) {
        System.out.println("LOG: " + msg);
    }
}

class CreditCardProcessor extends PaymentProcessor {
    @Override
    void process(double amount) {
        validate(amount);  // final — static binding
        System.out.println("Credit card charge: " + amount);
    }
}

PaymentProcessor pp = new CreditCardProcessor();
pp.process(100.0); // Dynamic binding → CreditCardProcessor.process()

PaymentProcessor.generateId(); // Static binding → PaymentProcessor.generateId()

Bu örnekte:

process() → dynamic binding (override edilmiş instance metot)
generateId() → static binding (static metot)
validate() → static binding (final metot)
logInternal() → static binding (private metot)

⚠️ Dikkat: Constructor içinde override edilebilir metot çağırma! Superclass constructor'ı çalışırken subclass henüz tam initialize olmamış olabilir.

class Parent {
    Parent() {
        display(); // TEHLİKELİ! override edilebilir
    }

    void display() {
        System.out.println("Parent");
    }
}

class Child extends Parent {
    String value = "Hello";

    Child() {
        super(); // Parent() çalışır, display() çağırılır
    }

    @Override
    void display() {
        System.out.println(value); // null! henüz initialize olmadı
    }
}

new Child(); // null yazdırır, "Hello" değil!

Bu tehlikeli bir durum çünkü Child.display() çağrılır (dynamic binding) ama value henüz initialize edilmemiştir.

Özet

Static binding derleme zamanında gerçekleşir; private, static, final metotlar ve overloaded metot seçimi buna tabidir.
Dynamic binding çalışma zamanında gerçekleşir; override edilmiş instance metotlar nesnenin gerçek tipine göre çözülür.
JVM, dynamic dispatch için vtable (virtual method table) mekanizması kullanır; her sınıfın metot adresleri bir tabloda tutulur.
Alanlar (fields) her zaman static binding kullanır — polimorfizm alanlarda çalışmaz, sadece metotlarda çalışır.
Modern JVM'ler inline caching ve devirtualization ile dynamic binding'i optimize eder; performans farkı pratikte ihmal edilebilir.
Constructor içinde override edilebilir metot çağırmak tehlikelidir — subclass alanları henüz initialize olmamış olabilir.