Per decenni la Gang of Four (GoF) è stata il testo sacro dell'ingegneria del software. Imparare i design pattern era un rito di passaggio: una checklist rigida (Singleton, Factory, Strategy, Observer...) applicata con la cieca fiducia che, accumulando astrazioni, l'architettura sarebbe diventata magicamente "pulita, disaccoppiata e scalabile".
Nel 2026, il panorama tecnologico ha imposto una drastica inversione di rotta. L'ecosistema .NET (maturato attraverso le ultime evoluzioni di .NET 9 e 10), la diffusione pervasiva del cloud-native, i vincoli della compilazione Native AOT (Ahead-Of-Time) e la necessità di ridurre il carico cognitivo hanno ridefinito il valore di questi pattern.
Alcuni sono stati assorbiti dal linguaggio e dal runtime; altri si sono evoluti in costrutti infrastrutturali; altri ancora sono oggi considerati veri e propri anti-pattern. Non è l'architettura a essere morta, ma il culto dogmatico dei pattern.
Ecco un'analisi profonda e senza filtri su cosa conta davvero oggi nello sviluppo C#.
1. Dependency Injection: Da Pattern a Infrastruttura Invisibile
La Dependency Injection (DI) non può più essere considerata un semplice design pattern applicativo: oggi è il framework mentale su cui poggia l'intero runtime di .NET.
Cosa è cambiato nel 2026
Con il consolidamento del container DI nativo di Microsoft (e l'introduzione di feature avanzate come i Keyed Services), non spendiamo più tempo a scrivere Service Locator o factory di registrazione custom. La DI è ovunque: dalle Minimal APIs alle funzioni Serverless, fino ai Worker Service isolati.
Il vero valore oggi
Il focus si è spostato dall'astrazione fine a se stessa (creare interfacce IService per ogni singola classe) alla gestione millimetrica dei lifetime (Transient, Scoped, Singleton) e dei confini di isolamento. Nel mondo cloud-native, un errore nella gestione del ciclo di vita (come una dipendenza Captive, dove un Singleton cattura un servizio Scoped) si traduce direttamente in memory leak o data corruption sotto carico.
2. Factory: Piccole, Esplicite e Legate al Dominio
Il passato era dominato dalle AbstractFactory e da gerarchie di classi create solo per istanziare altre classi. Un'eredità del mondo Java dei primi anni 2000 che in C# ha perso quasi totalmente senso.
La realtà odierna
Le uniche Factory sopravvissute con dignità sono quelle che incapsulano una reale complessità di business o di configurazione. Oggi si sfruttano ampiamente le espressioni lambda, i delegati (Func<T>) o i costruttori primari combinati con i Keyed Services:
C#
L'obiettivo moderno è la trasparenza: la Factory deve essere un servitore del dominio, non un labirinto di interfacce vuote.
3. Strategy: Il Pattern che Invecchia Meglio (Grazie al Pattern Matching)
Se c'è un pattern GoF che non ha risentito del peso degli anni, è lo Strategy. È il pilastro fondamentale per mantenere il codice conforme all'Open/Closed Principle.
L'evoluzione in C#
In passato, implementare lo Strategy significava creare un'interfaccia e dieci classi diverse, appesantendo la codebase. Nel C# moderno, lo Strategy si è fuso con le potenzialità del Pattern Matching avanzato, dei record e delle funzioni di ordine superiore (passaggio di delegati).
Se la logica della strategia è ad alta intensità di calcolo o richiede dipendenze complesse, la struttura a classi separate è ancora l'ideale. Se invece si tratta di variazioni algoritmiche leggere (es. calcolo delle tasse in base alla nazione), gli switch expressions basati su pattern matching offrono una pulizia e una velocità di lettura imbattibili, riducendo drasticamente il numero di file nel progetto.
4. Decorator: Il Re dei Cross-Cutting Concerns
Come gestiamo logging, caching, telemetria, auditing e logiche di retry senza inquinare i servizi di business? La risposta nel 2026 è, inequivocabilmente, il Decorator.
Performance e AOT
In passato, l'approccio alternativo al Decorator era la programmazione orientata agli aspetti (AOP) basata sulla riflessione a runtime o sulla generazione dinamica di proxy (come Castle Core). Nel 2026, con la spinta massiccia verso Native AOT per ridurre i tempi di avvio dei container e l'uso di memoria, la riflessione pesante è un tabù.
Il Decorator, applicato in modo pulito tramite registrazione nativa nel container DI (magari supportato da librerie come Scrutor o tramite Source Generators), permette di stratificare il comportamento in modo statico, sicuro e a costo prestazionale quasi zero.
5. Singleton: Quasi Morto (Indossando una Veste Gestita)
"Il Singleton scritto a mano è l'equivalente architettonico di una variabile globale che indossa un tuxedo."
Perché evitarlo a mano
La classica implementazione con istanza statica privata, costruttore privato e proprietà Instance (magari con doppio controllo di lock per il thread-safety) è un dinosauro del passato. Rende il codice non testabile, crea accoppiamento rigido e nasconde le dipendenze.
Come vive nel 2026
Il concetto di istanza singola vive ancora, ma la sua responsabilità è interamente delegata al container di Dependency Injection (builder.Services.AddSingleton<T>). La classe stessa rimane una classe normale, aperta, testabile e priva di logica di auto-istanziamento. Inoltre, in architetture cloud ad alta scalabilità orizzontale, lo stato globale in memoria è un rischio: tutto ciò che è Singleton deve essere rigorosamente stateless.
6. Observer: Scomparso dal Codice, Vivo nell'Infrastruttura
Nessuno scrive più interfacce ISubject e IObserver a mano. Il pattern Observer si è verticalizzato e spostato a livelli diversi della catena di sviluppo.
- A livello di linguaggio: È stato integrato da anni tramite eventi e delegati, ed evoluto con i reactive streams (
IObservable<T>/ Reactive Extensions), sebbene usati in nicchie specifiche come UI complesse o elaborazione di stream di dati in tempo reale. - A livello architetturale: Si è trasformato nell'Event-Driven Architecture (EDA). Gli "Observer" oggi sono microservizi indipendenti che ascoltano messaggi su broker come Kafka, RabbitMQ o Azure Service Bus. Nel codice applicativo, usiamo astrazioni asincrone come i
System.Threading.Channelsper gestire scenari produttore-consumatore ad altissime prestazioni in-memory.
7. Command & Mediator: Lo Standard per le API Moderne
Nelle architetture web del 2026, l'accoppiata Command (incapsulare una richiesta) e Mediator (disaccoppiare chi invia da chi esegue) rappresenta lo standard de facto, spesso trainato da librerie storiche come MediatR o da implementazioni custom basate su Source Generators.
La spinta della Vertical Slice Architecture
I vecchi controller monolitici e le architetture rigidamente stratificate "a cipolla" o "esagonali" rigide hanno lasciato spazio alla Vertical Slice Architecture. Invece di organizzare il codice per filtri tecnici (tutti i controller insieme, tutti i servizi insieme), lo si organizza per funzionalità (Feature).
Ogni feature è un blocco atomico composto da:
- Un Command o una Query (un record immutabile).
- Un Handler isolato che contiene l'unica logica di business per quella richiesta.
- Una pipeline di sbarramento (Validation, Logging, Transazionalità) gestita dal Mediator.
Questo riduce drasticamente i conflitti di merge e rende il codice incredibilmente manutenibile.
8. Adapter: La Cintura di Sicurezza dell'Integrazione
Il mondo esterno è caotico. Le API di terze parti cambiano, gli SDK legacy ereditati da vecchi sistemi non seguono i nostri standard di design e i modelli dati esterni sono spesso ridondanti o incoerenti con il nostro dominio.
L'Adapter (o Anti-Corruption Layer nella terminologia Domain-Driven Design) resta uno strumento di igiene architetturale indispensabile. Isolare l'impurità dei sistemi esterni dietro un'interfaccia proprietaria e un adapter pulito è ciò che separa un sistema resiliente da uno destinato a crollare al primo aggiornamento di un pacchetto NuGet esterno. Nel 2026, questi mapping vengono spesso accelerati da source generator di mapping (come Mapperly) per garantire zero allocazioni e performance Native AOT.
9. Template Method: Sconfitto dalla Composizione
Il Template Method si basa sull'ereditarietà: una classe base definisce lo scheletro di un algoritmo e lascia alle classi derivate il compito di sovrascrivere determinati passaggi tramite metodi astratti o virtuali.
Perché ha perso popolarità
L'ereditarietà rigida ha mostrato tutti i suoi limiti strutturali negli anni. Tende a creare gerarchie fragili, dove una modifica alla classe base rischia di rompere comportamenti inattesi nelle derivate (il classico problema della classe base fragile).
Nel 2026 la regola d'oro è: "Composition over Inheritance" (Composizione sopra l'ereditarietà). Lo scheletro dell'algoritmo viene definito in una classe standard che accetta le variazioni dei singoli passaggi non tramite ereditarietà, ma ricevendo interfacce strategiche, delegati (Func<T>) o definendo una pipeline di funzioni asincrone concatenabili.
10. Repository: Una Relazione Complicata con EF Core
Il pattern Repository merita una riflessione profonda, poiché è l'epicentro di accesi dibattiti nelle community .NET.
Il grande malinteso
Creare un GenericRepository<T> che espone metodi come IQueryable<T> GetAll() è, nel 2026, un acclamato anti-pattern. Entity Framework Core è già, intrinsecamente, un'implementazione del pattern Repository (tramite DbSet) e del pattern Unit of Work (tramite DbContext). Creare un wrapper generico sopra di esso significa solo nascondere funzionalità cruciali (come il tracking, il caricamento esplicito delle relazioni o le performance delle query compilate) senza offrire alcun reale vantaggio.
Quando ha senso
Il Repository è vivo e utile solo se applicato secondo i canoni del Domain-Driven Design (DDD):
- È specifico per un Aggregate Root (non un repository per ogni singola tabella del database).
- Non espone
IQueryable, ma restituisce oggetti di dominio (Entity/Record) completamente idratati e pronti a eseguire logiche di business. - Nasconde completamente i dettagli di persistenza, agendo come una collezione in-memory di oggetti di dominio.
Riepilogo Architetturale per il 2026
| Pattern | Stato nel 2026 | Sostituto / Evoluzione Moderna |
| Dependency Injection | 🌟 Essenziale | Integrato nativamente nel runtime di .NET. |
| Strategy | 🌟 Eccellente | Ottimizzato tramite Pattern Matching e Switch Expressions. |
| Command / Mediator | 🌟 Standard | Spina dorsale delle Vertical Slice Architectures e delle Minimal APIs. |
| Decorator | 🌟 Eccellente | Fondamentale per i cross-cutting concerns, specialmente in ottica Native AOT. |
| Adapter | 🚀 Utile | Utilizzato come Anti-Corruption Layer nei confini di sistema. |
| Factory | ⚠️ Condizionato | Solo se esplicito e snello; spesso integrato con i Keyed Services. |
| Repository | ⚠️ Condizionato | Solo se specifico per Aggregate Roots; da evitare se è un wrapper generico di EF Core. |
| Observer | 🔄 Trasformato | Evoluto in Event-Driven Architectures e messaggistica asincrona cloud. |
| Singleton | ❌ Superato | Gestito esclusivamente come lifetime del container DI. |
| Template Method | ❌ Deprecato | Sostituito dalla composizione di funzioni e pipeline basate su delegati. |
Conclusione: Meno Dogma, Più Intento
La linea di demarcazione tra un software di successo e un fallimento architetturale nel 2026 non è determinata da quanti pattern GoF sono stati implementati. È determinata dalla capacità del codice di ridurre la complessità non lineare, rendere esplicito l'intento del business e permettere al team di rilasciare valore in produzione in sicurezza e ad alte prestazioni.
I pattern non sono regole scolpite nella pietra; sono soluzioni storiche a problemi comuni. Se l'evoluzione del linguaggio e delle infrastrutture offre una via più semplice, lineare e performante per risolvere lo stesso problema, abbandonare il vecchio pattern non è un peccato di design: è pragmatismo ingegneristico. E nel 2026, il pragmatismo vince sempre sulla nostalgia.
Commenti (0)
Nessun commento ancora.
