PHP Design Patterns — Singleton Test Suite Failure

Every PHP codebase beyond a certain size starts to rot in predictable ways — God classes that do everything, tightly coupled modules that break when you sneeze, duplicated logic scattered across controllers. These aren't signs of bad programmers; they're signs that the code grew without a shared vocabulary for solving recurring structural problems. Design patterns are that vocabulary, and they've been the lingua franca of serious software engineering since the Gang of Four published their seminal work in 1994.

The problem patterns solve isn't complexity for its own sake. It's the cost of change. When your PaymentProcessor is hardcoded to Stripe and the business suddenly needs PayPal too, you pay a tax — refactoring, regression testing, prayer. A well-applied Strategy or Factory pattern means that change costs an afternoon, not a sprint. Patterns encode the insight that software requirements always drift, so your architecture should make drift cheap.

By the end of this article you'll be able to identify which pattern fits which problem in a real PHP codebase, implement Singleton, Factory Method, Decorator, Observer, and Strategy with production-grade PHP 8.x code, spot the performance and testability traps each one hides, and answer the patterns questions that trip up even experienced developers in senior interviews.

What Are Design Patterns?

Design patterns are reusable, documented solutions to recurring software design problems. They're not copy-paste code — they're blueprints that you adapt to your architecture. The original 23 patterns from the Gang of Four fall into three categories: creational, structural, and behavioral.

Patterns solve the problem of change cost. When your code is tightly coupled, every new requirement forces you to rewrite large chunks. A pattern introduces a seam — a place where you can insert new behavior without touching existing code. The Strategy pattern, for example, lets you swap algorithms at runtime. The Observer pattern lets you notify multiple objects without hardcoding dependencies.

But patterns come with baggage. Each one adds indirection, more classes, and more files. If you apply a pattern to a problem that doesn't exist yet, you're paying the complexity tax for no benefit. The senior engineer's skill isn't knowing 23 patterns — it's knowing which one to ignore.

<?php

namespace TheCodeForge\Patterns;

interface PaymentStrategy
{
    public function pay(float $amount): string;
}

class CreditCardPayment implements PaymentStrategy
{
    public function pay(float $amount): string
    {
        return "Paid $amount via Credit Card.";
    }
}

class PayPalPayment implements PaymentStrategy
{
    public function pay(float $amount): string
    {
        return "Paid $amount via PayPal.";
    }
}

class Checkout
{
    public function __construct(private PaymentStrategy $strategy) {}

    public function process(float $amount): string
    {
        return $this->strategy->pay($amount);
    }
}

// Usage
$checkout = new Checkout(new PayPalPayment());
echo $checkout->process(150.00);  // Paid 150 via PayPal.

Creational Patterns — Singleton, Factory & Builder

Creational patterns abstract the instantiation process. They make a system independent of how its objects are created, composed, and represented.

The Singleton ensures a class has only one instance and provides a global access point. Use it carefully — it's a global variable with a marketing name. PHP's request lifecycle means a Singleton lives only for the current HTTP request, which often surprises devs coming from Java.

The Factory Method defines an interface for creating an object, but lets subclasses decide which class to instantiate. It decouples client code from concrete classes.

The Builder pattern separates the construction of a complex object from its representation, allowing the same construction process to create different representations. Perfect for objects with many optional parameters — avoids telescoping constructors.

<?php

namespace TheCodeForge\Patterns;

interface Logger
{
    public function log(string $message): void;
}

class FileLogger implements Logger
{
    public function log(string $message): void
    {
        file_put_contents('/var/log/app.log', $message . PHP_EOL, FILE_APPEND);
    }
}

class DatabaseLogger implements Logger
{
    public function log(string $message): void
    {
        // INSERT INTO logs ...
    }
}

abstract class LoggerFactory
{
    abstract public function createLogger(): Logger;

    public function logMessage(string $message): void
    {
        $logger = $this->createLogger();
        $logger->log($message);
    }
}

class FileLoggerFactory extends LoggerFactory
{
    public function createLogger(): Logger
    {
        return new FileLogger();
    }
}

// Usage
$factory = new FileLoggerFactory();
$factory->logMessage('User login event logged.');

Structural Patterns — Adapter, Decorator & Facade

