Early Binding vs Late Binding
Early vs late binding explained — compile-time vs runtime method resolution, virtual keyword in C++, with Java examples and Q&A.
Expected Interview Answer
Early binding (also called static binding) connects a method call to its implementation at compile time, while late binding (also called dynamic binding) connects a call to its implementation at runtime — early binding is faster since the target is already known, while late binding trades some performance for the flexibility of runtime polymorphism.
Early binding applies to non-virtual calls: static methods, non-overridden methods, and, in languages without virtual-by-default semantics like C++, any method not marked virtual — the compiler bakes the address of the target function directly into the generated code. Late binding applies to virtual/overridable methods called through a base-type reference or interface: the actual target is looked up through a vtable at the moment the call executes, because the concrete type isn’t knowable until runtime. Java’s instance methods are virtual by default, so most method calls there use late binding automatically, whereas C++ requires the explicit virtual keyword to opt in. The tradeoff is fundamental to OOP design: late binding is what enables extensible, polymorphic APIs, at the cost of an indirect lookup on every call.
- Early binding: no runtime lookup cost, fully predictable
- Late binding: enables plugging in new subtypes without changing caller code
- Understanding the tradeoff explains why C++ requires “virtual” explicitly
- Clarifies performance-sensitive code paths where early binding is preferred
AI Mentor Explanation
A pre-match press release names the exact opening bowler, printed and fixed the night before — that decision is locked in early, before the toss even happens. But the captain’s in-match call of “next bowler up” is decided late, only when the over actually ends, based on live conditions and who is actually available at that moment. The press release is early binding, fixed well before execution; the live bowling change is late binding, decided at the point of need.
Step-by-Step Explanation
Step 1
Identify whether the call is virtual
Non-virtual calls (static, non-overridden, or explicitly non-virtual methods) use early binding.
Step 2
Early binding resolves at compile time
The compiler embeds the exact function address directly into the generated code.
Step 3
Virtual/overridable calls defer resolution
Calls through a base-type reference to an overridable method are late bound.
Step 4
Late binding resolves at the call itself
The runtime looks up the actual object’s vtable entry at the moment the call executes.
What Interviewer Expects
- Correct mapping of early binding to non-virtual calls and late binding to virtual calls
- Mention of C++’s explicit “virtual” keyword versus Java’s virtual-by-default methods
- Understanding the performance vs flexibility tradeoff
- A concrete example distinguishing the two
Common Mistakes
- Treating “early binding” and “late binding” as unrelated to static/dynamic binding (they are the same distinction, different names)
- Assuming Java methods need an explicit keyword to be late bound (they are virtual by default)
- Forgetting that constructors and static methods are always early bound
- Not mentioning the vtable as the mechanism enabling late binding
Best Answer (HR Friendly)
“Early binding means the exact function to call is already known when the code is compiled, so it runs fast with no extra lookup. Late binding means that decision is postponed until the program is actually running, because it depends on the real object’s type — that’s what makes overriding and polymorphism work, at a small performance cost for the lookup.”
Code Example
class MathUtil {
static int square(int x) { return x * x; } // early bound: resolved at compile time
}
class Shape {
double area() { return 0; } // virtual by default in Java
}
class Circle extends Shape {
double r;
Circle(double r) { this.r = r; }
@Override
double area() { return Math.PI * r * r; } // late bound: resolved at runtime
}
int s = MathUtil.square(5); // early binding, no lookup needed
Shape shp = new Circle(2.0);
double a = shp.area(); // late binding, vtable lookup picks Circle.area()Follow-up Questions
- Why does C++ require the “virtual” keyword to opt into late binding?
- Are constructors early bound or late bound, and why?
- How does late binding relate to the vtable mechanism?
- What performance cost does late binding introduce compared to early binding?
MCQ Practice
1. Early binding resolves a method call at?
Early binding embeds the exact call target during compilation, before the program runs.
2. In C++, what keyword must be added to a method for it to use late binding?
C++ methods are non-virtual (early bound) by default; the virtual keyword opts a method into late binding.
3. Which is true of Java instance methods by default?
Java instance methods are virtual by default, so overriding and late binding work without any extra keyword.
Flash Cards
Early binding in one line? — Method call target resolved at compile time (non-virtual calls).
Late binding in one line? — Method call target resolved at runtime via vtable lookup (virtual calls).
C++ vs Java default? — C++ methods are non-virtual by default; Java instance methods are virtual by default.
Tradeoff? — Early binding is faster and fixed; late binding is slightly slower but enables polymorphism.