Il wrapping di API API di terze parti è un odore di progettazione?

In realtà, penso che avvolgere o isolare le API di terze parti in uno strato "shim" sia un buon design. Ci sono un certo numero di vantaggi nel fare questo.

Ad esempio, cosa succede se cambi i sistemi operativi assumendo che tu non stia sviluppando in ambiente gestito come .NET (che fornisce fondamentalmente lo strato di shim per te)? Se metti uno shim layer su tutte le chiamate di sistema come code di messaggi, mutex, ecc, questo processo è molto meno doloroso. Ho usato l'esempio del sistema operativo, perché ho fatto questo, ma si applica a qualsiasi tipo di modulo / libreria di codice "swap-able". Come altro esempio, supponiamo di utilizzare una libreria grafica e ad un certo punto decidere di cambiare fornitore. Lo strato di shim consente essenzialmente all'applicazione principale di funzionare in un numero di ambienti diversi, possibilmente senza altre modifiche oltre a ciò che lo shim layer sta effettivamente facendo. Questo è enormemente vantaggioso quando si sviluppano applicazioni multipiattaforma. Inoltre, tutto ciò che deve cambiare è in un punto conveniente.

Ti consiglierei di lasciare il tuo codice così com'è.

Tuttavia, ad esempio, se stai chiamando 20 diversi metodi nel codice di terze parti su 1000 righe del tuo codice, forse la creazione di uno strato sottile tra te e il tuo codice di terze parti potrebbe farti risparmiare (o qualcun altro) un po 'di dolore il futuro, nel caso in cui il codice di terze parti cambi e sia necessario aggiornare tutte le chiamate.

Il motivo per cui dovresti sempre racchiudere l'api è:

1. L'api che stai utilizzando è stata progettata per 50 diversi usi, mentre stai scegliendo solo uno di essi in uso. Quindi i prototipi di funzioni sembreranno notevolmente diversi perché l'ambito dei progetti è diverso.
2. Poiché puoi scegliere un ambito più piccolo, l'API avvolta è necessariamente molto più semplice e ottieni enormi vantaggi di astrazione avvolgendolo
3. Ovviamente copiare e incollare manualmente i prototipi non funzionerà. Devi effettivamente renderlo più semplice.

Descrive approssimativamente il modello di gateway . Nessun odore.

...Interesting software rarely lives in isolation. Even the purest object-oriented system often has to deal with things that aren't objects, such as relational data-base tables, CICS transactions, and XML data structures.

When accessing external resources like this, you'll usually get APIs for them. However, these APIs are naturally going to be somewhat complicated because they take the nature of the resource into account. Anyone who needs to under-stand a resource needs to understand its API - whether JDBC and SQL for rela-tional databases or W3C or JDOM for XML. Not only does this make the software harder to understand, it also makes it much harder to change should you shift some data from a relational database to an XML message at some point in the future.

The answer is so common that it's hardly worth stating. Wrap all the special API code into a class whose interface looks like a regular object. Other objects access the resource through this Gateway, which translates the simple method calls into the appropriate specialized API.