Why Class Constructors Should Avoid Side Effects

Developers are all too familiar with debates about best practices. One debate that’s been making rounds for years concerns whether or not a class constructor should avoid side effects. While it’s easy to get dogmatic about this issue, the reality is more nuanced. This article will explore what side effects in constructors are, why you should generally avoid them, and the rare cases where they might be acceptable. We’ll back this up with some reasonable examples.

What Is a Side Effect in a Constructor?

A side effect occurs when a function or method changes the state of something outside its own scope. In the context of a class constructor, a side effect could be:

Writing to a file
Sending a network request
Modifying global variables
Interacting with a database

A side effect in a constructor goes beyond simply initializing properties and instead performs an action that affects the external world. For example:

class FileLogger
{
    private string $filePath;

    public function __construct(string $filePath)
    {
        $this->filePath = $filePath;
        // Side effect: actually creating the file
        file_put_contents($this->filePath, "Log file created.\n", FILE_APPEND);
    }
}

// Creating an instance of FileLogger has a side effect of creating a file
$logger = new FileLogger('/path/to/log.txt');

In the above code, instantiating the FileLogger class has an unintended side effect: it creates a file on the system. While this might seem harmless, it introduces several issues that can make your code harder to manage.

Why You Should Avoid Side Effects in Constructors

Here are some compelling reasons to avoid side effects in constructors:

Predictability: A constructor should create an object in a predictable and controlled manner. If side effects are involved, you may unknowingly trigger actions that aren’t immediately obvious, making debugging a nightmare.
Testability: Unit testing a class becomes more difficult when constructors have side effects. Tests should ideally operate in isolation, and a constructor that writes to a file, makes a network call, or queries a database can complicate this.
Dependency Management: When a constructor triggers actions outside its own context, it can make dependency injection and inversion of control more difficult to manage.
Performance: Side effects can introduce performance penalties, particularly if they involve I/O operations. This could make object creation unnecessarily expensive.

Let’s look at a cleaner way to handle the FileLogger class:

class FileLogger
{
    private string $filePath;

    public function __construct(string $filePath)
    {
        $this->filePath = $filePath;
    }

    public function initializeLog(): void
    {
        // The side effect is now contained within a method
        file_put_contents($this->filePath, "Log file created.\n", FILE_APPEND);
    }
}

// Object creation is now side-effect-free
$logger = new FileLogger('/path/to/log.txt');
$logger->initializeLog();

In this improved version, the constructor is purely responsible for setting up the object state. The side effect (creating the file) is deferred to a method that the consumer of the class can call explicitly.

When Are Side Effects Acceptable?

While avoiding side effects is a good rule of thumb, there are times when they are unavoidable or even desirable:

Frameworks and Dependency Injection Containers: In some cases, frameworks automatically instantiate classes, and having the constructor do some minimal setup (like connecting to a database) can be reasonable.
Initialization Requirements: If your class absolutely must perform a critical action to function correctly (e.g., opening a persistent database connection), you may justify a side effect. However, even in these cases, consider if a factory method might be a better alternative.
Performance Optimization: Sometimes, initializing resources in the constructor can improve performance if you know that the object will always require those resources immediately.

Practical Example: Database Connection

Here’s an example where a side effect might seem justified but can be improved:

Suboptimal Design:

class DatabaseConnection
{
    private \PDO $pdo;

    public function __construct(string $dsn, string $username, string $password)
    {
        // Side effect: opening a database connection
        $this->pdo = new \PDO($dsn, $username, $password);
    }

    public function getPdo(): \PDO
    {
        return $this->pdo;
    }
}

// The constructor opens a database connection, which could fail
$db = new DatabaseConnection('mysql:host=localhost;dbname=test', 'user', 'pass');

If the PDO connection fails, the object cannot even be instantiated properly, making error handling tricky. Instead, you could opt for:

Improved Design:

class DatabaseConnection
{
    private ?\PDO $pdo = null;
    private string $dsn;
    private string $username;
    private string $password;

    public function __construct(string $dsn, string $username, string $password)
    {
        $this->dsn = $dsn;
        $this->username = $username;
        $this->password = $password;
    }

    public function connect(): void
    {
        // Side effect is now delayed until explicitly requested
        $this->pdo = new \PDO($this->dsn, $this->username, $this->password);
    }

    public function getPdo(): ?\PDO
    {
        return $this->pdo;
    }
}

// Now, you have control over when the connection is established
$db = new DatabaseConnection('mysql:host=localhost;dbname=test', 'user', 'pass');
$db->connect();

This pattern makes it easier to manage errors and gives us more control over when the side effect occurs.

Avoiding side effects in our constructors is a sensible guideline that can make our code more predictable, easier to test, and simpler to maintain. However, rules aren’t meant to be absolute. There are scenarios where a constructor side effect might be acceptable, but even then, we should weigh the trade-offs carefully. As always, strive for clarity and simplicity.

Constructors should set up the state of the object. If there’s more going on, pause and consider: is there a better way? By designing our classes with minimal side effects, we make our applications more robust and easier to maintain.