DEV Community: Dev-Iadicola

Factory Method: creare senza conoscere

Dev-Iadicola — Tue, 11 Aug 2026 17:00:12 +0000

new e una dipendenza concreta

Ogni volta che scrivi new MysqlSchemaBuilder(), stai creando una dipendenza concreta. Il codice chiamante ora sa esattamente quale classe istanziare — e se domani devi supportare PostgreSQL, devi trovare e modificare ogni punto dove quel new compare. Il Factory Method risolve questo problema delegando la creazione a un metodo che le sottoclassi possono sovrascrivere, o che una logica interna può personalizzare in base al contesto.

Il pattern e sottilmente diverso dall'Abstract Factory: non crea famiglie di oggetti correlati, ma singoli oggetti il cui tipo concreto dipende dal contesto. In Soft PHP MVC, SchemaBuilder::make() ispeziona il driver configurato e restituisce il builder corretto — MysqlSchemaBuilder, PostgresSchemaBuilder, SqliteSchemaBuilder, MariaDbBuilder — senza che il chiamante debba saperlo. La decisione e centralizzata in un unico punto, non dispersa nel codice applicativo.

Cos'e il Factory Method: definizione e struttura

Il Gang of Four definisce il Factory Method come un pattern creazionale che "definisce un'interfaccia per creare un oggetto, ma lascia alle sottoclassi la decisione su quale classe istanziare. Il Factory Method permette a una classe di rinviare l'istanziazione alle sottoclassi". Gli attori sono: il Creator (la classe con il metodo factory), il ConcreteCreator (la sottoclasse che decide il tipo concreto), il Product (l'interfaccia del prodotto), e il ConcreteProduct (l'implementazione specifica).

Il cuore del pattern e la separazione tra la logica di creazione e la logica di utilizzo. Chi usa l'oggetto non sa come e stato creato; chi lo crea non sa come verra usato. Questa separazione permette di cambiare le regole di creazione senza impattare il codice che usa l'oggetto — e viceversa. Il Dependency Inversion Principle nella sua applicazione più diretta alla creazione degli oggetti.

Il pattern make() nel framework

Il make() statico e il Factory Method adottato sistematicamente in Soft PHP MVC. CsrfService::make(), EncryptionService::make(), SessionService::make() — ogni service espone un metodo factory che incapsula la logica di creazione. Oggi alcuni restituiscono semplicemente new static(); domani potrebbero restituire un singleton, leggere una configurazione, o risolvere da un container. Il punto di creazione e uno solo, e può evolvere senza ripercussioni sul resto del codice.

La forza del Factory Method e nella promessa che fa al codice chiamante: "non ti preoccupare del come, dimmi solo cosa ti serve". SchemaBuilder::make() potrebbe creare l'oggetto con new, pescarlo da una cache, o costruirlo con dieci dipendenze — il chiamante non lo sa e non deve saperlo. Questa ignoranza deliberata e il cuore del disaccoppiamento. Il Factory Method non nasconde complessità — la isola in un punto dove può essere gestita senza contaminare il codice che consuma il prodotto.

Vantaggi concreti del pattern make()

L'adozione sistematica di make() nel framework porta vantaggi misurabili:

Punto di creazione unico — ogni modifica alla logica di istanziazione avviene in un solo metodo
Evoluzione senza breaking change — passare da new static() a singleton o pool richiede zero modifiche al codice chiamante
Naming semantico — make() comunica "sto creando un'istanza pronta all'uso", diverso da un costruttore generico
Testabilita — il factory method può essere sovrascritto in una sottoclasse di test per restituire mock o stub
Consistenza — ogni service si istanzia allo stesso modo, riducendo il carico cognitivo per chi legge il codice

Factory Method vs costruttore: una questione di nomi

Un costruttore non può avere un nome semantico. new Connection($config) non dice se stai creando una connessione nuova o riutilizzando una esistente. Connection::fromConfig($config) e Connection::forTesting() sono Factory Method con nomi che comunicano l'intento. Il nome e documentazione che il compilatore verifica — non può diventare obsoleto come un commento. Un factory method ben nominato e il miglior tipo di documentazione: preciso, verificabile, impossibile da ignorare.

In PHP, i named constructor — metodi statici che restituiscono new static(...) — sono la forma più idiomatica del Factory Method. Il framework ne usa diversi: Migration::table() per creare migrazioni, Seeder::table() per creare seeder, Column::make() per definire colonne. Ogni nome racconta cosa stai costruendo e perché. La proliferazione di named constructor non e un segno di over-engineering — e un segno di API che comunicano con chiarezza.

Factory Method e PHP 8.4

Le novità di PHP 8.4 rendono il Factory Method ancora più espressivo. Le property hooks permettono di validare i parametri nel momento dell'assegnazione, riducendo la logica nel costruttore. I tipi di intersezione permettono di restituire oggetti che soddisfano più interfacce contemporaneamente. E le closure di prima classe rendono possibile passare factory method come callable, abilitando pattern di lazy creation e deferred resolution che prima richiedevano classi dedicate.

Quando il factory e troppo

Non ogni new ha bisogno di un factory. Value object semplici, DTO, eccezioni — crearli direttamente e perfettamente legittimo. Il Factory Method serve quando: il tipo concreto può variare, la logica di creazione e complessa, o vuoi un punto di estensione per il futuro. Se la classe non cambiera mai e il costruttore ha zero o un parametro, new e la scelta giusta. L'over-engineering e un costo reale, non solo teorico.

Ecco una guida pratica per decidere:

Usa new — value object, DTO, eccezioni, classi con costruttore semplice e tipo fisso
Usa make() — service, repository, handler, classi con logica di creazione non banale
Usa named constructor — quando lo stesso tipo può essere creato da input diversi (fromArray, fromRequest, forTesting)
Usa Abstract Factory — quando devi creare famiglie di oggetti correlati che variano insieme

Il pragmatismo e la differenza tra conoscere i pattern e sapere quando applicarli. Un codebase dove ogni oggetto passa attraverso un factory e un codebase over-engineered. Un codebase dove i punti di creazione critici hanno un factory e il resto usa new e un codebase che bilancia flessibilita e semplicità — e quello e l'obiettivo di ogni architettura PHP ben progettata.

👉 Leggi l'articolo completo su iadicola.it

Quick note: Adapter Pattern nel mail service

Dev-Iadicola — Mon, 10 Aug 2026 17:00:15 +0000

Quando il provider cambia nome

sendinblue/api-v3-sdk e diventato getbrevo/brevo-php. Non un aggiornamento: un rebranding. Il namespace e passato da SendinBlue\Client a Brevo\Client. Senza un adapter, ogni punto del codice che usava l'SDK avrebbe dovuto cambiare — e in un'applicazione reale, quei punti possono essere decine. Un rebranding del vendor non dovrebbe mai causare un refactoring nel codice applicativo. Se lo causa, manca un livello di astrazione.

L'Adapter Pattern wrappa l'interfaccia di un componente esterno in un'interfaccia che il nostro codice conosce. MailService espone send() con i nostri tipi — MailMessage, MailRecipient — e traduce internamente verso l'SDK di Brevo. Il codice applicativo chiama MailService::make()->send($message) e non sa se sotto c'e Brevo, SendGrid, Mailgun o un file di log. L'adapter e il confine tra il nostro dominio e il mondo esterno.

Cos'e l'Adapter Pattern: definizione e varianti

Il Gang of Four definisce l'Adapter come un pattern strutturale che "converte l'interfaccia di una classe in un'altra interfaccia che il client si aspetta. L'Adapter permette a classi con interfacce incompatibili di collaborare". Esistono due varianti classiche: l'Object Adapter (usa la composizione, wrappando l'oggetto adattato) e il Class Adapter (usa l'ereditarieta multipla, non disponibile in PHP).

In PHP, la variante naturale e l'Object Adapter: la classe adapter ha una proprieta privata che contiene l'oggetto adattato, e i metodi dell'adapter delegano all'oggetto adattato dopo aver tradotto i parametri e i valori di ritorno. Il MailService di Soft PHP MVC e un Object Adapter puro: mantiene un'istanza del client Brevo come dipendenza interna e traduce ogni chiamata dal vocabolario del framework al vocabolario dell'SDK.

La struttura del MailService come adapter

Il MailService nel framework separa tre responsabilità:

Interfaccia pubblica — metodi come send(), sendTemplate() con tipi del framework (MailMessage, MailRecipient)
Traduzione — conversione da MailRecipient a Brevo\Client\Model\SendSmtpEmailTo, da MailMessage alla struttura richiesta dall'API
Comunicazione — la chiamata effettiva all'SDK di Brevo con error handling specifico del provider

Questa separazione permette di cambiare il provider senza toccare ne l'interfaccia pubblica ne il codice applicativo — si riscrive solo la traduzione e la comunicazione.

Il valore dell'Adapter si misura al momento del cambiamento

