Override và dynamic dispatch — đa hình ở runtime

Bài trước bạn viết class Dog extends Animal và thấy Dog kế thừa eat() từ Animal. Nhưng nếu Dog muốn ăn khác (vd thêm log, kèm uống nước), bạn không muốn xoá eat() — bạn muốn override: giữ chữ ký giống cha, thay body.

Và đây là lúc Java làm điều tuyệt vời: kể cả bạn có reference kiểu Animal đang trỏ tới một Dog object, animal.eat() vẫn gọi phiên bản của Dog. Đó là dynamic dispatch — nền tảng của đa hình (polymorphism). Nhờ nó bạn viết code thao tác "mọi Animal" mà không cần biết loài cụ thể.

Bài này giải thích override đúng cách, phân biệt với overload, cơ chế dispatch ở bytecode, covariant return, và các rule Java quy định để override hợp lệ.

1. Analogy — ca sĩ hát lại bài hit

Bài hát "Yesterday" của Beatles được nhiều ca sĩ cover. Tên bài giống (eat() cùng signature), nhưng mỗi bản thu có phong cách riêng (body khác). Khi bạn bật playlist "Yesterday", app phát bản đúng ca sĩ được gắn vào track đó — không quan tâm bạn đang nhìn tên bài như nhau.

2. Override cơ bản

class Animal {
    public String sound() {
        return "some sound";
    }
}

class Dog extends Animal {
    @Override
    public String sound() {
        return "woof";
    }
}

class Cat extends Animal {
    @Override
    public String sound() {
        return "meow";
    }
}

Dùng:

Animal a1 = new Dog();
Animal a2 = new Cat();
System.out.println(a1.sound());   // woof
System.out.println(a2.sound());   // meow

a1 và a2 có kiểu khai báo Animal nhưng kiểu thực là Dog/Cat. Method sound() chọn theo kiểu thực → in đúng woof / meow.

2.1 @Override annotation — dùng luôn

class Dog extends Animal {
    @Override
    public String sound() { return "woof"; }
}

Không bắt buộc, nhưng nên có:

• Compiler kiểm tra bạn thật sự override method có sẵn. Viết sai tên (Sound thay sound), sai signature (int sound() thay String sound()) → compile error.
• Không có annotation, Java sẽ coi nó là method mới của class con → không override → bug im lặng.

class Dog extends Animal {
    // gõ sai — không có @Override
    public String soound() { return "woof"; }   // method moi, khong override
}

Animal a = new Dog();
a.sound();   // goi Animal.sound() -> "some sound" — BUG

3. Override vs overload — phân biệt rõ hai loại đa hình

Một trong những nguồn nhầm lẫn lớn nhất của lập trình viên là không phân biệt được rõ ranh giới giữa Method Overriding (Ghi đè phương thức) và Method Overloading (Nạp chồng phương thức). Trong Java, đây là hai hiện diện của hai kiểu đa hình hoàn toàn khác nhau:

• Method Overriding đại diện cho Runtime Polymorphism (Đa hình lúc chạy) hay Dynamic Binding (Liên kết động).
• Method Overloading đại diện cho Compile-time Polymorphism (Đa hình lúc biên dịch) hay Static Binding (Liên kết tĩnh).

Bảng so sánh toàn diện

Ví dụ minh họa

class Calc {
    // 1. Phương thức gốc
    public int add(int a, int b) { return a + b; }
    
    // 2. Overload: Khác tham số truyền vào (double, double)
    public double add(double a, double b) { return a + b; }
}

class SafeCalc extends Calc {
    // 3. Override: Giữ nguyên chữ ký, thay đổi logic ở lớp con
    @Override
    public int add(int a, int b) {
        return Math.addExact(a, b);   // Kiểm tra tràn số (overflow)
    }
}

Trong ví dụ trên:

• SafeCalc.add(int, int) là Override phương thức Calc.add(int, int). Khi chạy, JVM sẽ quyết định gọi hàm này nếu đối tượng thực tế là SafeCalc.
• Calc.add(double, double) là Overload của Calc.add(int, int). Ngay khi biên dịch, Compiler đã xác định được dòng code của bạn đang gọi hàm nào dựa vào kiểu dữ liệu truyền vào.

4. Dynamic dispatch — cơ chế JVM

Bảng so sánh trên rút gọn được thành một câu: một lời gọi đi qua hai lần quyết định, ở hai thời điểm khác nhau.

Cột trái là nơi overload được giải: javac chỉ nhìn kiểu khai báo của biến để chọn chữ ký, nên đổi kiểu khai báo là đổi luôn hàm được gọi — không cần chạy chương trình cũng biết. Cột phải là nơi override thắng: kể cả khi a khai báo kiểu Animal, nếu object thực là Dog thì JVM tra vtable của Dog, slot sound() trỏ tới Dog.sound(), nên phiên bản của Dog được gọi.

5. Rule override — tightening không được, loosening được

Khi override, Java áp rule về:

5.1 Visibility — không thu hẹp

class Animal {
    public void eat() { }
}

class Dog extends Animal {
    protected void eat() { }   // COMPILE ERROR — thu hep tu public xuong protected
}

Class con không được thu hẹp visibility. public cha → public con. Có thể nới rộng (protected → public).

