Che cosa è considerato codice di terze parti?

I tuoi esempi sono tutti codici di terze parti, ma non dovresti scrivere wrapper per loro. Sono progetti grandi e maturi con API stabili e ben pianificate.

La necessità di wrapper è di fornire un livello di astrazione tra il codice e la libreria. Hai solo bisogno di questa astrazione quando scopri che una libreria non fornisce buone API per la specifica cosa che stai facendo. Quindi puoi creare il wrapper per semplificare il tuo codice e nascondere il fatto che le chiamate API sono scomode.

Il tuo codice sarà testabile se utilizzi l'iniezione di dipendenza. Nei test delle tue unità puoi sostituire la dipendenza della biblioteca con un oggetto fittizio, permettendoti di isolare il tuo codice sotto test.

L'obiettivo di avvolgere una libreria è di rompere la dipendenza del proprio codice su quella libreria per abilitare:

• Test delle unità: devi essere in grado di testare il tuo codice. Se una libreria non ti permette di prendere in giro le classi o forzare le risposte che ti servono per il test, allora dovrai avvolgere quella libreria. Questo è un problema ovvio, e probabilmente non è il caso che ti stai chiedendo.
• Modifica delle implementazioni - In qualità di autore del codice, è necessario comprendere le modifiche che probabilmente stanno arrivando e quanto costano queste modifiche per prepararsi rispetto a quanto sono probabili. Puoi passare da .NET a JVM? È difficile e improbabile; tuttavia, è molto probabile che cambi le tecnologie dell'interfaccia utente in futuro o i motori XML.

L'isolamento di librerie e framework di terze parti è solo un sottoinsieme di isolamento delle modifiche.

Non tratterò i membri della libreria standard come codice di terze parti - dopotutto sono standard e si può ragionevolmente presumere che siano disponibili e funzionanti sulla piattaforma che stai utilizzando.

Per quanto riguarda qualcosa come Zend, penso che uno non lo avvolgerebbe - probabilmente avresti bisogno di riscrivere il programma se hai preso un framework diverso. Per essere onesti, non vorrei avvolgere molto che non fosse una seria dipendenza dalla configurazione esterna o se non stavo davvero pensando di rendere quel pezzo scambiabile.

Considererei le librerie fornite da un linguaggio di programmazione specifico solo come parte della lingua.

Quindi, considererei terze parti, tutte le librerie fornite da qualsiasi altra entità come un'estensione o uno strumento separato dal linguaggio di programmazione stesso.

Prendendo il tuo esempio, considererei Zend una terza parte. Vorrei anche costruire la mia applicazione in modo che la mia logica di business principale non dipendesse da Zend.

Wikipedia definisce componente di terze parti come:

In computer programming, a third-party software component is a reusable software component developed to be either freely distributed or sold by an entity other than the original vendor of the development platform.

Nel senso più stretto, ogni esempio che hai dato è un codice di terze parti. Tuttavia, non tutti i codici di terze parti devono essere inclusi. Tutte le librerie di terze parti dovrebbero essere incluse. I framework, per definizione, non possono essere incapsulati perché diventano parte integrante del tuo codice. Questo è il motivo per cui dovresti avvolgere la tua libreria di logging, ma non il framework .NET o il framework Zend. Non puoi davvero separare il tuo codice da .NET - sono intrecciati. Ovviamente, i framework validi avranno interfacce da programmare contro, consentendo di bypassare il problema in una certa misura.

Vedi anche: link