Il valore dell'Adapter non e immediatamente visibile — si manifesta quando qualcosa cambia. Quando SendinBlue e diventato Brevo, l'unico file da toccare e stato l'adapter. Nessun controller modificato, nessun service riscritto, nessun test aggiornato (a parte quello dell'adapter stesso). Il resto del codice ha continuato a funzionare come se nulla fosse accaduto — perché per il codice applicativo, nulla e accaduto.

Questa protezione dal cambiamento ha un nome nel mondo dei design pattern: Information Hiding. L'adapter nasconde l'identita del provider dietro un'interfaccia stabile. Domani Brevo potrebbe cambiare di nuovo nome, cambiare la versione dell'API, o essere sostituito interamente da un altro servizio. L'adapter assorbe il cambiamento, e il codice applicativo resta intatto. E il ritorno sull'investimento di un'astrazione ben posizionata.

Adapter e altri pattern: collaborazioni naturali

L'Adapter collabora naturalmente con altri pattern. Con lo Strategy: se hai più provider email (Brevo per la produzione, un logger per lo sviluppo), ogni adapter diventa una strategia intercambiabile. Con il Factory Method: MailService::make() decide quale adapter istanziare in base alla configurazione. Con il Facade: il MailService semplifica un'API complessa (l'SDK di Brevo ha decine di metodi) in un'interfaccia minimale con solo i metodi che il framework usa davvero.

Questa composizione di pattern non e accidentale — e il risultato di una progettazione guidata dai principi SOLID. L'adapter rispetta il Single Responsibility (traduce, non fa logica di business), l'Open/Closed (nuovo provider = nuovo adapter, zero modifiche altrove), il Dependency Inversion (il codice applicativo dipende dall'astrazione MailService, non dal concreto Brevo). I pattern e i principi si rinforzano a vicenda.

Quando usare l'Adapter Pattern

L'Adapter e la scelta giusta in questi scenari:

Integrazione con SDK di terze parti — API di pagamento, mail, storage cloud, social login
Legacy code — wrappare codice vecchio con un'interfaccia moderna senza riscriverlo
Cambio di provider — quando prevedi (o vuoi prepararti per) il cambio di un servizio esterno
Testing — sostituire l'adapter reale con uno che scrive su file o su array in memoria

Non usare l'Adapter quando l'integrazione e banale e il provider non cambiera mai (raro, ma possibile). L'overhead di un adapter inutile e minimo ma reale — una classe in più da mantenere, un livello di indirezione in più da navigare nel debugging. Come sempre, il pragmatismo guida la scelta: se il costo dell'adapter e inferiore al costo di un futuro cambio di provider, l'adapter si ripaga.

👉 Leggi l'articolo completo su iadicola.it

Quick note: Middleware come Chain of Responsibility

Dev-Iadicola — Sun, 09 Aug 2026 17:00:14 +0000

Ogni anello decide se passare al successivo

Lo stack middleware di Soft PHP MVC e una Chain of Responsibility: ogni middleware riceve la request, decide se gestirla o passarla al successivo, e può modificare la response in uscita. CsrfMiddleware verifica il token — se manca, risponde 403 e la catena si interrompe. RateLimitMiddleware conta le richieste — se il limite e superato, risponde 429. AuthMiddleware verifica la sessione — se non autenticato, redirige al login. Ogni anello e un filtro autonomo con una logica precisa.

La potenza del pattern e nella composibilita: l'ordine dei middleware conta, ma ogni middleware e indipendente. Puoi aggiungere, rimuovere o riordinare anelli senza toccare gli altri. Il VisitorTrackingMiddleware e stato aggiunto alla catena senza modificare una riga dei middleware esistenti — e questo e il test definitivo di un buon Chain of Responsibility. L'Open/Closed Principle in azione: la catena e aperta all'estensione (nuovi anelli), chiusa alla modifica (anelli esistenti non cambiano).

Cos'e il Chain of Responsibility: definizione formale

Il Gang of Four definisce il Chain of Responsibility come un pattern comportamentale che "evita di accoppiare il mittente di una richiesta al suo destinatario, dando a più oggetti la possibilita di gestire la richiesta. Gli oggetti riceventi vengono concatenati e la richiesta viene passata lungo la catena fino a quando un oggetto la gestisce". I due elementi chiave sono: l'Handler (l'interfaccia comune a tutti gli anelli) e la catena (la sequenza ordinata di handler).

A differenza dell'Observer, dove tutti gli osservatori vengono notificati, nella Chain of Responsibility la richiesta può fermarsi a qualsiasi anello. Un middleware che risponde con un errore 403 interrompe la catena — i middleware successivi non vengono eseguiti. Questa capacità di cortocircuito e fondamentale per la sicurezza: il CsrfMiddleware deve poter bloccare una richiesta malevola prima che raggiunga il controller.

L'anatomia di un middleware in Soft PHP MVC

Ogni middleware nel framework implementa un contratto semplice: riceve la request e un callable che rappresenta il prossimo anello della catena. Il middleware può:

Passare la request al successivo — chiama il callable e restituisce la response (middleware trasparente)
Modificare la request — aggiunge header, normalizza input, poi passa al successivo
Interrompere la catena — restituisce una response direttamente (errore, redirect, cache hit)
Modificare la response — chiama il successivo, poi modifica la response prima di restituirla

Questa flessibilita rende il middleware una primitiva estremamente potente. Non e un caso che la quasi totalita dei framework PHP moderni — Laravel, Symfony, Slim — adotti lo stesso pattern per il request handling. La Chain of Responsibility nel contesto HTTP e diventata uno standard de facto dell'ecosistema PHP.

Middleware concreti nel framework

Lo stack middleware di Soft PHP MVC include anelli con responsabilità diverse:

CsrfMiddleware — verifica il token CSRF su richieste POST/PUT/DELETE, protegge da attacchi cross-site request forgery
RateLimitMiddleware — limita le richieste per IP in una finestra temporale, previene abusi e DDoS
AuthMiddleware — verifica l'autenticazione, redirige al login se la sessione e scaduta
VisitorTrackingMiddleware — traccia i visitatori unici per analytics, senza bloccare la request
MaintenanceModeMiddleware — intercetta tutte le richieste e mostra la pagina di manutenzione quando attivo

L'ordine e significativo: il CSRF check avviene prima dell'auth, perché una richiesta senza token valido non dovrebbe nemmeno arrivare al controllo dell'autenticazione. Il rate limiting avviene prima di tutto, perché un attacco brute force non dovrebbe consumare risorse per verificare token o sessioni.

Pipeline pattern: l'evoluzione del Chain of Responsibility

In molti framework moderni, il Chain of Responsibility per i middleware e implementato come Pipeline: un oggetto che riceve una lista di handler e li esegue in sequenza, passando il risultato di uno come input del successivo. La Pipeline e una variante più strutturata della catena classica — invece di lasciare che ogni anello conosca il successivo, la pipeline li orchestra dall'esterno.

In Soft PHP MVC, il kernel HTTP costruisce la pipeline al boot dell'applicazione, concatenando i middleware configurati nel file di routing. La pipeline e immutabile dopo la costruzione: l'ordine degli anelli non cambia durante l'esecuzione. Questa immutabilita semplifica il debugging e garantisce un comportamento predicibile — la stessa request attraversa sempre gli stessi anelli nello stesso ordine.

Quando usare la Chain of Responsibility

Il pattern e ideale quando:

Più oggetti possono gestire una richiesta e il gestore corretto non e noto a priori
L'ordine di gestione e importante ma deve essere configurabile
Nuovi gestori devono poter essere aggiunti senza modificare quelli esistenti
Una richiesta deve poter essere rifiutata a qualsiasi livello della catena

Oltre ai middleware HTTP, la Chain of Responsibility si applica a validazione (ogni regola e un anello che può bloccare), logging (ogni handler decide se loggare e a quale livello), e event handling (ogni listener può marcare l'evento come gestito). In Soft PHP MVC, il middleware e l'applicazione principale, ma il pattern e una risorsa architetturale disponibile ogni volta che serve una catena decisionale configurabile e aperta all'estensione.

👉 Leggi l'articolo completo su iadicola.it

Decorator Pattern: aggiungere comportamento senza toccare il codice esistente

Dev-Iadicola — Sat, 08 Aug 2026 17:00:12 +0000

Il problema: estendere senza ereditare

Immagina di avere un servizio che invia notifiche via email. Funziona perfettamente. Poi arriva la richiesta: "vogliamo anche un log di ogni notifica inviata". La tentazione immediata e modificare la classe esistente, aggiungendo il logging dentro il metodo send(). Ma questo viola il principio di responsabilità singola: la classe che invia email non dovrebbe occuparsi di logging. E se domani servisse anche il caching? E la validazione? Ogni nuova responsabilità si accumulera nella stessa classe fino a renderla ingestibile.

L'ereditarieta sembra una soluzione: LoggingEmailNotifier extends EmailNotifier. Ma l'ereditarieta crea una gerarchia rigida. Se vuoi logging + caching, serve una nuova sottoclasse. Logging + caching + rate limiting? Un'altra ancora. Il numero di combinazioni esplode esponenzialmente. Questo problema ha un nome preciso nella letteratura del software: class explosion, e il Decorator Pattern e la risposta elegante.

Cos'e il Decorator Pattern: definizione formale

Il Gang of Four definisce il Decorator come un pattern strutturale che "attacca responsabilità aggiuntive a un oggetto in modo dinamico, fornendo un'alternativa flessibile alla sottoclasse per estendere le funzionalita". Il concetto e semplice: il decorator implementa la stessa interfaccia dell'oggetto che wrappa, delega le chiamate all'oggetto originale, e aggiunge il proprio comportamento prima, dopo, o attorno alla delega.

La struttura prevede quattro attori: il Component (l'interfaccia comune), il ConcreteComponent (l'implementazione base), il Decorator (la classe astratta che mantiene un riferimento al Component wrappato) e i ConcreteDecorator (le implementazioni che aggiungono comportamento specifico). Il client non distingue tra l'oggetto originale e quello decorato: entrambi rispettano lo stesso contratto.

Esempio teorico: un sistema di notifiche componibile

Consideriamo un'interfaccia NotifierInterface con un metodo send(string $message): void. L'implementazione base EmailNotifier invia l'email. Poi creiamo i decorator:

LoggingDecorator: riceve un NotifierInterface nel costruttore, chiama $this->notifier->send($message) e poi logga l'invio. Il logging e aggiunto senza toccare EmailNotifier.
RateLimitDecorator: prima di delegare la chiamata, controlla se il limite di invii e stato raggiunto. Se si, lancia un'eccezione. Se no, delega e incrementa il contatore.
RetryDecorator: wrappa la chiamata in un try/catch e ritenta fino a N volte in caso di fallimento. Aggiunge resilienza senza che il notifier base sappia nulla di retry.
EncryptionDecorator: prima di delegare, cripta il messaggio. Il notifier base riceve un messaggio già criptato senza saperlo.

La composizione avviene a runtime: $notifier = new LoggingDecorator(new RateLimitDecorator(new RetryDecorator(new EmailNotifier()))). L'ordine conta: il logging avvolge il rate limiting che avvolge il retry che avvolge l'invio. Puoi ricombinare questi decorator in qualsiasi ordine senza creare nuove classi.

Perché la composizione batte l'ereditarieta

Con 4 decorator e la necessita di combinarne qualsiasi sottoinsieme, l'ereditarieta richiederebbe 15 sottoclassi (tutte le combinazioni possibili). Con il Decorator ne servono 4: una per responsabilità. Ogni nuovo decorator si compone con tutti gli esistenti senza modificare nulla. Questa e la potenza della composizione rispetto all'ereditarieta, uno dei principi fondamentali della programmazione ad oggetti moderna.

Decorator nel mondo reale: middleware HTTP

Se hai lavorato con framework PHP moderni, hai già usato il Decorator Pattern senza saperlo. I middleware HTTP sono decorator: ogni middleware riceve la request, può modificarla, delega al middleware successivo (l'oggetto wrappato), e può modificare la response al ritorno. La pipeline di middleware e una catena di decorator dove ogni anello aggiunge un comportamento: autenticazione, CORS, rate limiting, logging.

In Soft PHP MVC, il MiddlewarePipeline funziona esattamente così. Il CsrfMiddleware decora la request aggiungendo la verifica del token. Il RateLimitMiddleware decora aggiungendo il controllo delle richieste per IP. Il CorsMiddleware decora la response aggiungendo gli header necessari. Nessuno di questi middleware conosce gli altri: ognuno fa una cosa sola e la fa bene.

Decorator Pattern e stream I/O

Un altro esempio classico e l'I/O. Immagina un'interfaccia StreamInterface con metodi read() e write(). L'implementazione base FileStream legge e scrive su file. Un BufferedStream wrappa qualsiasi stream aggiungendo un buffer in memoria per ridurre le operazioni disco. Un CompressedStream wrappa qualsiasi stream aggiungendo compressione gzip al volo. Un EncryptedStream aggiunge crittografia.

La composizione new EncryptedStream(new CompressedStream(new BufferedStream(new FileStream('data.bin')))) crea uno stream che scrive su file, con buffer, compressione e crittografia, senza che nessuna di queste classi conosca le altre. Ogni layer e indipendente, testabile, e riutilizzabile in contesti diversi.

Quando usare il Decorator

Usa il Decorator quando vuoi aggiungere responsabilità a oggetti singoli senza influenzare altri oggetti della stessa classe
Usa il Decorator quando l'ereditarieta porta a un'esplosione di sottoclassi per coprire tutte le combinazioni
Usa il Decorator quando il comportamento aggiuntivo deve essere componibile e l'ordine può variare
Non usare il Decorator se il comportamento aggiuntivo e sempre lo stesso e non cambia mai: in quel caso l'ereditarieta semplice e sufficiente
Non usare il Decorator se la catena diventa troppo profonda e il debugging diventa impossibile: a quel punto considera il middleware pattern con una pipeline esplicita

Decorator e principi SOLID

Il Decorator e uno dei pattern che meglio incarnano i principi SOLID. Rispetta il Single Responsibility Principle perché ogni decorator ha una sola ragione di cambiare. Rispetta l'Open/Closed Principle perché estende il comportamento senza modificare il codice esistente. Rispetta il Liskov Substitution Principle perché ogni decorator e sostituibile al component originale. Rispetta il Dependency Inversion Principle perché tutti dipendono dall'astrazione (l'interfaccia), non dalle implementazioni concrete.

Pochi pattern riescono a soddisfare quattro principi SOLID contemporaneamente. Il Decorator ci riesce naturalmente, senza forzature. Questo spiega perché e uno dei pattern più diffusi e più utili nel software professionale.

👉 Leggi l'articolo completo su iadicola.it

Proxy Pattern: controllare l'accesso senza cambiare l'interfaccia

Dev-Iadicola — Fri, 07 Aug 2026 17:00:11 +0000

Il problema: oggetti pesanti che non servono subito

Hai un modello Article con una relazione comments(). La pagina del blog elenca 20 articoli con titolo, data e autore. Nessuno ha ancora cliccato su un articolo per vederne i commenti, eppure il codice carica tutte le relazioni in anticipo, eseguendo 21 query (una per gli articoli e una per i commenti di ciascuno). E il classico N+1 problem, ma la radice e più profonda: il problema e che l'oggetto Article espone direttamente i commenti, e chi lo usa non ha modo di decidere quando caricarli.

Il Proxy Pattern risolve questo problema interponendo un oggetto surrogato (il proxy) tra il client e l'oggetto reale. Il proxy implementa la stessa interfaccia dell'oggetto reale, ma controlla quando e come l'oggetto reale viene creato o acceduto. Il client non sa di parlare con un proxy — per lui e lo stesso oggetto di sempre.

Cos'e il Proxy Pattern: definizione e varianti

Il Gang of Four definisce il Proxy come un pattern strutturale che "fornisce un surrogato o segnaposto per un altro oggetto per controllarne l'accesso". La struttura e simile al Decorator — entrambi wrappano un oggetto con la stessa interfaccia — ma l'intento e diverso: il Decorator aggiunge comportamento, il Proxy controlla l'accesso.

Esistono diverse varianti del Proxy, ognuna con uno scopo specifico:

Virtual Proxy (Lazy Loading): ritarda la creazione dell'oggetto reale fino al primo utilizzo. Utile per oggetti pesanti che potrebbero non servire mai.
Protection Proxy: verifica i permessi prima di delegare la chiamata. L'oggetto reale non sa nulla di autorizzazione — il proxy la gestisce esternamente.
Cache Proxy: memorizza il risultato dell'oggetto reale e lo restituisce direttamente alle chiamate successive, evitando ricalcoli costosi.
Remote Proxy: rappresenta un oggetto che vive su un altro server o processo. Il client chiama metodi locali, il proxy traduce in chiamate di rete.
Logging Proxy: registra ogni chiamata all'oggetto reale per debugging o auditing senza che il codice di business contenga logica di logging.

Esempio teorico: lazy loading delle relazioni ORM

Consideriamo un ORM che carica un Article dal database. L'articolo ha una proprietà $comments che dovrebbe contenere un array di oggetti Comment. Con il caricamento eager, tutti i commenti vengono caricati immediatamente. Con il Proxy Pattern, la proprietà contiene inizialmente un CommentCollectionProxy.

Il CommentCollectionProxy implementa la stessa interfaccia di una collection (es. Countable, IteratorAggregate, ArrayAccess). Internamente mantiene un flag $loaded = false e un riferimento al query necessario per caricare i dati. Quando qualcuno chiama count() o itera la collection, il proxy esegue la query, memorizza il risultato e delega la chiamata alla collection reale. Alle chiamate successive il dato e già in memoria.

Il vantaggio: N+1 diventa 1+0

Se la pagina del blog mostra solo titolo e data, nessun proxy viene mai risolto: zero query per i commenti. Se l'utente apre un articolo specifico, il proxy di quell'articolo risolve i commenti con una singola query. Il pattern trasforma l'N+1 problem in un "1 + solo quello che serve", senza che il codice del controller cambi di una riga.

Esempio teorico: Protection Proxy per le API

Immagina un servizio ReportService con un metodo generateFinancialReport(). Questo metodo può essere chiamato solo da utenti con ruolo "admin" o "finance". Invece di aggiungere il controllo dei permessi dentro il service (violando SRP), crei un AuthorizedReportServiceProxy:

Il proxy riceve il ReportService reale e un AuthorizationChecker nel costruttore
Prima di delegare generateFinancialReport(), verifica che l'utente corrente abbia il permesso report.financial.generate
Se il permesso manca, lancia una ForbiddenException senza mai chiamare il service reale
Il ReportService resta pulito: genera report, punto. Non sa nulla di permessi.

Esempio teorico: Cache Proxy per chiamate API esterne

Un WeatherService chiama un'API esterna per ottenere le previsioni meteo. Ogni chiamata costa 200ms di latenza. Un CachedWeatherProxy wrappa il service: alla prima chiamata delega al service reale e salva il risultato in cache con un TTL di 30 minuti. Alle chiamate successive restituisce il dato dalla cache in meno di 1ms. Il controller non sa se sta ricevendo dati freschi o cachati — e non deve saperlo.

Proxy vs Decorator: la differenza sottile

Proxy e Decorator hanno la stessa struttura: un wrapper con la stessa interfaccia dell'oggetto wrappato. La differenza e nell'intento:

Decorator: aggiunge comportamento nuovo. Il focus e sull'estensione delle funzionalita.
Proxy: controlla l'accesso all'oggetto esistente. Il focus e su quando, come e se l'oggetto viene usato.

In pratica: un LoggingDecorator aggiunge logging come funzionalita extra. Un LazyProxy controlla quando l'oggetto viene creato. Un ProtectionProxy controlla se l'oggetto viene acceduto. La distinzione e concettuale, non strutturale — ed e importante per comunicare l'intento del codice a chi lo legge.

Quando usare il Proxy

Lazy Loading: quando creare l'oggetto e costoso e potrebbe non servire (relazioni ORM, connessioni, file pesanti)
Access Control: quando vuoi separare la logica di autorizzazione dalla logica di business
Caching: quando il risultato e costoso da calcolare ma stabile nel tempo
Remote Access: quando l'oggetto reale vive su un altro server e vuoi nascondere la complessità di rete
Non usare il Proxy se l'oggetto e leggero e viene sempre usato: il proxy aggiunge indirezione senza beneficio
Non usare il Proxy se la trasparenza diventa un problema: a volte e meglio rendere esplicito che un'operazione e lazy o cachata

Il Proxy Pattern e uno dei pattern più invisibili — quando funziona bene, nessuno sa che c'e. E questa e la sua forza: il codice di business resta pulito, e il controllo dell'accesso, del caching o del caricamento e gestito in un unico punto, testabile e modificabile indipendentemente.

👉 Leggi l'articolo completo su iadicola.it

Command Pattern: trasformare le azioni in oggetti

Dev-Iadicola — Thu, 06 Aug 2026 17:00:16 +0000

Il problema: azioni che vivono solo nel momento

Un controller riceve una richiesta POST e chiama direttamente $order->cancel(). Funziona. Ma cosa succede quando servono requisiti aggiuntivi? "Vogliamo un log di chi ha cancellato l'ordine e quando." Aggiungi una riga di logging. "Vogliamo poter annullare la cancellazione." Adesso serve memorizzare lo stato precedente. "Vogliamo che le cancellazioni passino per un'approvazione." Serve una coda. "Vogliamo poter ripetere l'operazione se fallisce." Serve un sistema di retry.

Ogni requisito aggiuntivo aggiunge complessità al controller perché l'azione — cancellare un ordine — vive solo nel flusso di esecuzione: non e un oggetto che puoi manipolare, accodare, serializzare o annullare. Il Command Pattern risolve questo problema trasformando l'azione in un oggetto con un proprio stato, una propria identita e un ciclo di vita.

Cos'e il Command Pattern: definizione formale

Il Gang of Four definisce il Command come un pattern comportamentale che "incapsula una richiesta come oggetto, permettendo di parametrizzare i client con richieste diverse, accodare o loggare le richieste, e supportare operazioni annullabili". La struttura prevede cinque attori:

Command: l'interfaccia con il metodo execute()
ConcreteCommand: implementa execute() con la logica specifica, mantenendo un riferimento al Receiver
Receiver: l'oggetto che sa effettivamente come eseguire l'operazione
Invoker: chiede al Command di eseguire la richiesta, senza sapere cosa fa
Client: crea il ConcreteCommand e lo associa al Receiver

Esempio teorico: un sistema di ordini con undo

Immagina un gestionale dove gli operatori gestiscono ordini. Ogni azione e un Command:

CancelOrderCommand: riceve l'ordine nel costruttore. Il metodo execute() salva lo stato corrente ($this->previousStatus = $order->getStatus()), poi chiama $order->cancel(). Il metodo undo() ripristina lo stato precedente: $order->setStatus($this->previousStatus).
ShipOrderCommand: segna l'ordine come spedito, registra la data di spedizione. L'undo() annulla la spedizione e ripristina lo stato precedente.
RefundOrderCommand: esegue il rimborso. L'undo() annulla il rimborso (se ancora possibile).
ChangeAddressCommand: aggiorna l'indirizzo di spedizione. L'undo() ripristina l'indirizzo precedente.

L'Invoker mantiene una history stack: ogni Command eseguito viene pushato nello stack. L'operazione "annulla" fa pop dall'stack e chiama undo() sull'ultimo Command. L'operazione "ripeti" fa la stessa cosa con uno stack di redo. Il sistema di undo/redo e generico e funziona con qualsiasi Command, senza conoscerne il tipo concreto.

Command Pattern nella CLI

In Soft PHP MVC, i comandi CLI sono un'applicazione naturale del Command Pattern. Ogni comando implementa una classe con un metodo handle(Input, Output): int. L'attributo #[CliCommand] dichiara il nome e la descrizione. Il Kernel (l'Invoker) riceve il nome del comando dalla linea di comando, cerca il ConcreteCommand corrispondente, e chiama handle(). Il Kernel non sa cosa fa il comando: sa solo che ha un metodo handle() e restituisce un exit code.

Questa struttura permette di aggiungere comandi senza toccare il Kernel: basta creare una nuova classe con l'attributo #[CliCommand] e l'auto-discovery la trova. Il Command Pattern e il motivo per cui 26 comandi diversi — da migrate:fresh a key:generate — condividono la stessa infrastruttura senza conflitti.

Esempio teorico: job queue asincrona

Il Command Pattern e alla base di ogni sistema di code (queue). Un job e un Command serializzato: contiene tutti i dati necessari per eseguire l'operazione, ma l'esecuzione e differita nel tempo. Il flusso e:

Il controller crea il Command: $command = new SendInvoiceEmail($orderId, $customerEmail)
Il dispatcher (Invoker) serializza il Command e lo mette in coda (Redis, database, RabbitMQ)
Un worker legge il Command dalla coda, lo deserializza e chiama execute()
Se l'esecuzione fallisce, il Command può essere rimesso in coda per un retry
Se fallisce N volte, viene spostato in una dead letter queue per analisi manuale

Il fatto che l'azione sia un oggetto serializzabile rende possibile tutto questo: accodare, ritardare, ritentare, loggare, monitorare. Un'azione che vive solo come chiamata di metodo non può essere accodata o ritentata — un Command si.

Command vs Strategy: la differenza

Command e Strategy sono entrambi pattern comportamentali con una struttura simile (un oggetto con un metodo da invocare), ma l'intento e diverso:

Strategy: rappresenta come fare qualcosa. E intercambiabile: puoi cambiare l'algoritmo a runtime. L'accento e sull'alternativa.
Command: rappresenta cosa fare. E un'azione reificata con il proprio stato e ciclo di vita. L'accento e sull'operazione.

Uno Strategy cambia il comportamento di un contesto. Un Command e un'azione che puoi manipolare come dato: accodare, serializzare, annullare, ripetere. La differenza e sottile ma fondamentale per scegliere il pattern giusto.

Quando usare il Command Pattern

Usa il Command quando vuoi supportare undo/redo: ogni Command salva lo stato precedente e sa come ripristinarlo
Usa il Command quando le azioni devono essere accodate, ritardate o eseguite in batch
Usa il Command quando vuoi loggare ogni azione con i suoi parametri per auditing o debugging
Usa il Command quando azioni diverse devono passare per la stessa pipeline (validazione, autorizzazione, logging)
Non usare il Command per operazioni semplici e immediate dove la complessità aggiuntiva non e giustificata
Non usare il Command se non hai bisogno di nessuna delle funzionalita che il pattern offre: l'astrazione senza beneficio e solo burocrazia

Il Command Pattern trasforma le azioni da verbi effimeri a sostantivi permanenti. Questa trasformazione apre possibilita che prima non esistevano: undo, queue, replay, auditing. E uno dei pattern con il miglior rapporto tra complessità introdotta e funzionalita abilitate.

👉 Leggi l'articolo completo su iadicola.it

State Pattern: oggetti che cambiano comportamento in base al proprio stato

Dev-Iadicola — Wed, 05 Aug 2026 17:00:10 +0000

Il problema: lo switch sullo stato che divora il codice

Un ordine in un e-commerce ha diversi stati: draft, pending, paid, shipped, delivered, cancelled, refunded. Ogni operazione dipende dallo stato corrente: puoi pagare un ordine solo se e pending, puoi spedire solo se e paid, puoi cancellare solo se non e già shipped. Il codice diventa una cascata di if ($this->status === 'pending') in ogni metodo.

Il metodo cancel() controlla se lo stato permette la cancellazione. Il metodo ship() controlla se lo stato permette la spedizione. Il metodo refund() controlla se lo stato permette il rimborso. Ogni nuovo stato o nuova operazione richiede di aggiornare tutti i metodi. Ogni nuova transizione richiede di aggiornare tutti i controlli. La complessità cresce come il prodotto di stati per operazioni: 7 stati e 6 operazioni significano 42 condizioni da gestire e mantenere sincronizzate.

Cos'e lo State Pattern: definizione formale

Il Gang of Four definisce lo State come un pattern comportamentale che "permette a un oggetto di alterare il proprio comportamento quando il suo stato interno cambia. L'oggetto sembrera cambiare la propria classe". La struttura prevede tre attori:

Context: l'oggetto che ha uno stato (es. Order). Mantiene un riferimento allo State corrente e delega le operazioni a esso.
State: l'interfaccia che dichiara i metodi per ogni operazione (es. pay(), ship(), cancel()).
ConcreteState: ogni stato (es. PendingState, PaidState) implementa i metodi con il comportamento specifico di quello stato.

Esempio teorico: ciclo di vita di un ordine

Definiamo l'interfaccia OrderStateInterface con i metodi: pay(Order $order): void, ship(Order $order): void, cancel(Order $order): void, refund(Order $order): void, getStatus(): string.

Ogni stato implementa l'interfaccia:

DraftState: pay() lancia un'eccezione ("non puoi pagare un ordine in bozza, prima confermalo"). cancel() transiziona a CancelledState. Tutti gli altri metodi lanciano eccezioni appropriate.
PendingState: pay() processa il pagamento e transiziona a PaidState. cancel() transiziona a CancelledState. ship() lancia "non puoi spedire un ordine non pagato".
PaidState: ship() registra la spedizione e transiziona a ShippedState. refund() processa il rimborso e transiziona a RefundedState. pay() lancia "ordine già pagato".
ShippedState: cancel() lancia "non puoi cancellare un ordine già spedito". refund() richiede prima il reso. L'unica transizione valida e verso DeliveredState quando il corriere conferma la consegna.
CancelledState e RefundedState: sono stati terminali. Tutti i metodi lanciano eccezioni: nessuna transizione e possibile.

La classe Order ha una proprieta private OrderStateInterface $state e delega ogni operazione: public function pay(): void { $this->state->pay($this); }. Il metodo di transizione Order::transitionTo(OrderStateInterface $newState) e chiamato dagli stati stessi: $order->transitionTo(new PaidState()).

Il vantaggio: aggiungere uno stato senza toccare gli altri

Se arriva un nuovo stato — ad esempio OnHoldState per ordini bloccati in attesa di verifica antifrode — basta creare una nuova classe che implementa OrderStateInterface. Definisci quali operazioni sono permesse in questo stato e quali transizioni sono valide. Nessun altro stato deve cambiare. Nessun metodo della classe Order deve essere modificato. Il principio Open/Closed e rispettato naturalmente.

State Pattern vs Enum con match

In PHP 8.1+ si potrebbe gestire gli stati con un Enum e match:

match($this->status) { OrderStatus::Pending => ..., OrderStatus::Paid => ..., ... }

Funziona per casi semplici, ma ha un limite strutturale: ogni nuovo stato richiede di aggiornare ogni match in ogni metodo. Con lo State Pattern, ogni nuovo stato e autocontenuto nella propria classe. La scelta dipende dalla complessità:

3-4 stati, 2-3 operazioni: l'Enum con match e più semplice e diretto. Lo State Pattern sarebbe over-engineering.
5+ stati, 4+ operazioni: lo State Pattern scala meglio perché ogni stato e isolato.
Transizioni complesse con regole di business: lo State Pattern permette di incapsulare le regole dentro ogni stato.

State Machine come evoluzione

Lo State Pattern può evolvere in una State Machine formale, dove le transizioni valide sono dichiarate esplicitamente in una mappa: ['pending' => ['paid', 'cancelled'], 'paid' => ['shipped', 'refunded']]. La State Machine aggiunge garanzie: nessuna transizione non dichiarata e possibile, e ogni transizione può avere guardie (condizioni) e azioni (side effect).

In molti framework questa evoluzione e supportata da librerie dedicate (Symfony Workflow, Laravel State Machines). Ma il concetto alla base e sempre lo State Pattern: il comportamento cambia in base allo stato, e ogni stato sa quali transizioni sono valide.

Quando usare lo State Pattern

Usa lo State Pattern quando un oggetto ha un numero significativo di stati e il comportamento varia in base allo stato corrente
Usa lo State Pattern quando gli switch/if sullo stato sono ripetuti in molti metodi della stessa classe
Usa lo State Pattern quando le regole di transizione sono complesse e vuoi renderle esplicite
Non usare lo State Pattern per oggetti con 2-3 stati semplici: un boolean o un enum con match bastano
Non usare lo State Pattern se le transizioni non hanno regole: se ogni stato può andare in ogni altro stato, il pattern aggiunge struttura senza valore

Lo State Pattern non e un modo elegante di riscrivere degli if: e un modo di rendere esplicite e isolate le regole di comportamento che dipendono dallo stato. Quando queste regole sono complesse, il pattern trasforma un groviglio di condizioni in una struttura leggibile, testabile e manutenibile.

👉 Leggi l'articolo completo su iadicola.it

L'AI sostituirà i programmatori?

Dev-Iadicola — Tue, 04 Aug 2026 17:00:15 +0000

Si sente spesso questa affermazione, sui social, nelle conferenze, nelle chiacchierate tra colleghi.

C'è chi la teme, chi la cavalca come argomento di marketing, chi la usa per giustificare tagli ai team di sviluppo.

Io ho una posizione diversa, basata sull'esperienza diretta: l'AI è uno strumento potente, ma chi dice che sostituirà i programmatori non ha ancora revisionato abbastanza codice scritto da un agente.Il problema non è la velocità

L'AI è veloce.

Su questo non ci sono dubbi. Genera codice in pochi secondi, risponde a qualsiasi richiesta, non si stanca e non chiede ferie.Ma la velocità da sola non basta.

Anzi, può essere controproducente se il codice prodotto è di bassa qualità.

E qui iniziano i problemi.

Cosa ho osservato sul campo

Codice di bassa qualità

Uno dei problemi più frequenti è la duplicazione.

L'agente non ha una visione globale del progetto: non sa che quella funzione esiste già altrove, non ragiona sulla base di codebase consolidate.

Scrive quello che gli chiedi, punto.

Il risultato è un progetto che cresce in larghezza invece che in profondità, pieno di logica ridondante difficile da mantenere.

Assenza di pattern architetturali

L'AI conosce i design pattern. Se glielo chiedi, ti spiegherà cos'è un repository, un service, un DTO.

Ma se non glielo chiedi esplicitamente, non li userà.

La logica di business finisce nei controller, le responsabilità non vengono separate, e il progetto diventa rapidamente un monolite ingestibile.

Ho visto controller con decine di righe di logica inline che avrebbero dovuto stare in classi dedicate. Non perché l'agente non sapesse farlo, ma perché nessuno glielo aveva chiesto.

Architettura approssimativa

Se chiedi a un agente di progettare un'architettura, ti darà qualcosa di funzionante — ma raramente qualcosa di ben fatto.

Classi astratte che andrebbero ripensate, dependency injection usata male o per niente, layer che si sovrappongono senza rispettare le responsabilità.

Un software architect esperto farebbe scelte diverse, e soprattutto le motiverebbe.

Nessuna visione a lungo termine

Questo è forse il limite più critico.

L'agente risponde alla richiesta presente.

Non pensa a come il progetto evolverà tra sei mesi, non considera la scalabilità, non anticipa i problemi che emergeranno quando il team crescerà o i requisiti cambieranno.

Il debito tecnico si accumula silenziosamente, e quando esplode è sempre nel momento peggiore.

Tende ad accontentarti

L'AI non ha interessi propri.

Esegue.

Se cambi direzione dieci volte in una settimana, la seguirà ogni volta senza alzare la mano. Se hai una pessima idea, ci sono buone probabilità che la implementi comunque — a meno che non sia palesemente errata.

Un collega esperto ti direbbe di no.

Ti farebbe le domande scomode. L'agente no.

Un esempio concreto

Se chiedi a un agente di creare un'entità per gestire dati statici — tipo una lista di nazioni o di categorie che non cambieranno mai — lo farà.

Tabella nel database, model, migration, tutto quanto.Un programmatore con esperienza ti fermerebbe subito: "Se i dati non cambiano, non hai bisogno di un'entità. Usa un file JSON o un enum."

È una scelta banale per chi ha anni di esperienza, ma l'agente non la proporrà mai se non gliela chiedi.

La code review inutile

Paradossalmente, se chiedi all'agente di fare una code review su codice già ben scritto, ti suggerirà comunque dei cambiamenti.

Perché è programmato per rispondere, non per dire "qui non c'è nulla da fare".

Il rischio concreto è introdurre complessità non necessaria su qualcosa che funzionava già bene.

Perché succede tutto questo?

La risposta è semplice: l'AI è una macchina che esegue ordini.

Non ha intuizione, non ha contesto storico sul progetto, non ha opinioni reali.

Risponde al prompt nel modo più plausibile possibile, basandosi sui dati su cui è stata addestrata.

Non ragiona sul problema.

Questo non significa che sia inutile. Significa che va usata per quello che è.

Allora a cosa serve?

L'AI è uno strumento. Come un martello: utile nelle mani giuste, pericoloso in quelle sbagliate.

Nella mia esperienza, rende i programmatori più veloci su compiti ripetitivi, boilerplate, ricerca di bug banali, generazione di test.

Ma richiede sempre qualcuno in grado di valutare l'output, riconoscere i problemi architetturali, prendere le decisioni che contano.Il programmatore che sa usarla bene è più produttivo. Il programmatore che si fida ciecamente, accumula debito tecnico.

Conclusione

L'AI sostituirà i programmatori? Forse, un giorno. Non lo escludo.

Ma oggi, chi pensa di poter affidare a un agente la progettazione e lo sviluppo di un software senza supervisione tecnica competente, si troverà presto con un progetto difficile da mantenere, da scalare e da capire.La qualità del codice conta. E quella, per ora, richiede ancora un essere umano che sappia cosa sta guardando.

👉 Leggi l'articolo completo su iadicola.it

Facade Pattern: semplificare l'accesso a sistemi complessi

Dev-Iadicola — Mon, 03 Aug 2026 17:00:14 +0000

Il problema: troppi oggetti per fare una cosa semplice

Per inviare un'email di conferma ordine servono sei passaggi: creare il template engine, caricare il template, renderizzare con i dati dell'ordine, creare il transport SMTP, configurare le credenziali, costruire il messaggio con mittente, destinatario, oggetto e corpo, e infine inviare. Sei oggetti, dodici metodi, venti righe di codice. Ogni controller che deve inviare un'email ripete lo stesso boilerplate, o copia-incolla da un controller precedente.

Il Facade Pattern propone di creare un'interfaccia semplificata che nasconde questa complessità. Invece di sei oggetti e dodici metodi, il controller chiama Mailer::send('order-confirmation', $order, $customer->email). Una riga. La Facade si occupa di orchestrare i sei oggetti sotto il cofano.

Cos'e il Facade Pattern: definizione formale

Il Gang of Four definisce il Facade come un pattern strutturale che "fornisce un'interfaccia unificata a un insieme di interfacce in un sottosistema. La Facade definisce un'interfaccia di livello superiore che rende il sottosistema più facile da usare". Non nasconde il sottosistema — lo rende accessibile a chi non ha bisogno di conoscerne i dettagli.

La struttura e semplice: una classe Facade che conosce quali classi del sottosistema sono responsabili di ogni richiesta, e delega le chiamate del client alle classi appropriate. Il sottosistema non sa dell'esistenza della Facade — le sue classi sono autonome e possono essere usate direttamente quando serve un controllo fine.

Esempio teorico: un sottosistema di reportistica

Immagina un sistema di generazione report con diverse componenti:

DataExtractor: esegue query sul database e restituisce dati grezzi
DataTransformer: aggrega, filtra e formatta i dati per il report
ChartGenerator: genera grafici SVG dai dati trasformati
PdfRenderer: combina testo e grafici in un documento PDF
FileStorage: salva il PDF generato nel filesystem o nel cloud
NotificationService: notifica l'utente che il report e pronto

Senza Facade, il controller deve orchestrare tutti questi oggetti manualmente: estrarre i dati, trasformarli, generare i grafici, renderizzare il PDF, salvarlo e notificare l'utente. Sei dipendenze nel controller, sei passaggi da coordinare, sei punti dove qualcosa può andare storto.

La Facade ReportFacade espone un metodo: generate(string $type, array $params, int $userId): string. Internamente orchestra tutti e sei i passaggi e restituisce il path del report generato. Il controller ha una sola dipendenza e una sola riga di codice.

La Facade non imprigiona

Un malinteso comune e che la Facade impedisca l'accesso diretto al sottosistema. Non e così: la Facade e un in più, non un invece di. Se un caso d'uso specifico richiede il controllo fine sul ChartGenerator — ad esempio per generare un grafico senza il PDF — il codice può usare direttamente ChartGenerator senza passare dalla Facade. La Facade semplifica il caso comune, non limita i casi speciali.

Esempio teorico: Facade per l'autenticazione

L'autenticazione coinvolge molti componenti: verifica credenziali, hashing password, gestione sessione, generazione token, verifica 2FA, logging dei tentativi. Una AuthFacade espone:

attempt(string $email, string $password): bool — verifica credenziali, logga il tentativo, avvia la sessione
verify2FA(string $code): bool — verifica il codice TOTP e completa l'autenticazione
logout(): void — invalida sessione e token
check(): bool — verifica se l'utente e autenticato

Ogni metodo della Facade coordina 3-4 componenti interni. Il middleware di autenticazione chiama AuthFacade::check() senza sapere che sotto il cofano vengono verificati sessione, token JWT e timestamp di scadenza.

Facade vs Service: la differenza

La distinzione tra Facade e Service e sottile ma importante:

Facade: semplifica l'accesso a un sottosistema esistente. Non aggiunge logica di business: orchestra componenti già esistenti. Se rimuovi la Facade, le classi del sottosistema funzionano ancora.
Service: contiene logica di business propria. Può usare componenti del sottosistema, ma aggiunge regole, validazioni e decisioni che non esistono altrove.

Se il metodo della tua "Facade" contiene 50 righe di logica di business con condizioni e calcoli, probabilmente e un Service, non una Facade. Se orchestra 6 chiamate a componenti diversi senza aggiungere logica, e una Facade pura.

Facade in Laravel e il malinteso

Le Facade di Laravel (Cache::get(), DB::table(), Auth::check()) non sono il Facade Pattern del Gang of Four. Sono static proxy: classi che risolvono un service dal container e delegano la chiamata statica a un'istanza. La confusione di nomenclatura e storica, ma e importante capire la differenza: il Facade Pattern originale crea un'interfaccia semplificata per un sottosistema complesso. Le "Facade" di Laravel sono un meccanismo di risoluzione dal container con sintassi statica.

Quando usare il Facade Pattern

Usa la Facade quando un sottosistema ha molte classi e il caso d'uso comune richiede di coordinarle sempre nello stesso modo
Usa la Facade quando vuoi ridurre le dipendenze del codice client: una Facade al posto di sei classi
Usa la Facade quando vuoi creare un punto di ingresso chiaro per un modulo o package
Non usare la Facade per nascondere un cattivo design: se il sottosistema e confuso, semplificarlo con una Facade non risolve il problema strutturale
Non usare la Facade se il sottosistema ha una sola classe: stai aggiungendo un layer di indirezione senza beneficio

Il Facade Pattern e il pattern della cortesia: rende un sistema complesso accessibile senza semplificarlo oltre misura. Non elimina la complessità — la nasconde dietro un'interfaccia pulita per chi non ha bisogno di vederla, e la lascia accessibile per chi ne ha bisogno.

👉 Leggi l'articolo completo su iadicola.it

Composite Pattern: trattare gerarchie come singoli oggetti

Dev-Iadicola — Sun, 02 Aug 2026 17:00:27 +0000

Il problema: strutture ricorsive con trattamento diverso

Un menu di navigazione ha voci semplici (link a una pagina) e voci con sotto-menu (dropdown che contengono altre voci). Il codice che renderizza il menu deve distinguere costantemente: "questa voce e un link diretto o un contenitore?" — e dentro il contenitore, ripetere la stessa domanda per ogni elemento. Ogni rendering, ogni conteggio, ogni ricerca richiede un if (is_array($item)) o un instanceof per distinguere foglie da nodi.

Lo stesso problema emerge ovunque ci siano strutture ad albero: un filesystem (file e cartelle), un'organizzazione aziendale (dipendenti e dipartimenti), un preventivo (singole voci e raggruppamenti), un layout UI (componenti singoli e container). Il Composite Pattern elimina la distinzione: foglie e nodi implementano la stessa interfaccia, e il codice client li tratta allo stesso modo.

Cos'e il Composite Pattern: definizione formale

Il Gang of Four definisce il Composite come un pattern strutturale che "compone oggetti in strutture ad albero per rappresentare gerarchie parte-intero. Il Composite permette ai client di trattare oggetti singoli e composizioni di oggetti in modo uniforme". La struttura prevede:

Component: l'interfaccia comune a foglie e compositi (es. MenuItemInterface con render(): string)
Leaf: l'elemento terminale che non contiene figli (es. MenuItem — un singolo link)
Composite: l'elemento che contiene figli, anch'esso Component (es. MenuGroup — un dropdown con sotto-voci)

La chiave e che MenuGroup implementa MenuItemInterface e contiene un array di MenuItemInterface. Il suo metodo render() chiama render() su ogni figlio. I figli possono essere MenuItem (foglie) o altri MenuGroup (compositi) — la ricorsione e naturale.

Esempio teorico: un sistema di preventivi

Un preventivo per un progetto web ha una struttura gerarchica:

Progetto Completo (composito, 15.000 EUR totale)
- Frontend (composito, 6.000 EUR)
  - Design UI — 2.000 EUR (foglia)
  - Sviluppo template — 2.500 EUR (foglia)
  - Responsive testing — 1.500 EUR (foglia)
- Backend (composito, 7.000 EUR)
  - API REST — 3.000 EUR (foglia)
  - Autenticazione — 2.000 EUR (foglia)
  - Pannello admin — 2.000 EUR (foglia)
- Deploy & Infrastruttura (composito, 2.000 EUR)
  - Setup server — 1.000 EUR (foglia)
  - CI/CD pipeline — 1.000 EUR (foglia)

L'interfaccia QuoteItemInterface ha due metodi: getTotal(): float e getDescription(): string. La foglia QuoteLine restituisce il proprio importo. Il composito QuoteGroup somma i totali di tutti i figli. Chiamare $progetto->getTotal() calcola ricorsivamente il totale dell'intero preventivo, indipendentemente dalla profondita della gerarchia.

Operazioni uniformi sulla gerarchia

Se aggiungi un metodo applyDiscount(float $percentage): void all'interfaccia, la foglia applica lo sconto al proprio importo, e il composito delega ad ogni figlio. Uno sconto applicato al nodo "Backend" si propaga automaticamente a "API REST", "Autenticazione" e "Pannello admin". Uno sconto applicato al nodo radice si propaga all'intero preventivo. Il codice che applica lo sconto non sa e non deve sapere se sta operando su una foglia o su un albero di 50 nodi.

Esempio teorico: un filesystem virtuale

L'esempio classico del Composite e il filesystem. L'interfaccia FileSystemEntry dichiara: getSize(): int, getName(): string, getPath(): string. La foglia File restituisce la propria dimensione. Il composito Directory somma le dimensioni di tutti i figli (file e sotto-directory). Chiamare $rootDir->getSize() calcola ricorsivamente la dimensione dell'intero albero.

Aggiungere operazioni e semplice: find(string $name): array nella foglia controlla il proprio nome, nella directory delega a tutti i figli e raccoglie i risultati. delete(): void nella foglia rimuove il file, nella directory rimuove ricorsivamente tutto il contenuto e poi se stessa. Ogni operazione si definisce una volta per la foglia e una volta per il composito.

Composite e il rendering di UI

Nei sistemi di rendering UI, il Composite Pattern e onnipresente. Un Panel contiene Button, Label, TextField e altri Panel. Il metodo render() di un Panel renderizza tutti i figli in sequenza. Il metodo setVisible(false) nasconde il panel e tutti i suoi figli. Il metodo validate() valida tutti i campi contenuti, ricorsivamente.

React, Vue, Blade — tutti i sistemi di templating moderni usano il Composite Pattern implicitamente: un componente può contenere altri componenti, e il rendering e ricorsivo. La differenza e che nel Composite Pattern classico l'interfaccia e esplicita e tipizzata, mentre nei template engine e implicita nella struttura del markup.

Quando usare il Composite Pattern

Usa il Composite quando i dati hanno una struttura ad albero naturale (menu, filesystem, organizzazioni, preventivi, UI)
Usa il Composite quando vuoi trattare singoli elementi e gruppi di elementi allo stesso modo
Usa il Composite quando le operazioni devono propagarsi ricorsivamente nella gerarchia
Non usare il Composite se la struttura e piatta: non forzare un albero dove basta una lista
Non usare il Composite se foglie e compositi hanno comportamenti radicalmente diversi: il Composite funziona quando l'interfaccia comune ha senso per entrambi

Il Composite Pattern trasforma la complessità strutturale in semplicità d'uso: una gerarchia di qualsiasi profondita si usa come un singolo oggetto. E uno dei pattern che meglio dimostrano come la ricorsione e il polimorfismo, combinati, possano gestire complessità che sembrerebbe richiedere logica ad hoc.

👉 Leggi l'articolo completo su iadicola.it

Iterator Pattern: attraversare collezioni senza esporne la struttura

Dev-Iadicola — Sat, 01 Aug 2026 17:00:13 +0000

Il problema: attraversamento accoppiato alla struttura

Hai una classe UserCollection che internamente usa un array PHP. Il codice client fa for ($i = 0; $i < $collection->count(); $i++) { $user = $collection->getAt($i); ... }. Funziona, ma il client sa che la collezione e indicizzata per posizione. Se domani la struttura interna cambia — un albero, una linked list, un result set paginato dal database — il codice client si rompe.

Il problema e l'accoppiamento tra attraversamento e struttura. Chi usa la collezione non dovrebbe sapere come e organizzata internamente. Dovrebbe solo poter dire "dammi il prossimo elemento" fino a che non ce ne sono più. L'Iterator Pattern formalizza questa separazione.

Cos'e l'Iterator Pattern: definizione formale

Il Gang of Four definisce l'Iterator come un pattern comportamentale che "fornisce un modo per accedere sequenzialmente agli elementi di un oggetto aggregato senza esporne la rappresentazione sottostante". La struttura prevede:

Iterator: l'interfaccia con metodi come current(), next(), hasNext(), rewind()
ConcreteIterator: implementa l'attraversamento per una struttura dati specifica
Aggregate: l'interfaccia della collezione con un metodo createIterator()
ConcreteAggregate: la collezione che crea il proprio iteratore

In PHP, il pattern e talmente fondamentale da essere integrato nel linguaggio: le interfacce Iterator e IteratorAggregate di SPL permettono a qualsiasi oggetto di essere usato in un foreach. Se la tua classe implementa Iterator, il foreach funziona automaticamente — il linguaggio stesso usa l'Iterator Pattern.

Esempio teorico: paginazione trasparente dal database

Immagina di dover processare 100.000 utenti dal database. Caricarli tutti in memoria e impraticabile: servirebbero gigabyte di RAM. La soluzione e un PaginatedUserIterator che carica gli utenti a blocchi di 1.000:

Il costruttore riceve la query base e la dimensione del blocco
current() restituisce l'utente corrente dal blocco caricato
next() avanza al prossimo utente; quando il blocco finisce, carica il blocco successivo dal database
valid() restituisce false quando non ci sono più blocchi

Il codice client e un semplice foreach ($users as $user) — non sa e non deve sapere che sotto il cofano stanno avvenendo 100 query da 1.000 record ciascuna. La memoria usata e costante (1.000 oggetti alla volta), indipendentemente dal numero totale di utenti. Questo e il potere dell'Iterator: disaccoppia il "cosa fare con ogni elemento" dal "come ottenere il prossimo elemento".

Generator PHP: Iterator senza boilerplate

PHP offre i generator come zucchero sintattico per creare Iterator senza implementare l'intera interfaccia. Un generator e una funzione che usa yield invece di return:

function paginatedUsers(int $chunkSize): Generator { $offset = 0; while ($chunk = fetchUsersChunk($offset, $chunkSize)) { foreach ($chunk as $user) { yield $user; } $offset += $chunkSize; } }

Il generator produce un oggetto Generator che implementa Iterator. Il foreach (paginatedUsers(1000) as $user) funziona identicamente all'esempio precedente, ma con 6 righe invece di una classe intera. I generator sono la forma moderna dell'Iterator Pattern in PHP.

Lazy evaluation: calcolare solo cio che serve

I generator sono lazy per natura: producono il valore successivo solo quando richiesto. Se il foreach fa break dopo 10 elementi, il generator non carichera mai gli altri 99.990. Questa lazy evaluation e impossibile con un array: array_map e array_filter processano sempre l'intera collezione, anche se serve solo il primo risultato.

La combinazione di generator e yield from permette di comporre iteratori: un generator che filtra, uno che trasforma, uno che limita — ogni step e lazy e la pipeline processa un elemento alla volta, senza mai tenere l'intera collezione in memoria.

Esempio teorico: file processing riga per riga

Un file CSV di 2 GB non può essere caricato in memoria con file(). Un CsvIterator apre il file, legge una riga alla volta con fgets(), la parsa e la yielda. Il codice client fa foreach (new CsvIterator('data.csv') as $row) e processa 2 GB di dati con 10 KB di memoria.

Questo approccio si combina con i generator per creare pipeline di trasformazione:

readCsv('data.csv') — generator che produce righe grezze
filterActive($rows) — generator che filtra solo le righe con status attivo
mapToEntity($rows) — generator che trasforma array in oggetti
batchInsert($entities, 500) — generator che raggruppa in batch e inserisce nel database

Ogni step processa un elemento alla volta. L'intero file da 2 GB viene processato con un consumo di memoria costante. Senza l'Iterator Pattern (e i generator come sua implementazione moderna), questo sarebbe impossibile o richiederebbe codice molto più complesso.

Iterator e interfacce SPL in PHP

PHP offre diverse interfacce e classi nell'estensione SPL per casi d'uso specifici:

FilterIterator: wrappa un iteratore e restituisce solo gli elementi che soddisfano una condizione
LimitIterator: wrappa un iteratore e restituisce solo i primi N elementi
AppendIterator: concatena più iteratori in una sequenza unica
RecursiveIteratorIterator: attraversa strutture ricorsive (alberi di directory, menu annidati)
CachingIterator: aggiunge lookahead — sai se c'e un elemento successivo prima di avanzare

Queste classi si compongono come Decorator: new LimitIterator(new FilterIterator(new ArrayIterator($data)), 0, 10) crea un iteratore che filtra e limita a 10 risultati. E OOP puro, senza un singolo for nel codice client.

Quando usare l'Iterator Pattern

Usa l'Iterator quando la struttura dati e complessa (alberi, grafi, risultati paginati) e vuoi nasconderla al client
Usa l'Iterator quando i dati sono troppi per stare in memoria e servono lazy loading o streaming
Usa l'Iterator quando vuoi comporre pipeline di trasformazione senza allocare array intermedi
Usa i Generator come implementazione moderna quando non serve un'intera classe Iterator
Non usare l'Iterator se hai un semplice array PHP: il foreach su array e già ottimale
Non usare l'Iterator se hai bisogno di accesso random (per indice): l'Iterator e sequenziale per definizione

L'Iterator Pattern e così fondamentale che ogni linguaggio moderno lo integra nella propria sintassi. In PHP, il foreach e l'Iterator Pattern reso trasparente. Ma capire il pattern dietro il costrutto sintattico permette di crearne di nuovi — iteratori lazy, paginati, filtrati — che risolvono problemi reali con eleganza e efficienza.

👉 Leggi l'articolo completo su iadicola.it

Dependency Injection: il pattern che rende tutto il resto possibile

Dev-Iadicola — Fri, 31 Jul 2026 17:00:13 +0000

Il problema: classi che creano le proprie dipendenze

Una classe OrderService ha bisogno di un OrderRepository per accedere ai dati e di un Mailer per inviare conferme. L'approccio più istintivo e crearli internamente: $this->repository = new PgsqlOrderRepository() e $this->mailer = new SmtpMailer(). Sembra semplice, ma ha conseguenze profonde.

Primo: OrderService e accoppiato al cemento. Sa che il repository e PostgreSQL e il mailer e SMTP. Se vuoi usare MySQL o un mock per i test, devi modificare OrderService. Secondo: non puoi testare OrderService senza un database e un server SMTP reali. Terzo: se PgsqlOrderRepository a sua volta crea le proprie dipendenze, hai una catena di creazione che nessuno controlla centralmente. Ogni classe e responsabile di crearsi il proprio mondo — e questo rende il sistema rigido, fragile e difficile da testare.

Cos'e la Dependency Injection

La Dependency Injection (DI) e un principio semplice: una classe non crea le proprie dipendenze, le riceve dall'esterno. Invece di $this->repository = new PgsqlOrderRepository(), il costruttore dichiara: public function __construct(private readonly OrderRepositoryInterface $repository, private readonly MailerInterface $mailer). Chi crea OrderService decide quale implementazione passare.

La DI non e un framework, non e un container, non e una libreria. E un principio di design: le dipendenze vengono iniettate, non create internamente. Esistono tre forme:

Constructor Injection: le dipendenze vengono passate nel costruttore. E la forma preferita perché rende le dipendenze esplicite e immutabili: la classe non può esistere senza le sue dipendenze.
Setter Injection: le dipendenze vengono passate tramite metodi setter. Utile per dipendenze opzionali, ma rende possibile l'uso della classe in uno stato incompleto.
Method Injection: la dipendenza viene passata come parametro del metodo che la usa. Utile quando la dipendenza varia ad ogni chiamata.

Esempio teorico: un servizio ordini testabile

Senza DI, testare OrderService richiede un database reale con dati di test e un server SMTP (o un mock complesso). Con DI, il test crea implementazioni fake:

InMemoryOrderRepository: implementa OrderRepositoryInterface con un array PHP. save() aggiunge all'array. findById() cerca nell'array. Zero database, zero latenza.
SpyMailer: implementa MailerInterface registrando ogni email in un array interno. Il test verifica: $this->assertCount(1, $mailer->getSentEmails()). Zero SMTP, zero email reali.

Il test diventa: $service = new OrderService(new InMemoryOrderRepository(), new SpyMailer()); $service->cancel($orderId); $this->assertTrue(...). E un test unitario puro: testa la logica di cancellazione senza dipendenze esterne, senza database, senza rete. Gira in millisecondi.

Il test dice la verità sul design

Se una classe e difficile da testare, quasi sempre e perché le dipendenze non sono iniettate. Il test e il primo "utente" della classe, e se l'utente fa fatica, il design ha un problema. La DI non e un requisito per il testing — e un requisito per il buon design, e il testing e la prova empirica.

Il Container: automazione della DI

Con la DI manuale, chi crea OrderService deve conoscere tutte le sue dipendenze e le dipendenze delle dipendenze. In un'applicazione con 50 classi, questa catena diventa lunga e ripetitiva. Il DI Container automatizza la risoluzione:

Registri le associazioni: OrderRepositoryInterface → PgsqlOrderRepository
Il container legge il costruttore di OrderService via Reflection
Vede che serve un OrderRepositoryInterface, lo risolve a PgsqlOrderRepository
Crea ricorsivamente tutte le dipendenze necessarie
Restituisce un OrderService completamente assemblato

Il container e un lusso, non una necessita. Per progetti piccoli, la DI manuale (creare gli oggetti nel bootstrap) e perfettamente valida. Per progetti con decine di servizi e dipendenze profonde, il container elimina il boilerplate di assemblaggio.

DI e il Dependency Inversion Principle

La Dependency Injection e la tecnica. Il Dependency Inversion Principle (la D di SOLID) e il principio: "i moduli di alto livello non dovrebbero dipendere da moduli di basso livello. Entrambi dovrebbero dipendere da astrazioni." La DI e il meccanismo pratico per realizzare questo principio.

Senza DI, OrderService (alto livello) dipende da PgsqlOrderRepository (basso livello). Con DI, OrderService dipende da OrderRepositoryInterface (astrazione), e PgsqlOrderRepository implementa quell'astrazione. La direzione della dipendenza si e invertita: il modulo di basso livello dipende dall'astrazione definita dal modulo di alto livello, non viceversa.

Errori comuni con la DI

Service Locator: iniettare il container stesso e usarlo per risolvere le dipendenze a runtime. Nasconde le dipendenze reali e rende il codice opaco. Le dipendenze devono essere nel costruttore, non risolte a runtime.
Troppe dipendenze: se un costruttore ha 8 parametri, il problema non e la DI — e che la classe ha troppe responsabilità. La DI rende visibile il problema, non lo causa.
Interfacce inutili: creare un'interfaccia per ogni classe "perché la DI lo richiede" e cargo cult. L'interfaccia serve quando ci sono (o ci saranno realisticamente) multiple implementazioni. Una UserRepositoryInterface con una sola implementazione e burocrazia — a meno che non serva per il testing, e allora ha un motivo concreto.
Auto-wiring magico: affidarsi ciecamente alla risoluzione automatica del container rende invisibili le dipendenze. E comodo ma va bilanciato con la leggibilità.

Quando usare la Dependency Injection

Sempre per le dipendenze di servizio (repository, mailer, logger, cache): sono le dipendenze che cambiano tra ambienti (produzione, test, staging)
Sempre quando vuoi che la classe sia testabile con mock o fake
Non necessaria per value objects e DTO: creare un new Money(100, 'EUR') internamente e perfettamente valido
Non necessaria per factory di oggetti semplici: non serve iniettare una factory se la creazione e banale

La Dependency Injection non e un pattern opzionale da adottare quando si diventa esperti: e il fondamento che rende possibili tutti gli altri pattern. Strategy, Repository, Observer, Decorator — tutti funzionano perché le dipendenze sono iniettate, non create internamente. Senza DI, i pattern diventano rigidi e non sostituibili. Con DI, diventano componenti intercambiabili di un sistema flessibile.

👉 Leggi l'articolo completo su iadicola.it