Theory
Members, librarians, and deja vu
BookBridge needs people now, not just books. A Member has a name, an ID, borrowed books. A Librarian has a name, an ID, a staff code.
You start writing 2 classes and feel Semester 3 deja vu: same name field, same ID logic, copied twice. In BCA304 you solved this exact smell in C++ with inheritance.
Java's version is one keyword: class Member extends Person. And on top of the family, Java builds its best trick: polymorphism.
Theory
The 3 pillars, in BookBridge terms
Encapsulation: private data behind public methods. Member's fineDue is private; only payFine() can reduce it. You built this in the access-controls lesson; now it has its exam name.
Inheritance: class Member extends Person gives Member every Person field and method, plus its own. One parent maximum: Java classes have single inheritance only.
Polymorphism: one call, many behaviours: p.describe() acts differently depending on what p actually points at. The rest of this lesson unpacks it.
Practical
One family, one call, two behaviours
class Person {
String name;
void describe() {
System.out.println("Person: " + name);
}
}
class Member extends Person {
int booksIssued;
@Override
void describe() { // same signature: OVERRIDING
System.out.println("Member " + name + " has " + booksIssued + " book(s)");
}
}
public class BookBridge {
public static void main(String[] args) {
Person p = new Member(); // a Member IS a Person
p.name = "Riya";
p.describe(); // whose version runs?
}
}
Quiz
In the listing above, p is declared as Person but holds a new Member(). What does p.describe() print?
- Person: Riya
- Member Riya has 0 book(s)
- Compile error: a Person reference cannot call an overridden method
- Both lines, parent first then child
Show the answer
Member Riya has 0 book(s)
Java looks at the object's REAL type at run time, not the reference's declared type: the object is a Member, so Member's describe() runs, with booksIssued at its default 0. This is dynamic method dispatch, the machinery of polymorphism. Option A is what students who think the reference type decides would answer, the exact misconception this question targets. Nothing about overriding is a compile error, and Java never runs both versions unless the child explicitly asks (next lesson's super).
At a glance
Overloading vs overriding (the confusion pair)
| Aspect | Overloading | Overriding |
|---|---|---|
| Where | Same class | Parent and child class |
| Signature | Same name, DIFFERENT parameters | Same name, SAME parameters |
| Decided | At compile time | At run time (dynamic dispatch) |
| Purpose | Convenient variants of one action | Child replaces inherited behaviour |
Think first
Name that mechanism
Inside class Librarian: issueBook(String title) and issueBook(String title, int days). Overloading or overriding? Decide before tapping.
Show the answer
Overloading. Same class, same name, different parameter lists (one takes an extra int), so the compiler picks the right one from the arguments at each call site, at compile time. Overriding would need a parent class whose issueBook(String) Librarian redefines with the identical signature. Quick test to apply in exams: different parameters = overloading, different classes in a family with the same signature = overriding.
Watch out
Where this pair eats marks
Swapped definitions: writing "overriding means same class, different parameters" scores 0 even if everything else is right. Anchor it: overload = more parameter loads; override = the child rides over the parent.
Signature slips: change the parameter list while "overriding" and you have silently overloaded instead; the parent's version still runs through parent references. The @Override annotation exists exactly to make the compiler catch that slip: use it.
Theory
The C++ contrast that impresses examiners
In BCA304's C++, dynamic dispatch needed the virtual keyword; forget it and the parent's method ran. In Java, every instance method is virtual by default: overriding just works. That one sentence, dropped into a Java-vs-C++ or polymorphism answer, signals real understanding. The family you built here is load-bearing: this and super (next lesson) navigate it, and interfaces complete Java's polymorphism story at the end of this unit.
Summary
Key takeaways
- Encapsulation: private fields, public guard methods; inheritance: extends, one parent only; polymorphism: one call, many forms.
- Overloading: same class, same name, different parameter lists, resolved at compile time.
- Overriding: child redefines an inherited method with the identical signature, resolved at run time.
- Person p = new Member(); p.describe() runs Member's version: the object's type decides, not the reference's.
- All Java instance methods are virtual by default; C++ needed the virtual keyword.
- @Override makes the compiler verify a genuine override.
- Memory hook: overload adds loads, override rides over.