Room type hierarchy in LLD - System Design Guide

Problem Statement

When managing different types of rooms in a system, treating each room type as a separate unrelated entity leads to duplicated code and inconsistent behavior. This makes it hard to add new room types or change common features without breaking existing code.

Solution

Use a hierarchy where a base room class defines common properties and behaviors, and specialized room types inherit and extend this base. This allows code reuse, easier maintenance, and consistent handling of all room types while enabling specific customizations.

Architecture

Room (Base)

- name

↓

Conference

Room

This diagram shows a base Room class with common attributes and methods, and three specialized room types inheriting from it, each adding their own unique features.

Trade-offs

✓ Pros

→

Reduces code duplication by sharing common features in the base class.

→

Makes it easier to add new room types by extending the base class.

→

Ensures consistent behavior across all room types through inheritance.

✗ Cons

→

Tight coupling between base and derived classes can make changes risky.

→

Deep hierarchies can become complex and hard to understand.

→

Inheritance can limit flexibility if room types need to change behavior dynamically.

Use when multiple room types share common features but also have unique behaviors, especially if the number of room types is moderate and mostly static.

Avoid when room types have very different behaviors with little shared code, or when you need to change room behaviors dynamically at runtime.

Real World Examples

Airbnb

Airbnb models different room types like entire homes, private rooms, and shared rooms using a hierarchy to manage shared booking logic and specific features.

HotelTonight

HotelTonight uses room type hierarchies to handle various hotel room categories with shared booking and pricing logic but different amenities.

Code Example

The before code repeats name, capacity, and book method in each room type. The after code moves common parts to a base Room class, reducing duplication and making it easier to add new room types.

LLD

### Before (No hierarchy, duplicated code)
class ConferenceRoom:
    def __init__(self, name, capacity, projector):
        self.name = name
        self.capacity = capacity
        self.projector = projector
    def book(self):
        print(f"Booking conference room {self.name}")

class Bedroom:
    def __init__(self, name, capacity, bed_type):
        self.name = name
        self.capacity = capacity
        self.bed_type = bed_type
    def book(self):
        print(f"Booking bedroom {self.name}")

### After (Using inheritance)
class Room:
    def __init__(self, name, capacity):
        self.name = name
        self.capacity = capacity
    def book(self):
        print(f"Booking room {self.name}")

class ConferenceRoom(Room):
    def __init__(self, name, capacity, projector):
        super().__init__(name, capacity)
        self.projector = projector

class Bedroom(Room):
    def __init__(self, name, capacity, bed_type):
        super().__init__(name, capacity)
        self.bed_type = bed_type

# Usage
conf = ConferenceRoom("Conf A", 50, True)
conf.book()  # Booking room Conf A
bed = Bedroom("Bed 1", 2, "King")
bed.book()   # Booking room Bed 1

Alternatives

Composition over Inheritance

Instead of inheriting from a base room, room types contain components that define behavior, allowing more flexible combinations.

Use when: Choose when room behaviors need to change dynamically or when multiple behaviors must be combined without deep hierarchies.

Flat Structure with Type Field

Use a single room class with a type attribute and conditional logic for behavior instead of inheritance.

Use when: Choose when the number of room types is small and behaviors are simple, avoiding complexity of inheritance.

Summary

Room type hierarchy organizes room classes by shared and unique features using inheritance.

It reduces code duplication and eases maintenance by centralizing common logic.

Use it when room types share behavior but need specific customizations.