What is the Composite Reuse Principle?
Learn the Composite Reuse Principle in OOP — why composition and delegation beat inheritance for reuse — with a Java example.
Expected Interview Answer
The Composite Reuse Principle states that classes should achieve code reuse through composition — holding references to other objects and delegating to them — rather than through inheritance from a base class.
It is the formal name behind the well-known guideline “favor composition over inheritance.” Under this principle, behavior is assembled at runtime by wiring together small, independent objects, instead of being fixed at compile time through a rigid class hierarchy. Composed objects are typically accessed only through interfaces, so an implementation can be swapped without recompiling or reshaping the class tree. The principle does not forbid inheritance; it says inheritance should be reserved for genuine is-a relationships where subtype substitutability actually holds, while has-a relationships should be modeled with composition.
- Avoids fragile, deep inheritance hierarchies
- Allows behavior to be swapped or changed at runtime
- Keeps classes loosely coupled to concrete implementations
- Encourages small, single-purpose, independently testable classes
AI Mentor Explanation
A franchise team is not built by inheriting a fixed template of “ideal player”; it is assembled by picking an opener, a spinner, and a wicketkeeper from a pool of available specialists and wiring them into a lineup. If the team needs a different bowling attack next season, the selectors swap the bowler component in, they do not redesign the entire team class from scratch. That is the Composite Reuse Principle: build capability by holding and combining separate objects, not by locking behavior into one deep inherited chain.
Step-by-Step Explanation
Step 1
Identify the varying behavior
Spot the responsibility that changes independently of the rest of the class (e.g. how payment is processed).
Step 2
Extract it behind an interface
Define a small interface capturing just that responsibility.
Step 3
Hold a reference, don’t extend
Give the class a field of that interface type instead of subclassing a concrete implementation.
Step 4
Delegate calls
The class forwards work to the held object, and the concrete implementation can be swapped at runtime.
What Interviewer Expects
- Correct definition: reuse via composition/delegation, not inheritance
- Awareness that this is the formal basis for “favor composition over inheritance”
- Recognition that inheritance is still appropriate for genuine is-a relationships
- A concrete example distinguishing has-a from is-a
Common Mistakes
- Claiming the principle forbids inheritance entirely
- Confusing composition with simple aggregation without delegation
- Not mentioning runtime flexibility as a key motivation
- Failing to connect the principle to reduced coupling
Best Answer (HR Friendly)
“The Composite Reuse Principle says you should build up an object’s behavior by combining smaller objects it holds references to, rather than by inheriting from a big parent class. It keeps your classes flexible because you can swap out one piece for another without rewriting or reshaping the whole class hierarchy.”
Code Example
interface PaymentMethod {
void pay(double amount);
}
class CreditCardPayment implements PaymentMethod {
public void pay(double amount) {
System.out.println("Paid " + amount + " via credit card");
}
}
class Checkout {
// Composition: Checkout HOLDS a PaymentMethod instead of extending one
private PaymentMethod paymentMethod;
Checkout(PaymentMethod paymentMethod) {
this.paymentMethod = paymentMethod;
}
void completeOrder(double amount) {
paymentMethod.pay(amount); // delegate, swappable at runtime
}
}
Checkout checkout = new Checkout(new CreditCardPayment());
checkout.completeOrder(59.99);Follow-up Questions
- How does the Composite Reuse Principle relate to the Strategy pattern?
- When is inheritance still the right choice over composition?
- How does composition help with unit testing compared to inheritance?
- What problems does deep inheritance typically cause in large codebases?
MCQ Practice
1. The Composite Reuse Principle recommends achieving reuse primarily through?
The principle favors holding and delegating to composed objects over inheriting from a base class.
2. Which relationship type does composition typically model?
Composition models a has-a relationship, where an object holds and delegates to another object.
3. A key practical benefit of following this principle is?
Because composed dependencies are just references, swapping the concrete implementation changes behavior without recompiling a class hierarchy.
Flash Cards
Composite Reuse Principle in one line? — Favor composition and delegation over inheritance for code reuse.
What relationship does it favor? — has-a, modeled through held object references.
Does it forbid inheritance? — No — inheritance is still right for genuine is-a substitutable relationships.
Main benefit? — Runtime flexibility and looser coupling than a fixed class hierarchy.