Design del Factory Pattern: una guida agli oggetti disaccoppiati

Il factory pattern è un design pattern creazionale che केंदralizza la logica di istanziazione degli oggetti. Invece di creare direttamente gli oggetti usando l’operatore new dove servono, il codice client chiama un metodo dedicato di “factory”, che gestisce il processo di istanziazione. Questo potrebbe sembrare un livello di astrazione non necessario, ma è fondamentale per costruire software flessibile e manutenibile, disaccoppiando il codice client dalle classi concrete che utilizza.

Il problema: accoppiamento stretto dovuto all’istanziazione diretta

In molti sistemi software, l’operatore new all’inizio sembra innocuo. Con il tempo, però, il suo uso diretto diventa una fonte significativa di rigidità e debito tecnico. Ogni volta che il tuo codice istanzia direttamente un oggetto—per esempio, new MySQLConnector()—crea una dipendenza codificata in modo rigido. Questo forte accoppiamento tra il client e l’implementazione concreta può ostacolare seriamente l’evoluzione di un sistema.

Per applicazioni semplici con un insieme stabile di requisiti, questo approccio diretto può essere sufficiente. Ma con l’aumentare della complessità, il design diventa fragile. Considera una piattaforma SaaS che inizialmente supporta un solo provider di archiviazione file. La logica di business è probabilmente piena di new AWSS3Storage(). Cosa succede quando i requisiti di business cambiano e devi aggiungere il supporto per Azure Blob Storage o Google Cloud Storage?

Il costo di business di un’architettura rigida

Senza un’astrazione per la creazione degli oggetti, ogni nuova integrazione richiede agli sviluppatori di individuare e modificare ogni punto in cui viene istanziato un oggetto di storage. Questo processo non è solo noioso; è un’attività ad alto rischio che spesso introduce regressioni.

Questa istanziazione diretta impone costi di business tangibili:

• Time-to-market più lento: aggiungere un nuovo provider si trasforma in un importante progetto di refactoring invece che in un’attività circoscritta e prevedibile.
• Maggiore rischio di bug: modificare codice esistente e funzionante per adattarlo a nuovi tipi è una delle principali cause di regressioni. Il sistema viola il Principio Open/Closed, poiché non può essere esteso senza essere modificato.
• Design di sistema inflessibile: la codebase resiste attivamente al cambiamento. Un requisito di business semplice, come fare A/B testing di due servizi di reporting diversi, diventa una sfida architetturale perché la logica è saldata a implementazioni specifiche.

Un’architettura che non può adattarsi a nuovi requisiti è un’architettura che sta fallendo il business. Il costo della rigidità si paga in funzionalità ritardate, frustrazione degli sviluppatori e opportunità perdute.

Per costruire sistemi resilienti, è fondamentale separare il cosa dal come. Il codice client dovrebbe specificare cosa gli serve—un oggetto in grado di archiviare un file—ma non dovrebbe essere responsabile di come quell’oggetto viene costruito. Il factory pattern offre una soluzione strutturata a questo problema incapsulando la logica di creazione, consentendo al resto dell’applicazione di rimanere agile e adattabile.

Simple Factory vs. Factory Method: selezionare l’astrazione appropriata

Una volta presa la decisione di centralizzare la creazione degli oggetti, la domanda diventa come implementarla. I due approcci più comuni sono i pattern Simple Factory e Factory Method. Ognuno offre un diverso compromesso tra semplicità di implementazione ed estensibilità a lungo termine. La scelta è strategica e influisce su come il sistema evolverà.

Come illustra il diagramma, implementare una factory è una decisione architetturale deliberata. Introduce struttura e prevedibilità nella creazione degli oggetti, consentendo a un sistema di scalare senza collassare sotto il peso della propria complessità.

La Simple Factory: un hub centralizzato di creazione

La Simple Factory è un idiom comune e pragmatico, anche se non è uno dei design pattern originali della “Gang of Four”. In genere consiste in una singola classe con un metodo che restituisce una delle varie possibili classi di oggetti.

La sua funzione principale è astrarre la parola chiave new e qualsiasi logica di configurazione associata. Il client chiama il metodo della factory, passa un identificatore (come una stringa o un enum) e riceve un oggetto che aderisce a una common interface. Il client resta all’oscuro della classe concreta che è stata istanziata.

