Class Relationships in Practice: Parking Lot Example

Class diagrams express four fundamental relationships: Inheritance (▲), Composition (◆), Aggregation (◇), and Association (→). Let's see how these apply to a Parking Lot system.
Vehicle
+ getSize(): Size
▲
Car
Motorcycle
Truck
Inheritance (IS-A): Car IS-A Vehicle
1. Inheritance (▲) - Generalization:
Relationship: "IS-A" relationship (Car IS-A Vehicle)
Notation: Solid line with hollow triangle pointing to parent
Usage: When subclasses share common behavior but have specialized implementations
Example: Car, Motorcycle, and Truck all inherit from abstract Vehicle
ParkingLot
- floors: List
◆
Floor
- spots: List
Composition (HAS-A, strong): ParkingLot owns Floors
2. Composition (◆) - Strong Ownership:
Relationship: "HAS-A" with strong ownership (part cannot exist without whole)
Notation: Solid line with filled diamond at owner side
Usage: When child's lifecycle is bound to parent (destroy parent, destroy child)
Example: ParkingLot owns Floor objects. If ParkingLot is destroyed, Floors cease to exist
ParkingSpot
- currentVehicle: Vehicle
◇
Vehicle
- licensePlate: String
Aggregation (HAS-A, weak): ParkingSpot references Vehicle
3. Aggregation (◇) - Weak Ownership:
Relationship: "HAS-A" with weak ownership (part can exist independently)
Notation: Solid line with hollow diamond at container side
Usage: When objects have independent lifecycles but one uses the other
Example: ParkingSpot references a Vehicle. Vehicle exists before parking and continues after leaving
ParkingTicket
+ calculateFee(): Money
→
FeeCalculator
+ compute(duration): Money
Association (USES-A): ParkingTicket uses FeeCalculator
4. Association (→) - Usage Relationship:
Relationship: "USES-A" or "KNOWS-ABOUT" relationship
Notation: Simple solid line or arrow indicating direction
Usage: When one class uses another temporarily (method parameter, local variable)
Example: ParkingTicket uses FeeCalculator to compute fees, but doesn't own it
Interview Tip: If you're unsure between composition and aggregation, ask yourself: "If I delete the parent, should the child be deleted too?" If yes, use composition (◆). If no, use aggregation (◇).
Common Mistake: Many candidates confuse aggregation with association. Remember that aggregation implies a "whole-part" relationship (ParkingSpot contains Vehicle), while association is just usage (ParkingTicket uses FeeCalculator for calculation). If there's no containment semantics, use association instead.

💡 Key Takeaways

✓Inheritance (▲): IS-A relationship, hollow triangle pointing to parent, used for polymorphism

✓Composition (◆): Strong HAS-A, filled diamond, child lifecycle bound to parent (ParkingLot owns Floor)

✓Aggregation (◇): Weak HAS-A, hollow diamond, child exists independently (ParkingSpot references Vehicle)

✓Association (→): USES-A relationship, simple line/arrow, temporary usage (ParkingTicket uses FeeCalculator)

✓Decision rule: If deleting parent should delete child, use composition; otherwise aggregation or association

📌 Examples

1Inheritance: Car, Motorcycle, Truck all inherit from Vehicle abstract class

2Composition: ParkingLot contains Floors which contain ParkingSpots (destroy lot, destroy floors)

3Aggregation: ParkingSpot has a Vehicle reference, but Vehicle exists before and after parking

4Association: ParkingTicket uses FeeCalculator service to compute fees without owning it

← Back to Class Diagrams Overview