Un wrapper Java attorno all'API di un prodotto di terze parti deve essere confezionato come bean?

Question

Un wrapper Java attorno all'API di un prodotto di terze parti deve essere confezionato come bean?

#1 da (-1 voti)

0

Per motivi di uso personale e per motivi didattici, voglio creare un wrapper Java attorno all'API web di un determinato servizio. Cioè, non è necessario alcun software aggiuntivo per usarlo su un computer client - solo il mio codice.

Voglio anche rendere quel wrapper riutilizzabile ed eventualmente utilizzato da altre persone che potrebbero voler accedere a quel servizio dal codice Java.

Quindi la mia domanda è: esiste una pratica comune o un modello di progettazione standard per i casi come il mio che afferma che tali wrapper sono imballati in un bean Java e usati di conseguenza? Oppure tale software è tipicamente distribuito sotto forma di codice sorgente e compilato come parte del progetto che lo utilizza?

api-design java web-api wrapper

posta Semisonic 08.02.2017 - 20:34

fonte

1 risposta

Leggi altre domande sui tag api-design java web-api wrapper

Round robin, bilanciato casa / fuori, più posizioni con opzioni multi-team La lettura su codice che ho scritto ha senso verificarla?

score -1 · Answer 1

IMHO che fornisce wrapper su servizi / dipendenze di terze parti può essere vantaggioso in alcuni casi.

Uno di questi casi è dove il servizio di terze parti viene utilizzato estensivamente o in più moduli, pertanto potrebbe incorrere in un costo elevato per eseguire l'aggiornamento al servizio su più moduli, evitando così il blocco delle dipendenze.

Un altro caso può essere quando più servizi di terze parti forniscono funzionalità primarie simili, ma funzionalità secondarie competitive, e potrebbe esserci una possibilità che il fornitore del servizio possa essere cambiato durante la vita del progetto.

Il tuo wrapper può esporre funzionalità preziose per il tuo progetto e aggiungerne altre quando necessario, invece di esporre tutte le funzionalità dell'API di terze parti contemporaneamente. È più facile evolversi quando esponi funzionalità minori.

"When in doubt, leave it out" - Joshua Bloch

Nel mio caso (simile), ho esposto la funzionalità di archiviazione nella mia libreria interna per più progetti per memorizzare alcune strutture di dati interne, tuttavia la dipendenza dall'API di memorizzazione è nascosta nelle funzioni wrapper. Questo mi consente di cambiare facilmente il provider dell'API di archiviazione.