Questo approccio offre vantaggi immediati:

• Disaccoppiamento: il codice client non è più vincolato a classi concrete come PDFDocument. Dipende solo dalla factory e dall’astratta interfaccia Document.
• Centralizzazione: tutta la logica di creazione è consolidata in un unico punto. Per aggiungere un tipo WordDocument, devi modificare solo la factory, non i numerosi punti in cui i documenti potrebbero essere creati.
• Semplicità: il pattern è semplice da implementare e da comprendere, rendendolo un primo passo efficace per allontanarsi da chiamate new sparse nel codice.

Tuttavia, la Simple Factory ha un significativo svantaggio architetturale. Ogni volta che viene aggiunto un nuovo tipo di prodotto, la classe factory centrale deve essere modificata, in genere aggiungendo un altro ramo a una istruzione switch o if-else. Questo viola il Principio Open/Closed, che afferma che le entità software dovrebbero essere aperte all’estensione ma chiuse alla modifica. Per sistemi di grandi dimensioni o in rapida evoluzione, questo può diventare un collo di bottiglia per la manutenzione.

Il Factory Method: un modello per l’estensibilità

Il pattern Factory Method affronta la violazione del Principio Open/Closed insita nella Simple Factory. Lo fa delegando la decisione di istanziazione alle sottoclassi.

Invece di un singolo metodo statico onnisciente, il pattern Factory Method definisce un’interfaccia per creare un oggetto ma lascia che le sottoclassi alterino il tipo di oggetti che verranno creati. Una classe creator contiene la logica di business che si basa su un oggetto creato da un “factory method”. La classe creator non implementa essa stessa questo metodo; tale responsabilità viene rimandata alle sue sottoclassi.

Il pattern Factory Method fornisce un potente punto di aggancio architetturale. Consente a un sistema centrale o a un framework di definire lo scheletro di un algoritmo, permettendo al codice client o ai plugin di fornire gli oggetti specifici richiesti a runtime.

Considera un framework per l’elaborazione di feed di dati. Una classe base DataProcessor potrebbe definire un metodo process() che orchestra un flusso di lavoro. Questo metodo ha bisogno di un DataReader per recuperare i dati, ma non dovrebbe essere codificato in modo rigido su un’implementazione specifica come XMLReader o JSONReader.

Per risolvere questo problema, la classe DataProcessor dichiarerebbe un metodo factory astratto, createReader(). Sottoclassi concrete, come XMLDataProcessor e JSONDataProcessor, fornirebbero poi le proprie implementazioni di createReader(), restituendo rispettivamente un’istanza XMLReader o JSONReader. La logica centrale process() nella classe base rimane invariata; si limita a chiamare createReader() e a operare sull’oggetto DataReader che riceve.

Confronto pratico: Simple Factory vs. Factory Method

La Simple Factory è un eccellente punto di partenza per rifattorizzare la logica di creazione degli oggetti. Tuttavia, per sistemi progettati per crescere—come una piattaforma SaaS in cui nuove integrazioni fanno parte della roadmap di business—il Factory Method fornisce una base più robusta e scalabile.

Esempi di implementazione pronti per la produzione

Traduciamo il factory pattern in codice pronto per la produzione. Implementeremo una soluzione per un requisito comune del software B2B: generare diversi tipi di report di conformità, come quelli per GDPR, SOX e HIPAA. Ogni report ha requisiti di dati e regole di formattazione unici, ma il codice client che li richiede non dovrebbe occuparsi di questi dettagli di implementazione.

I seguenti esempi in Python, Java e TypeScript dimostrano come il client rimanga disaccoppiato dalle classi concrete dei report.

Componenti fondamentali del pattern

L’implementazione coinvolge quattro ruoli chiave:

1. Interfaccia Product (Report): un’interfaccia o una classe astratta che definisce i metodi comuni che tutti i prodotti concreti devono implementare. Questo garantisce che il client possa trattare uniformemente tutti gli oggetti prodotto.
2. Prodotti concreti (GDPRReport, SOXReport): le classi effettive istanziate dalla factory. Ognuna implementa l’interfaccia Product ma contiene logica specifica.
3. La Factory (ReportFactory): la classe che contiene la logica di creazione. Determina quale prodotto concreto istanziare in base alla richiesta del client.
4. Il Client: la parte dell’applicazione che necessita di un oggetto prodotto. Richiede un oggetto alla factory e lo usa tramite l’interfaccia Product, senza conoscere il suo tipo concreto.