Structural patterns compose classes and objects to form larger structures. They're about how to wire things together without making the wiring fragile.

The Adapter converts the interface of a class into another interface that clients expect. It's the pattern equivalent of a travel power plug — it doesn't change the device, it makes the connection work.

The Decorator attaches additional responsibilities to an object dynamically. It provides an alternative to subclassing for extending functionality. In PHP, decorators are often used for logging or caching wrappers around services.

The Facade provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use. Think of it as a remote control for a home theatre system — you press one button instead of turning on each device individually.

<?php

namespace TheCodeForge\Patterns;

interface Notification
{
    public function send(string $message): string;
}

class EmailNotification implements Notification
{
    public function send(string $message): string
    {
        return "Email: $message";
    }
}

abstract class NotificationDecorator implements Notification
{
    public function __construct(protected Notification $notification) {}
}

class SlackDecorator extends NotificationDecorator
{
    public function send(string $message): string
    {
        $result = $this->notification->send($message);
        return $result . " | Slack: $message";
    }
}

class SMSDecorator extends NotificationDecorator
{
    public function send(string $message): string
    {
        $result = $this->notification->send($message);
        return $result . " | SMS: $message";
    }
}

// Usage
$notification = new SlackDecorator(new SMSDecorator(new EmailNotification()));
echo $notification->send('Server down!');
// Output: Email: Server down! | SMS: Server down! | Slack: Server down!

Behavioral Patterns — Strategy, Observer & Command

Behavioral patterns focus on communication between objects — how they assign responsibilities and how they interact. These patterns are the most diverse and often the most applicable in daily PHP development.

The Strategy pattern (shown earlier) lets you define a family of algorithms and make them interchangeable. It's the pattern behind PHP's sort functions that accept a comparison callback.

The Observer pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. PHP's SplSubject and SplObserver provide a native implementation, but many frameworks use event dispatchers instead.

The Command pattern encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. It's the foundation of undo/redo features and job queues.

<?php

namespace TheCodeForge\Patterns;

class User implements \SplSubject
{
    private int $id;
    private \SplObjectStorage $observers;

    public function __construct(int $id)
    {
        $this->id = $id;
        $this->observers = new \SplObjectStorage();
    }

    public function attach(\SplObserver $observer): void
    {
        $this->observers->attach($observer);
    }

    public function detach(\SplObserver $observer): void
    {
        $this->observers->detach($observer);
    }

    public function notify(): void
    {
        foreach ($this->observers as $observer) {
            $observer->update($this);
        }
    }

    public function setId(int $id): void
    {
        $this->id = $id;
        $this->notify();
    }
}

class EmailNotifier implements \SplObserver
{
    public function update(\SplSubject $subject): void
    {
        if ($subject instanceof User) {
            echo "Email sent to user ID: " . $subject->getId() . "\n";
        }
    }
}

When to Apply Patterns — And When to Run Away

The biggest mistake junior engineers make is learning a pattern and then looking for somewhere to use it. That's the wrong direction. You should only introduce a pattern when you can point to a concrete pain — a problem you've already felt in production.

Here's a rule of thumb: if you're adding a pattern to code that works fine today, you're probably over-engineering. Patterns are replacements for pain, not decorations. Wait until you have at least two occurrences of a similar problem before extracting a pattern.

Also, patterns are not silver bullets. The Singleton pattern is often misused for global state and breaks testability. The Observer pattern can introduce performance surprises. The Factory pattern can lead to explosion of classes. Always weigh the benefit against the complexity cost.

In production, the most effective approach is to build simple code first, refactor toward patterns when duplication or coupling becomes painful, and never let a pattern become an unchangeable architecture.

<?php

namespace TheCodeForge\Patterns;

// Bad: Using a pattern before needed
class PaymentProcessor
{
    public function process(string $method, float $amount): string
    {
        // Early Strategy pattern — only one method for now
        if ($method === 'credit_card') {
            return $this->processCreditCard($amount);
        }
        throw new \InvalidArgumentException('Only credit_card supported currently');
    }

    private function processCreditCard(float $amount): string { /* ... */ }
}

// Better: Keep it simple until second method arrives
class PaymentProcessor
{
    public function processCreditCard(float $amount): string { /* ... */ }
}