All Together

Let’s build a complete Library Management System that demonstrates all four class relationships working together.

System Overview

We’ll design a library system with:

• Library (main system)
• Book (items in library)
• Member (people who borrow books)
• Librarian (staff managing library)
• Loan (borrowing record)
• Fine (penalty for late returns)

Complete Implementation

Relationship Summary

Relationship Breakdown

1. Inheritance (Person → Member, Librarian)

• Why: Both share common attributes (name, email) and have roles
• Type: “Is-a” relationship

2. Composition (Library → Book, Member → Loan, Loan → Fine)

• Why: Books are part of library, loans belong to members, fines belong to loans
• Type: Strong ownership, cannot exist independently

3. Aggregation (Library → Member, Library → Librarian)

• Why: Members and librarians can exist independently (can transfer/leave)
• Type: Weak ownership, independent lifecycle

4. Association (Loan → Member, Book, Librarian)

• Why: Loan references these classes but doesn’t own them
• Type: “Knows-a” relationship

5. Dependency (Member → Book, Librarian → Loan)

• Why: Used temporarily as method parameters
• Type: Temporary use, no storage

Key Takeaways

Remember

This example demonstrates:

• Inheritance for shared behavior (Person base class)
• Composition for essential parts (Books in Library, Loans in Member)
• Aggregation for optional parts (Members/Librarians in Library)
• Association for references (Loan references Member, Book, Librarian)
• Dependency for temporary use (method parameters)

Understanding when to use each relationship type helps create flexible, maintainable systems!