Implementazione in Python

La natura dinamica di Python e le classi base astratte (ABC) si prestano a un’implementazione pulita e semplice del pattern.

from abc import ABC, abstractmethod

# 1. The Product Interface
class Report(ABC):
    @abstractmethod
    def generate(self) -> str:
        """Generates the report content."""
        pass

# 2. Concrete Products
class GDPRReport(Report):
    def generate(self) -> str:
        print("Generating GDPR data privacy report...")
        # Complex logic for GDPR report generation goes here
        return "GDPR Report Content"

class SOXReport(Report):
    def generate(self) -> str:
        print("Generating SOX financial compliance report...")
        # Complex logic for SOX report generation goes here
        return "SOX Report Content"

# 3. The Simple Factory
class ReportFactory:
    @staticmethod
    def create_report(report_type: str) -> Report:
        if report_type == 'GDPR':
            return GDPRReport()
        elif report_type == 'SOX':
            return SOXReport()
        else:
            raise ValueError(f"Report type '{report_type}' not supported.")

# 4. The Client Code
if __name__ == "__main__":
    report_type_needed = "GDPR"
    
    # Client requests a report without knowing the concrete class
    compliance_report = ReportFactory.create_report(report_type_needed)

    # Client uses the object through the common interface
    content = compliance_report.generate()
    print(f"Received: {content}")

Nota che il codice client è completamente isolato dalle classi GDPRReport e SOXReport. Se in futuro sarà necessario un HIPAAReport, il codice client rimane invariato. Solo ReportFactory richiede una modifica.

Implementazione in Java

Nelle linguaggi fortemente tipizzati come Java, il Factory Pattern fornisce una struttura robusta e prevedibile, particolarmente adatta alle applicazioni enterprise.

// 1. The Product Interface
public interface Report {
    String generate();
}

// 2. Concrete Products
public class GDPRReport implements Report {
    @Override
    public String generate() {
        System.out.println("Generating GDPR data privacy report...");
        // Logic for GDPR report
        return "GDPR Report Content";
    }
}

public class SOXReport implements Report {
    @Override
    public String generate() {
        System.out.println("Generating SOX financial compliance report...");
        // Logic for SOX report
        return "SOX Report Content";
    }
}

// 3. The Simple Factory
public class ReportFactory {
    public static Report createReport(String reportType) {
        if ("GDPR".equalsIgnoreCase(reportType)) {
            return new GDPRReport();
        } else if ("SOX".equalsIgnoreCase(reportType)) {
            return new SOXReport();
        }
        throw new IllegalArgumentException("Unknown report type: " + reportType);
    }
}

// 4. The Client Code
public class ComplianceService {
    public static void main(String[] args) {
        String requiredReport = "SOX";

        // The client asks the factory for a report
        Report report = ReportFactory.createReport(requiredReport);

        // The client uses the report via the interface
        String content = report.generate();
        System.out.println("Received: " + content);
    }
}

Il client ComplianceService dipende solo dall’interfaccia Report e da ReportFactory. Questa separazione pulita è fondamentale per costruire applicazioni Java su larga scala e manutenibili.

Implementazione TypeScript

La tipizzazione statica di TypeScript aggiunge sicurezza a JavaScript, rendendolo una scelta eccellente per implementare pattern di progettazione nelle applicazioni moderne.

// 1. The Product Interface
interface Report {
    generate(): string;
}

// 2. Concrete Products
class GDPRReport implements Report {
    public generate(): string {
        console.log('Generating GDPR data privacy report...');
        // Logic for GDPR report
        return 'GDPR Report Content';
    }
}

class SOXReport implements Report {
    public generate(): string {
        console.log('Generating SOX financial compliance report...');
        // Logic for SOX report
        return 'SOX Report Content';
    }
}

// 3. The Simple Factory
type ReportType = 'GDPR' | 'SOX';

class ReportFactory {
    public static createReport(type: ReportType): Report {
        switch (type) {
            case 'GDPR':
                return new GDPRReport();
            case 'SOX':
                return new SOXReport();
            default:
                // This case is unreachable if using the ReportType union type
                throw new Error('Invalid report type specified.');
        }
    }
}

