Factory Method for Nothing

Quando l’architettura continua a funzionare, ma il senso evapora

C’è una frase — attribuita a Mario Fusco — che suona quasi banale:

“Un software che non ha output ha solo uno scopo: scaldare il processore.”

È una frase giusta.
Ma incompleta.

Perché esiste una classe di sistemi molto più sofisticata:
sistemi che producono output perfettamente valido… e completamente inutile.

Non falliscono.
Non crashano.
Non segnalano errori.

Semplicemente, non fanno nulla di rilevante.

E lo fanno benissimo.

Il punto non è il fallimento

È la simulazione della produzione

Nell’ingegneria del software object-oriented esiste un pattern classico: il Factory Method.

Serve a delegare la creazione degli oggetti.
È elegante, estendibile, formalmente impeccabile.

Ora immagina di usarlo per costruire questo:

una factory che segue tutte le regole…
e alla fine non produce niente

Oppure, peggio:

produce qualcosa che formalmente è corretto,
ma ontologicamente è vuoto

Qui il discorso cambia.

Non siamo più nel bug.
Siamo nella messa in scena della produzione.

Caso 1 — La versione ingenua

Il ritorno esplicito del nulla

La forma più semplice è brutale: la factory ritorna null.

interface Product {
    void execute();
}

class ConcreteProduct implements Product {
    public void execute() {
        System.out.println("Doing something...");
    }
}

class ProductFactory {
    public static Product create(String type) {
        if ("real".equalsIgnoreCase(type)) {
            return new ConcreteProduct();
        }

        // Factory Method for Nothing
        return null;
    }
}

Qui il gioco è scoperto.

• il sistema dichiara il vuoto
• il contratto è spezzato
• l’assenza è evidente

È quasi onesto.

Troppo.

Caso 2 — La versione elegante

Quando il nulla diventa un oggetto

Molto più interessante è l’uso del Null Object Pattern.

La factory non ritorna null.
Ritorna un oggetto valido… che non fa nulla.

public interface IArtifact
{
    void Render();
    bool IsNull { get; }
}

public sealed class RealArtifact : IArtifact
{
    public void Render()
    {
        Console.WriteLine("Rendering something meaningful");
    }

    public bool IsNull => false;
}

public sealed class NullArtifact : IArtifact
{
    public void Render()
    {
        Console.WriteLine("[NullArtifact] Nothing to render.");
    }

    public bool IsNull => true;
}

public static class ArtifactFactory
{
    public static IArtifact Create(string key)
    {
        if (key == "real")
            return new RealArtifact();

        return new NullArtifact();
    }
}

Qui il sistema:

• rispetta il contratto
• produce un oggetto valido
• non genera errori

Eppure:

non succede nulla

Questa è la forma più pericolosa.

Perché il vuoto non è più un errore.
È un esito corretto.

Caso 3 — Il sistema che assorbe tutto

Il vuoto come comportamento standard

In una versione più evoluta, la factory diventa un sistema adattivo:

class NullProduct:
    def execute(self):
        return "No operation performed. The system preserves its emptiness."

class ConcreteProduct:
    def execute(self):
        return "Produced something."

class FactoryMethodForNothing:

    def create(self, key):
        if key == "real":
            return ConcreteProduct()

        return NullProduct()

Qualunque input non previsto:

• non genera errore
• non rompe il sistema
• non viene segnalato

Nota: il codice Python può essere eseguito. Invitiamo i lettori a farlo ed osservarne il comportamento.

Viene normalizzato nel nulla.

E qui il discorso esce dal codice

A questo punto il pattern smette di essere un pattern.

Diventa una lente.

Perché descrive perfettamente una classe di sistemi molto diffusa:

• strutture che funzionano
• processi che scorrono
• metriche che migliorano
• output formalmente corretti

ma che, nel concreto:

non producono alcun effetto reale

core_temperature

SATISFACTION_THRESHOLD

Doctor Ka.OS

(presunto nome civile: Kaveh Antonovič Osipov, 2077? – )

Teorico russo-iraniano, già ricercatore in informatica quantistica e successivamente espulso — o auto-espulso — dai circuiti accademici maggiori dopo aver definito il dashboarding manageriale “una forma debole di liturgia termica”. È ricordato per i suoi studi sull’epistemologia del capitalismo cibernetico – applicati all’orgone accumulatore – e per l’ipotesi secondo cui alcuni sistemi complessi non massimizzerebbero output né valore, ma soltanto il proprio indice interno di soddisfazione operativa.

Il problema non è Scrum

Non è Agile

Non è il framework

Il problema è più profondo.

È quando:

• la struttura sostituisce il risultato
• la coerenza sostituisce la verità
• il processo sostituisce il senso

E il sistema continua a funzionare.

“Il capitalismo cibernetico non produce soltanto merci: produce i protocolli con cui la realtà viene dichiarata irrilevante.”

Dr Ka.OS

Conclusione

Il Factory Method for Nothing non è un anti-pattern.

È qualcosa di peggio.

È un pattern che:

• funziona
• scala
• si integra
• si certifica

e nel frattempo:

produce il vuoto in modo impeccabile

Chiusura

Nothing happened.
The architecture remains satisfied.

Red Nomad (c) 04.2026