Lý do: Liskov — caller có Animal a; a.eat() phải gọi được. Nếu con thu hẹp thành protected, caller bị refuse → phá substitutability.

5.2 Checked exception — không mở rộng

class A {
    public void run() throws IOException { }
}

class B extends A {
    public void run() throws IOException, SQLException { }   // COMPILE ERROR
    public void run() { }                                     // OK — narrow xuong
    public void run() throws FileNotFoundException { }        // OK — subtype cua IOException
}

Con chỉ được ném subset exception của cha. Ngăn caller bị exception mới không lường trước.

5.3 Return type — covariant (Java 5+)

class Animal {
    public Animal clone() { return new Animal(); }
}

class Dog extends Animal {
    @Override
    public Dog clone() { return new Dog(); }   // OK — Dog la subtype cua Animal
}

Return type con có thể là subtype của return type cha. Gọi là covariant return.

Caller viết Animal a = dog.clone() vẫn work; nhưng caller biết rõ Dog dog có thể lấy trực tiếp Dog d = dog.clone() không cần cast.

5.4 final, static, private — không override được

class A {
    public final void f() { }
    public static void g() { }
    private void h() { }
}

class B extends A {
    public void f() { }        // COMPILE ERROR — cannot override final
    public static void g() { }  // KHONG override — chi shadow (bai sau)
    private void h() { }        // KHONG override — private khong ke thua
}

• final cấm override — dùng để khoá behaviour quan trọng.
• static method không có dynamic dispatch — chúng thuộc class, không phải object. Viết cùng tên ở con chỉ là shadow.
• private không kế thừa nên không có gì để override.

6. Gọi phiên bản cha trong override — super.method()

class Animal {
    public String describe() { return "Animal"; }
}

class Dog extends Animal {
    @Override
    public String describe() {
        return super.describe() + " (Dog)";   // goi Animal.describe
    }
}

System.out.println(new Dog().describe());   // "Animal (Dog)"

super.describe() bypass dispatch, gọi chính xác phiên bản của cha. Pattern này gặp khi con muốn bổ sung logic thay vì thay hoàn toàn.

7. Bẫy Constructor Override Trap — hiểm họa khi khởi tạo

Một trong những cạm bẫy tinh vi nhất liên quan đến đa hình là sự kết hợp giữa Constructor và Dynamic Dispatch. Khi bạn gọi một phương thức có thể override bên trong constructor của lớp cha, chương trình sẽ hoạt động theo cách cực kỳ khó lường.

class Animal {
  public Animal() {
      sound();   // Gọi method instance trong constructor của cha!
  }
  
  public void sound() { 
      System.out.println("animal sound"); 
  }
}

class Dog extends Animal {
  private String name = "Rex";

  @Override
  public void sound() {
      System.out.println("Dog says woof, name = " + name);
  }
}

8. Pitfall tổng hợp

❌ Nhầm 1: Quên @Override → sai signature → method mới thay vì override.

class Dog extends Animal {
    public void Sound() { ... }   // 'S' viet hoa — method moi
}

✅ Luôn @Override — compiler bắt tự động.

❌ Nhầm 2: Thu hẹp visibility khi override.

class Dog extends Animal {
    protected String sound() { return "woof"; }   // cha la public
}

✅ Giữ public hoặc nới rộng, không thu hẹp.

❌ Nhầm 3: Override static.

class A { public static void f() { ... } }
class B extends A { public static void f() { ... } }   // khong override — shadow

✅ static method không tham gia dispatch. Nếu muốn polymorphism, dùng instance method.

❌ Nhầm 4: Gọi method override trong constructor.

abstract class Animal {
    public Animal() { init(); }   // init() la abstract hoac override-able
    protected abstract void init();
}

✅ Không. Khởi tạo hẳn trong constructor của mỗi class cụ thể, hoặc dùng factory method.

❌ Nhầm 5: Cast rồi gọi để "override" — thực ra là dispatch bình thường.

Animal a = new Dog();
((Dog) a).sound();   // cast khong can thiet — a.sound() da dispatch dung

✅ Chỉ cast khi cần gọi method chỉ có ở con (không có ở cha).

9. 📚 Deep Dive Oracle

10. Tóm tắt

• Override = class con viết lại method của cha với cùng signature, body khác.
• @Override annotation — luôn dùng; compiler bắt lỗi nếu bạn gõ sai signature.
• Overload khác override: overload là cùng class, khác signature; override là khác class, cùng signature.
• Dynamic dispatch — JVM chọn method theo kiểu thực của object, không phải kiểu khai báo của biến. Cơ chế qua vtable + invokevirtual.
• Rule override:
  • Không thu hẹp visibility (public → public, protected → public OK).
  • Không ném checked exception rộng hơn cha.
  • Return type có thể là subtype (covariant) — Java 5+.
• final method cấm override; static không tham gia dispatch; private không kế thừa.
• super.method() gọi phiên bản cha — pattern "làm thêm, vẫn gọi cha".
• Không gọi method non-final trong constructor — dispatch chọn method con khi con chưa init xong.

11. Tự kiểm tra

Bài tiếp theo: Abstract class — class không tạo được nhưng định hình subtype