// 4. The Client Code
function runComplianceCheck(reportType: ReportType) {
    // The client gets a report object from the factory
    const report: Report = ReportFactory.createReport(reportType);

    // The client uses the object without knowing its concrete class
    const content = report.generate();
    console.log(`Received: ${content}`);
}

runComplianceCheck('SOX');

L’uso di un tipo union (ReportType) offre sicurezza in fase di compilazione, prevenendo una classe di errori a runtime. Questa chiara separazione delle responsabilità semplifica l’integrazione con i flussi di lavoro di test automatizzati e di deployment, un argomento che trattiamo nella nostra guida alle pipeline CI/CD.

Casi d’uso e compromessi

Un design pattern è uno strumento, non un obbligo. Applicare il design pattern factory in modo indiscriminato porta a un over-engineering. La chiave è riconoscere quando l’astrazione risolve un problema reale. Il valore del pattern sta nel gestire la complessità e nell’adattarsi ai cambiamenti futuri separando il client dai dettagli della creazione degli oggetti.

Scenari in cui una Factory eccelle

Il factory pattern è giustificato quando un sistema presenta caratteristiche o requisiti specifici:

• Selezione di oggetti a runtime: il tipo esatto di oggetto necessario non è noto in fase di compilazione e dipende da condizioni a runtime, come l’input dell’utente, un file di configurazione o lo stato del sistema. Un esempio comune è la selezione di un gateway di pagamento (Stripe, PayPal) in base alla posizione geografica dell’utente.
• Supporto per componenti plug-in: il sistema deve supportare componenti intercambiabili. Questo è comune per connettori di database (PostgreSQL, MongoDB), integrazioni con API esterne o servizi di logging. Una factory consente di sostituire questi componenti senza modificare la logica di business principale.
• Logica di creazione complessa: l’istanziazione degli oggetti è più articolata di una semplice chiamata new. Se la creazione richiede più passaggi, recupero di dipendenze o configurazioni complesse, incapsulare questa logica all’interno di una factory semplifica il codice del client.

I principi alla base del factory pattern sono ben consolidati. Uno studio interno sui codebase di produzione presso diverse aziende tecnologiche ha rivelato che i team che utilizzano pattern creazionali come il Factory Method hanno riportato una significativa riduzione del tempo speso a rifattorizzare la logica di istanziazione degli oggetti quando aggiungevano nuove varianti di prodotto. Scopri come il factory method semplifica la creazione degli oggetti con questa risorsa di Curate Partners.

Quando evitare l’uso di una Factory

Al contrario, introdurre una factory quando non serve aggiunge complessità inutile, tra cui classi extra, livelli di indirezione e sovraccarico cognitivo per il team di sviluppo.

Evita di usare una factory in questi casi:

• Applicazioni semplici e stabili: in una piccola applicazione con un set fisso di tipi di oggetti che difficilmente cambierà, l’istanziazione diretta è più semplice e più appropriata.
• Singola classe concreta: lo scopo di una factory è gestire la creazione di più tipi di oggetti correlati. Se esiste una sola implementazione concreta, una factory non aggiunge valore.
• Percorsi critici per le prestazioni: sebbene l’impatto sulle prestazioni sia trascurabile nella maggior parte delle applicazioni business, una factory introduce una chiamata di metodo aggiuntiva. In scenari estremi ad altissime prestazioni che coinvolgono la creazione di milioni di oggetti al secondo, questo sovraccarico marginale potrebbe teoricamente essere un fattore.

L’obiettivo è risolvere problemi reali, non crearne di nuovi. Una factory dovrebbe ridurre la complessità nel lungo periodo; se aggiunge complessità solo nel breve termine senza un chiaro beneficio futuro, è lo strumento sbagliato.

Scegliere di usare un design pattern factory è una decisione architetturale. Per i sistemi in cui la flessibilità è una priorità strategica, come una Service-Oriented Architecture (SOA), è spesso una necessità. Rappresenta un compromesso: un piccolo investimento iniziale in astrazione in cambio del significativo vantaggio a lungo termine di un sistema più manutenibile ed estensibile.

Factory nei moderni framework di Dependency Injection

