Adapter Pattern: come rendere compatibili interfacce diverse senza toccare il codice esistente

È proprio questo il contesto in cui nasce l’Adapter Pattern: risolvere incompatibilità tra interfacce senza modificare il codice esistente.

I tre elementi chiave del pattern

Il pattern è semplice, ma molto preciso nella struttura. Si basa su tre elementi fondamentali:

• Target: l’interfaccia che il client si aspetta
• Adaptee: il componente esistente, con un’interfaccia incompatibile
• Adapter: l’oggetto che traduce le chiamate tra Target e Adaptee

Il client lavora sempre con il Target. Non conosce l’Adaptee. È l’Adapter che si occupa di collegare i due mondi.

Come funziona davvero

Il funzionamento è diretto: l’Adapter implementa l’interfaccia del Target e, al suo interno, richiama i metodi dell’Adaptee adattando parametri, formato o logica.

In pratica:

• il client invoca un metodo standard
• l’adapter intercetta la chiamata
• traduce la richiesta
• delega l’esecuzione all’adaptee

Tutto avviene senza modificare il codice originale.

Questo è il punto chiave: il pattern lavora per composizione, non per modifica.

Un esempio tipico

Immagina un sistema che si aspetta un metodo request().

Hai però una classe già esistente che espone un metodo diverso, ad esempio specificRequest().

Non puoi cambiare il client. Non vuoi modificare la classe esistente.

L’adapter fa esattamente questo:

• espone request()
• al suo interno chiama specificRequest()
• restituisce il risultato nel formato atteso

Il client continua a funzionare senza sapere nulla della differenza.

Perché non modificare direttamente il codice

La soluzione più immediata sarebbe cambiare una delle due parti. Ma questo introduce problemi:

• rompe codice già testato
• aumenta il rischio di regressioni
• crea dipendenze non necessarie
• rende più difficile mantenere il sistema

L’Adapter evita tutto questo. Isola il problema in un unico punto.

Se qualcosa cambia, si interviene lì.

Quando usarlo davvero

L’Adapter Pattern è utile in situazioni molto concrete:

• quando integri una libreria esterna con interfaccia diversa
• quando lavori con sistemi legacy che non puoi modificare
• quando devi riutilizzare codice esistente in un nuovo contesto
• quando più componenti devono essere uniformati sotto una stessa interfaccia

In tutti questi casi, il pattern evita modifiche invasive.

Il vantaggio reale: disaccoppiare senza riscrivere

Il valore dell’Adapter non è teorico. È pratico.

Permette di:

• mantenere il codice esistente intatto
• ridurre l’impatto delle integrazioni
• separare responsabilità diverse
• semplificare l’evoluzione del sistema

Non è un pattern elegante per definizione, bensì un pattern utile quando serve davvero.

Quando diventa un problema

Come tutti i pattern, può essere abusato.

Non ha senso introdurlo se:

• puoi modificare facilmente una delle due interfacce
• il sistema è piccolo e non richiede flessibilità
• stai aggiungendo complessità senza un reale bisogno

Ogni adapter è un livello in più. Va usato quando risolve un problema concreto, non per struttura.

Una soluzione semplice a un problema comune

L’Adapter Pattern esiste perché il problema che risolve è molto comune: far dialogare sistemi che non sono stati progettati per farlo. Invece di forzare il cambiamento, introduce un punto di mediazione.

E nella maggior parte dei progetti reali, è esattamente quello che serve: far funzionare le cose senza rompere ciò che già funziona.