Large Classes

refactoring
Last reviewed

February 4, 2025

Last modified

March 25, 2025

A monolithic design is where an entire system is built as a single, tightly coupled unit without clear separation of responsibilities or modularization. This often leads to large, complex classes that handle multiple responsibilities, making the codebase harder to understand, modify, and maintain.

Symptoms

  • Large classes that try to handle too many responsibilities.
  • Code duplication across multiple parts of the system.
  • Difficulties in testing because changes in one part of the code affect others.
  • Limited reusability of components due to tight coupling.
  • Small modifications require extensive changes across the codebase.

Example - Violating the Single Responsibility Principle

In this example, we are writing code for a temperature monitoring system. A bad design would be putting everything inside one big class:

class SensorSystem:
    def __init__(self):
        self.temperature = 0

    def read_temperature(self):
        # Simulated temperature reading
        self.temperature = 25  
        print(f"Temperature: {self.temperature}°C")

    def log_temperature(self):
        # Simulated logging
        print(f"Logging temperature: {self.temperature}°C")

    def send_alert(self):
        if self.temperature > 30:
            print("ALERT: High temperature detected!")

def main():
    sensor_system = SensorSystem()
    sensor_system.read_temperature()
    sensor_system.log_temperature()
    sensor_system.send_alert()

if __name__ == "__main__":
    main()

Solution

We should split this class into smaller, focused classes: - TemperatureSensor – Handles sensor readings. - Logger – Handles logging. - AlertSystem – Handles alerts.

  1. Follow the Single Responsibility Principle (SRP) - Ensure that each class has only one job. If a class is doing too much, split its responsibilities into separate classes.
  2. Use dependency injection: Reduce class coupling by calling dependencies as arguments (injecting dependencies) rather than hard-coding them. This promotes modularity and testability, as well as making it easier to swap out components.
class TemperatureSensor:
    def read_temperature(self):
        # Simulated sensor reading
        return 25  

class Logger:
    def log(self, message):
        print(f"LOG: {message}")

class AlertSystem:
    def send_alert(self, temperature):
        temperature_threshold = 30
        if temperature > temperature_threshold:
            print("ALERT: High temperature detected!")

class SensorSystem:
    def __init__(self, sensor, logger, alert_system):
        self.sensor = sensor
        self.logger = logger
        self.alert_system = alert_system

    def monitor_temperature(self):
        temperature = self.sensor.read_temperature()
        self.logger.log(f"Temperature: {temperature}°C")
        self.alert_system.send_alert(temperature)

# Dependency Injection
def main():
    sensor = TemperatureSensor()
    logger = Logger()
    alert_system = AlertSystem()
    sensor_system = SensorSystem(sensor, logger, alert_system) # dependencies injected

    sensor_system.monitor_temperature()

if __name__ == "__main__":
    main()

Why is this better?

  • No unnecessary mixing of concerns.
  • Easily swap different logging or alerting mechanisms.
  • Each component can be tested in isolation.

Key Takeaways

  • If your class is doing too many things, split it into smaller, focused classes.
  • Use dependency injection to keep components flexible and testable.
  • Following modular design makes your code easier to understand, modify, and reuse.
Learn more