Framework applicativi moderni come Spring, .NET e NestJS includono sofisticati container di Dependency Injection (DI) che gestiscono il ciclo di vita degli oggetti. Questo solleva una domanda legittima: il factory pattern è ancora rilevante?

La risposta è sì. Il ruolo del design pattern factory si è evoluto. I container DI possono essere visti come factory altamente avanzate e configurabili. Automatizzano il processo di creazione e collegamento dei componenti dell’applicazione in base a una configurazione dichiarativa. Quando un OrderService richiede un IPaymentGateway, il container DI agisce come una factory principale, istanziando l’implementazione corretta e iniettandola automaticamente, promuovendo così un basso accoppiamento su scala applicativa.

Il ruolo duraturo delle factory personalizzate

Se i container DI sono “super-factory”, perché abbiamo ancora bisogno di factory personalizzate? Le factory personalizzate restano essenziali negli scenari in cui la logica di creazione è troppo complessa per una configurazione DI dichiarativa.

Considera questi casi d’uso comuni in un prodotto SaaS:

• Selezione dinamica della strategia: un’applicazione deve selezionare un provider di spedizione (FedEx, UPS) in base al peso del pacco, alla destinazione e al livello di abbonamento del cliente. Questa logica di business è meglio incapsulata in un ShippingProviderFactory, non in una configurazione DI statica.
• Creazione con parametri a runtime: alcuni oggetti richiedono dati disponibili solo a runtime, come l’ID di sessione di un utente o una chiave API specifica della richiesta. Una factory può accettare questi valori di runtime per costruire correttamente l’oggetto.
• Architetture multi-tenant: in un sistema multi-tenant, una TenantServiceFactory può esaminare il contesto della richiesta corrente per istanziare servizi (come una DatabaseConnection o un ThemeService) configurati specificamente per quel tenant.

In un’architettura gestita da DI, una factory personalizzata diventa un componente specializzato. Gestisce la logica di creazione dinamica per cui il container non è progettato, incapsulando tali decisioni in un’unità dedicata e testabile.

Migliorare testabilità e modularità

Combinare factory personalizzate con un container DI migliora anche in modo significativo la testabilità. Durante i test unitari, puoi configurare il container DI per iniettare una mock factory. Questa mock può quindi produrre oggetti fittizi preconfigurati, consentendoti di isolare il componente sotto test dalle sue dipendenze.

I benefici sono misurabili. Un’analisi di settore sui progetti enterprise ha mostrato che i team che applicano il Factory Method pattern registrano una riduzione dei bug legati alla gestione del ciclo di vita degli oggetti. Un uso corretto del pattern migliora anche l’aderenza al principio di responsabilità singola centralizzando la logica di creazione. Puoi saperne di più sul formale factory method pattern da fonti consolidate di informatica.

In definitiva, il factory pattern non viene sostituito dalla DI; viene completato da essa. Il container DI gestisce il wiring di alto livello dell’applicazione, mentre le factory personalizzate gestiscono la creazione sfumata, guidata dalla logica, necessaria per risolvere problemi di business specifici.

Conclusione: punti chiave per i leader tecnici

Il design pattern factory è una scelta architetturale strategica, non semplicemente un concetto accademico. La sua adozione indica l’impegno verso la salute del sistema nel lungo periodo più che verso la comodità di implementazione nel breve termine. È uno strumento fondamentale per costruire software in grado di evolvere insieme alle esigenze di business. Il principio centrale è separare il cosa (l’oggetto necessario) dal come (i dettagli della sua creazione).

Dare priorità a manutenibilità ed estensibilità

L’obiettivo principale di un leader tecnico dovrebbe essere guidare i team verso la costruzione di sistemi facili da modificare. Centralizzando la creazione degli oggetti, il factory pattern stabilisce un punto unico e prevedibile per le modifiche. Quando è necessario aggiungere un nuovo provider di pagamento o una nuova fonte dati, la modifica rimane confinata nella factory, non dispersa nel codebase.

Questa isolazione offre un valore aziendale concreto:

