Class Diagrams
Introduction: Why Class Diagrams Matter
Section titled “Introduction: Why Class Diagrams Matter”Class diagrams are the visual representation of your design. They help you:
- Communicate your design to interviewers
- Visualize relationships between classes
- Identify design issues early
- Plan implementation
Visual: The Power of Class Diagrams
Section titled “Visual: The Power of Class Diagrams”
Part 1: Understanding Class Diagrams
Section titled “Part 1: Understanding Class Diagrams”What Are Class Diagrams?
Section titled “What Are Class Diagrams?”Class diagrams show:
- Classes - With attributes and methods
- Relationships - How classes relate to each other
- Interfaces - Abstract contracts
- Inheritance - “is-a” relationships
- Composition - “has-a” relationships
Basic Class Notation
Section titled “Basic Class Notation”A class in a diagram shows:
- Class Name - At the top
- Attributes - Properties/fields (middle section)
- Methods - Operations (bottom section)
Visual: Class Notation
Section titled “Visual: Class Notation”
Access Modifiers
Section titled “Access Modifiers”- + Public - Accessible from anywhere
- - Private - Only accessible within class
- # Protected - Accessible within class and subclasses
- ~ Package - Accessible within package
Part 2: Class Relationships
Section titled “Part 2: Class Relationships”Types of Relationships
Section titled “Types of Relationships”- Inheritance (is-a) - Generalization
- Composition (has-a, owns) - Strong ownership
- Aggregation (has-a, uses) - Weak ownership
- Association (uses) - Reference/usage
- Dependency (depends on) - Temporary usage
Visual: Relationship Types
Section titled “Visual: Relationship Types”
Part 3: Inheritance (Generalization)
Section titled “Part 3: Inheritance (Generalization)”Inheritance represents an “is-a” relationship. A subclass is a type of superclass.
Example: Car is a Vehicle
UML Notation
Section titled “UML Notation”- Solid line with hollow triangle pointing to parent
- Arrow: Child → Parent
Example: Vehicle Hierarchy
Section titled “Example: Vehicle Hierarchy”classDiagram
class Vehicle {
<<abstract>>
-String licensePlate
-VehicleType vehicleType
+getVehicleType() VehicleType
}
class Car {
+getVehicleType() VehicleType
}
class Motorcycle {
+getVehicleType() VehicleType
}
class Truck {
+getVehicleType() VehicleType
}
Vehicle <|-- Car : extends
Vehicle <|-- Motorcycle : extends
Vehicle <|-- Truck : extends
✔ Use when:
- Subclass is a type of superclass
- Subclass shares common behavior
- You want polymorphism
❌ Don’t use when:
- Just sharing code (use composition)
- Relationship is “has-a” not “is-a”
Composition represents a “has-a” relationship with strong ownership. The whole owns the parts, and parts cannot exist without the whole.
Example: ParkingLot has ParkingSpots (spots don’t exist without the lot)
UML Notation
Section titled “UML Notation”- Solid line with filled diamond on the whole side
- Arrow: Part → Whole
- Multiplicity: 1 to many
Example: ParkingLot and ParkingSpot
Section titled “Example: ParkingLot and ParkingSpot”classDiagram
class ParkingLot {
-List~ParkingSpot~ spots
-int capacity
+parkVehicle(Vehicle) Ticket
+unparkVehicle(Ticket) Payment
}
class ParkingSpot {
-String spotId
-VehicleType spotType
-boolean isOccupied
+parkVehicle(Vehicle) void
+unparkVehicle() Vehicle
}
ParkingLot "1" *-- "many" ParkingSpot : contains
✔ Use when:
- Whole owns parts
- Parts cannot exist without whole
- Lifecycle is tied together
- Strong relationship
Example: Car has Engine (engine doesn’t exist without car)
Aggregation represents a “has-a” relationship with weak ownership. The whole uses the parts, but parts can exist independently.
Example: Team has Players (players exist without team)
UML Notation
Section titled “UML Notation”- Solid line with hollow diamond on the whole side
- Arrow: Part → Whole
- Multiplicity: 1 to many
Example: Team and Player
Section titled “Example: Team and Player”classDiagram
class Team {
-String teamName
-List~Player~ players
+addPlayer(Player) void
+removePlayer(Player) void
}
class Player {
-String playerId
-String name
+getName() String
}
Team "1" o-- "many" Player : has
✔ Use when:
- Whole uses parts
- Parts can exist independently
- Lifecycle is independent
- Weak relationship
Example: Library has Books (books exist without library)
| Aspect | Composition | Aggregation |
|---|---|---|
| Ownership | Strong | Weak |
| Lifecycle | Tied together | Independent |
| Example | Car-Engine | Team-Player |
| Diamond | Filled | Hollow |
Association represents a “uses” relationship. One class references or uses another class.
Example: Ticket references Vehicle
UML Notation
Section titled “UML Notation”- Solid line with arrow (optional)
- Arrow: Source → Target
- Can have multiplicity
Example: Ticket and Vehicle
Section titled “Example: Ticket and Vehicle”classDiagram
class Ticket {
-String ticketId
-DateTime entryTime
+calculateDuration() Duration
}
class Vehicle {
-String licensePlate
-VehicleType vehicleType
+getVehicleType() VehicleType
}
class ParkingSpot {
-String spotId
-boolean isOccupied
}
Ticket --> Vehicle : references
Ticket --> ParkingSpot : references
✔ Use when:
- One class uses another
- Reference relationship
- Not ownership
- Temporary or optional
Example: Order references Customer (order uses customer info)
Dependency represents a temporary “depends on” relationship. One class depends on another for a specific operation.
Example: Method parameter, return type, local variable
UML Notation
Section titled “UML Notation”- Dashed line with arrow
- Arrow: Dependent → Dependency
Example: Service and Repository
Section titled “Example: Service and Repository”classDiagram
class ParkingLotService {
+parkVehicle(Vehicle) Ticket
+unparkVehicle(Ticket) Payment
}
class ParkingSpotRepository {
+findAvailableSpot(VehicleType) ParkingSpot
+save(ParkingSpot) void
}
ParkingLotService ..> ParkingSpotRepository : uses
✔ Use when:
- Temporary relationship
- Method parameter
- Return type
- Local variable usage
Part 8: Complete Example: Parking Lot System
Section titled “Part 8: Complete Example: Parking Lot System”Full Class Diagram
Section titled “Full Class Diagram”classDiagram
class ParkingLot {
-List~ParkingSpot~ spots
-int capacity
+parkVehicle(Vehicle) Ticket
+unparkVehicle(Ticket) Payment
-findAvailableSpot(VehicleType) ParkingSpot
}
class ParkingSpot {
-String spotId
-VehicleType spotType
-boolean isOccupied
-Vehicle vehicle
+parkVehicle(Vehicle) void
+unparkVehicle() Vehicle
+isAvailable() boolean
}
class Vehicle {
<<abstract>>
-String licensePlate
-VehicleType vehicleType
+getVehicleType() VehicleType
}
class Car {
+getVehicleType() VehicleType
}
class Motorcycle {
+getVehicleType() VehicleType
}
class Ticket {
-String ticketId
-DateTime entryTime
+calculateDuration() Duration
}
class Payment {
-String paymentId
-float amount
-DateTime paymentTime
+processPayment() boolean
}
ParkingLot "1" *-- "many" ParkingSpot : contains
ParkingLot --> Ticket : creates
ParkingLot --> Payment : creates
ParkingSpot --> Vehicle : contains
Ticket --> Vehicle : references
Ticket --> ParkingSpot : references
Payment --> Ticket : references
Vehicle <|-- Car : extends
Vehicle <|-- Motorcycle : extends
Visual: Complete Diagram
Section titled “Visual: Complete Diagram”
Relationship Summary
Section titled “Relationship Summary”| Relationship | Type | Example |
|---|---|---|
| ParkingLot → ParkingSpot | Composition | ParkingLot has ParkingSpots (owns) |
| Vehicle → Car | Inheritance | Car is a Vehicle |
| Ticket → Vehicle | Association | Ticket references Vehicle |
| Payment → Ticket | Association | Payment references Ticket |
| ParkingLot → Ticket | Dependency | ParkingLot creates Ticket |
Part 9: Multiplicity
Section titled “Part 9: Multiplicity”What Is Multiplicity?
Section titled “What Is Multiplicity?”Multiplicity shows how many instances participate in a relationship.
Common Multiplicities
Section titled “Common Multiplicities”- 1 - Exactly one
- 0..1 - Zero or one (optional)
- 1..* - One or more
- * or 0..* - Zero or more (many)
- n..m - Between n and m
Examples
Section titled “Examples”classDiagram
class ParkingLot {
-List~ParkingSpot~ spots
}
class ParkingSpot {
-Vehicle vehicle
}
class Ticket {
-Vehicle vehicle
-ParkingSpot spot
}
ParkingLot "1" *-- "many" ParkingSpot : contains
ParkingSpot "1" --> "0..1" Vehicle : contains
Ticket "1" --> "1" Vehicle : references
Ticket "1" --> "1" ParkingSpot : references
Visual: Multiplicity
Section titled “Visual: Multiplicity”
Part 10: Interfaces and Abstract Classes
Section titled “Part 10: Interfaces and Abstract Classes”Interfaces define contracts that classes implement.
UML Notation: <<interface>> or I prefix
Example: Payment Interface
Section titled “Example: Payment Interface”classDiagram
class PaymentProcessor {
<<interface>>
+processPayment(amount, method) boolean
+refundPayment(paymentId) boolean
}
class StripeProcessor {
+processPayment(amount, method) boolean
+refundPayment(paymentId) boolean
}
class PayPalProcessor {
+processPayment(amount, method) boolean
+refundPayment(paymentId) boolean
}
PaymentProcessor <|.. StripeProcessor : implements
PaymentProcessor <|.. PayPalProcessor : implements
Abstract classes provide partial implementation.
UML Notation: <<abstract>> or italic name
Example: Vehicle Abstract Class
Section titled “Example: Vehicle Abstract Class”classDiagram
class Vehicle {
<<abstract>>
-String licensePlate
+getVehicleType() VehicleType
+calculateParkingFee() float
}
class Car {
+getVehicleType() VehicleType
+calculateParkingFee() float
}
Vehicle <|-- Car : extends
Part 11: Best Practices
Section titled “Part 11: Best Practices”✔ Use clear names - Descriptive class and method names
✔ Show key relationships - Don’t show everything, focus on important ones
✔ Use proper notation - Follow UML standards
✔ Group related classes - Organize diagram logically
✔ Show multiplicities - When important
✔ Use interfaces - For abstraction
Don’ts
Section titled “Don’ts”❌ Don’t show everything - Focus on important relationships
❌ Don’t use wrong relationships - Understand composition vs aggregation
❌ Don’t make it too complex - Keep it readable
❌ Don’t forget access modifiers - Show visibility
❌ Don’t mix concepts - Keep layers separate
Visual: Good vs Bad
Section titled “Visual: Good vs Bad”
Summary: Class Diagrams
Section titled “Summary: Class Diagrams”Key Takeaways
Section titled “Key Takeaways”✔ Class diagrams visualize your design
✔ Inheritance - “is-a” relationship (solid line, hollow triangle)
✔ Composition - “has-a” with ownership (filled diamond)
✔ Aggregation - “has-a” without ownership (hollow diamond)
✔ Association - “uses” relationship (solid line)
✔ Dependency - “depends on” (dashed line)
✔ Multiplicity - Shows quantity in relationships
✔ Interfaces - Define contracts
Relationship Quick Reference
Section titled “Relationship Quick Reference”| Relationship | Notation | When to Use |
|---|---|---|
| Inheritance | Solid line, hollow triangle | ”is-a” relationship |
| Composition | Solid line, filled diamond | Strong ownership |
| Aggregation | Solid line, hollow diamond | Weak ownership |
| Association | Solid line, arrow | Reference/usage |
| Dependency | Dashed line, arrow | Temporary dependency |
Visual Summary
Section titled “Visual Summary”
Next Steps
Section titled “Next Steps”Now that you’ve mastered class diagrams, let’s learn how to define contracts and APIs:
Next: Contract and API Definitions →
This next guide will teach you how to define clear interfaces, method signatures, and API contracts for your design!