Práctica: Singleton + Observer

// La dependencia entra por el constructor: la firma ya no miente.
class ReportMailer
{
    public function __construct(
        private string $to,
        private Logger $logger,
    ) {}

    public function send(string $body): void
    {
        $this->logger->log("Enviando reporte a {$this->to}");
        mail($this->to, 'Reporte', $body);
    }
}

// En un test, pasás un logger falso sin pelear con nada:
$mailer = new ReportMailer('jefe@empresa.sv', new FakeLogger());
$mailer->send('ventas del mes');

// Clase normal: constructor público, sin getInstance() global.
class Database
{
    public function __construct() { /* abre conexión */ }
    public function query(string $sql): array { /* ... */ return []; }
}

// La unicidad la decide el contenedor, NO la clase:
// (Laravel) en un Service Provider:
$this->app->singleton(Database::class);

// y quien la necesita la RECIBE, no la busca:
class OrderRepository
{
    public function __construct(private Database $db) {}
}

// Respuesta: NO hace falta refactorizar. El Singleton acá es aceptable.
//
// Razón: el costo que Hevery señala (testing frágil, dependencias
// ocultas que estorban al evolucionar) no se paga en un script
// de un solo uso, sin tests unitarios, que corre una vez y muere.
//
// Aplicar DI + contenedor acá sería sobre-ingeniería: agregar
// estructura para resolver un problema que este código no tiene.
//
// (Si MAÑANA este IdSequence se moviera a la app de producción,
//  que sí se testea y evoluciona, AHÍ sí valdría refactorizar.)

interface StockObserver
{
    public function onStockReduced(Product $product, int $qty): void;
}

class StockManager
{
    private array $observers = [];

    public function subscribe(StockObserver $o): void
    {
        $this->observers[] = $o;
    }

    public function reduce(Product $product, int $qty): void
    {
        $product->stock -= $qty;
        $product->save();

        // ya no instancia a nadie: solo avisa por la interfaz
        foreach ($this->observers as $o) {
            $o->onStockReduced($product, $qty);
        }
    }
}

// el wiring vive AFUERA. Agregar un reaccionador = una línea, sin tocar StockManager:
$mgr = new StockManager();
$mgr->subscribe(new CacheObserver());
$mgr->subscribe(new ReorderObserver());

class AuctionHouse
{
    private array $observers = [];

    public function subscribe(BidObserver $o): void
    {
        $this->observers[] = $o;
    }

    public function placeBid(float $amount): void
    {
        echo "Puja registrada: \$$amount\n";

        foreach ($this->observers as $o) {
            $o->onNewBid($amount);
        }
    }
}

// salida esperada:
// Puja registrada: $150
// Email: nueva puja de $150
// Dashboard actualizado: $150

// Respuesta: NO. Acá Observer es sobre-ingeniería.
//
// Observer paga cuando hay VARIOS reaccionadores, o cuando
// entran y salen sin que el emisor deba enterarse. Acá hay
// UNO solo, fijo: mandar la confirmación. Siempre uno.
//
// Meter una interfaz, una lista de observers y subscribe()
// para un único efecto agrega indirección sin beneficio:
// el flujo se vuelve más difícil de seguir, no más fácil.
//
// La llamada directa ($this->mailer->sendConfirmation())
// es más honesta: se lee de un vistazo qué pasa al confirmar.
//
// (Si mañana hubiera que avisar a 4 sistemas distintos y la
//  lista creciera, AHÍ recién Observer empezaría a pagar.)