• Sviluppo delle funzionalità accelerato: le nuove integrazioni diventano più prevedibili, riducendo il tempo necessario per rilasciare nuove capacità.
• Rischio ridotto di regressioni: la logica di business principale rimane intatta, abbassando drasticamente il rischio di introdurre bug nel codice stabile.
• Onboarding semplificato: i nuovi sviluppatori possono diventare operativi più rapidamente, poiché la logica di creazione si trova dove ci si aspetta che sia.

Un’architettura intenzionale, guidata da pattern collaudati come la factory, è ciò che distingue una codebase rigida che resiste al cambiamento da una piattaforma flessibile che lo consente.

Promuovere una cultura dell’architettura intenzionale

Incoraggia i tuoi team a pensare oltre il compito immediato. Promuovi discussioni architetturali che valutino i compromessi tra semplicità a breve termine e flessibilità a lungo termine. Il pattern factory è un ottimo esempio di questo principio in azione. Rappresenta un piccolo investimento iniziale nell’astrazione che genera rendimenti significativi lungo l’intero ciclo di vita del software. Questo approccio orientato al futuro è un pilastro di metodologie di sviluppo robuste come il modello V del software development.

Questa disciplina è ciò che separa il codice usa e getta da un vero asset aziendale.

Domande frequenti

Qual è la differenza tra una Factory e una Abstract Factory?

La differenza principale è l’ambito. Un Factory Method viene usato per creare un tipo di prodotto. Un’Abstract Factory viene usata per creare famiglie di prodotti correlati.

Per esempio, una NotificationFactory (Factory Method) potrebbe avere un metodo che restituisce diversi tipi di oggetti di notifica, come EmailNotification o SmsNotification. Il suo focus è singolo: creare notifiche.

Al contrario, una AlertingSystemFactory (Abstract Factory) è una “factory di factory”. Avrebbe metodi come createNotification(), createLogger() e createMetricsTracker(). Potresti quindi avere implementazioni diverse, come una CriticalAlertingFactory e una InfoAlertingFactory, in cui ciascuna garantisce che tutti i componenti che produce siano progettati per funzionare insieme all’interno di un contesto specifico.

L’uso di un pattern factory penalizza le prestazioni?

Per la stragrande maggioranza delle applicazioni, l’impatto sulle prestazioni è trascurabile. L’overhead tipicamente equivale a una singola chiamata di metodo extra, insignificante rispetto ai vantaggi architetturali di disaccoppiamento e manutenibilità.

Le prestazioni dovrebbero diventare una preoccupazione solo se stai istanziando milioni di oggetti al secondo in un “hot path” estremamente sensibile alle prestazioni. In quasi tutti gli altri casi, i vantaggi in termini di chiarezza e flessibilità superano di gran lunga il costo prestazionale minimo.

Il vero killer delle prestazioni nel software non è una singola chiamata di metodo; è un’architettura rigida e fortemente accoppiata che rende lo sviluppo lento e l’adattamento al cambiamento proibitivamente costoso.

Il pattern factory può essere usato nella programmazione funzionale?

Sì. Sebbene il pattern abbia avuto origine nella programmazione orientata agli oggetti, il suo principio fondamentale—separare la creazione dall’uso—è universale. In un paradigma funzionale, una factory non è una classe ma una funzione di ordine superiore. Questa funzione accetterebbe come argomento una configurazione o un identificatore di tipo e restituirebbe una nuova funzione o una struttura dati adattata a un compito specifico. L’obiettivo resta identico: nascondere i dettagli di implementazione al codice client.

Una Simple Factory è considerata un pattern di design “vero”?

Sebbene la Simple Factory non faccia parte degli originali 23 pattern di design del “Gang of Four” (GoF), è un idiom di programmazione ampiamente riconosciuto e molto utile. Può essere vista come un punto di ingresso pragmatico verso i pattern creazionali più formali. La sua semplicità è il suo punto di forza, offrendo un disaccoppiamento significativo a fronte di un basso costo di implementazione. Si è guadagnata un posto nel toolkit di uno sviluppatore grazie alla sua utilità comprovata nel risolvere in modo efficace i comuni problemi di progettazione.

At Devisia, crediamo che un’architettura intenzionale sia la chiave per costruire software destinato a durare. Sfruttando pattern collaudati, aiutiamo le aziende a creare prodotti digitali scalabili, manutenibili e affidabili, oltre a sistemi abilitati all’AI. Scopri di più sul nostro approccio su https://www.devisia.pro.