Realization (Implementation)
You're designing a payment system. You have different payment methods: credit card, PayPal, bank transfer, and cryptocurrency. Each method processes payments differently, but they all share the same contract: accept an amount and return a result.
How do you model this "implements a contract" relationship?
This is where Realization comes in. It represents the relationship between an interface (or abstract class) and the class that implements it.
Realization is an "implements" relationship where a class fulfills a contract defined by an interface.
1. What is Realization?
Realization represents a contract fulfillment relationship. Think of it as a promise: the interface declares "these methods must exist," and the implementing class promises to provide them.
The relationship works like this:
- An interface defines what must be done (the contract)
- A class implements how it's done (the fulfillment)
- The implementing class must provide all methods declared in the interface
- Multiple classes can realize the same interface differently
Real-world analogy
Think of a job description. The job description (interface) defines what skills and responsibilities are required. Different employees (classes) can fulfill that job description in their own way, but they all meet the requirements.
2. UML Representation
UML uses specific visual conventions to distinguish realization from other relationships.
Basic Realization
A dashed line with a hollow (unfilled) triangle pointing to the interface.
Compare this to inheritance, which uses a solid line with a hollow triangle. The dashed line visually suggests a "promise" or "contract" rather than direct descent.
Multiple Interfaces
A class can implement multiple interfaces, gaining multiple capabilities.
FileHandler can read, write, and be closed. Each interface represents a single, focused capability.
4. Realization vs Inheritance
Both create hierarchical relationships, but they serve different purposes.
Notice the key difference: Flyable connects unrelated things (Bird, Airplane, Drone) that share a capability. Animal connects related things (Dog, Cat, Bird) that share an identity.
Inheritance models identity
"A Dog IS an Animal."
The child inherits everything from the parent, including state (fields) and behavior (methods). You use it when there's a true taxonomic relationship.
Use Inheritance when:
- There's a true "is-a" relationship (Dog is an Animal)
- You want to share implementation code across related classes
- Child classes are specializations of the parent
- State (fields) needs to be inherited
Realization models capability
"A Bird CAN fly, and so can an Airplane."
The implementing classes share what they can do, not what they are. A Bird and an Airplane have nothing else in common.
Use Realization (Interfaces) when:
- Unrelated classes share a capability (Flyable, Serializable, Comparable)
- Multiple inheritance of behavior is needed
- You want maximum flexibility and loose coupling
- The contract matters more than shared implementation
Often you'll use both together. A Car might extend Vehicle (sharing common vehicle behavior) while implementing Drivable, Insurable, and Parkable interfaces (different capabilities).