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”
✔ 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”
✔ 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”
✔ 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”
✔ 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”
✔ 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”
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”
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”
Abstract classes provide partial implementation.
UML Notation: <<abstract>> or italic name
Example: Vehicle Abstract Class
Section titled “Example: Vehicle Abstract Class”
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!