Che cos'è il pattern Adapter?

Question

Accepted Answer

Il pattern **Adapter** consente agli oggetti con **interfacce incompatibili** di lavorare insieme incapsulando uno con un'interfaccia che l'altro si aspetta. Agisce come traduttore tra due interfacce, consentendo l'integrazione senza modificare il codice esistente.

## Cosa fa il pattern Adapter

```text
ADAPTER → convert one interface into another that a client expects (a "translator"):
  → wrap an object whose interface is INCOMPATIBLE, exposing the interface the client needs
  → the adapter translates calls/data between the two interfaces
→ makes incompatible things work together WITHOUT changing either's code
```

## Esempio

```js
// a third-party library with an incompatible interface
class ThirdPartyLogger { logMessage(text) { /* ... */ } }

// our code expects a .log(msg) interface → adapt it
class LoggerAdapter {
  constructor(thirdParty) { this.logger = thirdParty; }
  log(msg) { this.logger.logMessage(msg); }   // translate our interface to theirs
}
const logger = new LoggerAdapter(new ThirdPartyLogger());
logger.log('hello');   // our code uses .log; the adapter calls .logMessage
```

## Usi e vantaggi

```text
USES → integrate THIRD-PARTY libraries with incompatible interfaces; make legacy code work
  with new code; unify different APIs behind a common interface; swap implementations
BENEFITS:
  ✓ INTEGRATION → make incompatible interfaces work together without modifying either
  ✓ DECOUPLING → your code depends on YOUR interface; adapters isolate external/incompatible
    code → swap or upgrade dependencies behind the adapter
  ✓ Reuse existing code that doesn't quite fit
```

## Perché è importante

Comprendere il pattern Adapter è prezioso perché è un **pattern strutturale molto comune e pratico** per integrare codice incompatibile, quindi è una conoscenza di design rilevante.

Il pattern Adapter consente agli oggetti con **interfacce incompatibili di lavorare insieme** incapsulando uno con l'interfaccia che l'altro si aspetta — agendo da traduttore tra le interfacce.

Comprendere cosa fa (incapsulare un oggetto con un'interfaccia incompatibile per esporre l'interfaccia che il client necessita, traducendo tra le due) è la conoscenza fondamentale.

Comprendere gli **usi** è particolarmente prezioso perché sono esigenze comuni e reali: **integrare librerie di terze parti** con interfacce incompatibili (una situazione frequente — è necessario utilizzare una libreria ma la sua interfaccia non corrisponde al tuo codice), far funzionare il **codice legacy con il codice nuovo**, unificare diverse API dietro un'interfaccia comune, e consentire lo scambio di implementazioni.

Queste esigenze di integrazione sorgono costantemente nello sviluppo reale.

Comprendere i **vantaggi** — **integrazione** (far funzionare insieme interfacce incompatibili senza modificarne nessuna, il che è spesso necessario quando non puoi modificare codice di terze parti o legacy), e **disaccoppiamento** (il tuo codice dipende dalla tua interfaccia mentre gli adapter isolano il codice esterno/incompatibile, quindi puoi scambiare o aggiornare le dipendenze dietro l'adapter — un vantaggio architetturale prezioso) — chiarisce perché Adapter è praticamente importante.

Il pattern Adapter è uno dei pattern più praticamente utili perché integrare codice incompatibile (librerie di terze parti, sistemi legacy, API diverse) è un'esigenza costante e reale nello sviluppo.

Poiché il pattern Adapter è un pattern molto comune e pratico per integrare interfacce incompatibili (librerie di terze parti, codice legacy, API diverse) senza modificare nessuna — un'esigenza reale costante — e fornisce un disaccoppiamento prezioso, e poiché comprendere cosa fa, i suoi usi e i suoi vantaggi è rilevante per il lavoro di integrazione reale, comprendere il pattern Adapter è una conoscenza di design preziosa e praticamente rilevante — un pattern frequentemente necessario per il compito comune di integrare codice incompatibile, fornendo integrazione e disaccoppiamento, e una conoscenza di design importante per la sfida ricorrente e reale di far funzionare insieme diverse parti di codice.