Cosa è considerato codice di terze parti?

15

Ispirato a questa domanda Utilizzo di librerie di terze parti: utilizzare sempre un wrapper? Volevo sapere che cosa la gente considera effettivamente come librerie di terze parti.

Esempio da PHP:
se sto creando un'applicazione utilizzando Zend framework, dovrei trattare le librerie del framework Zend come codice di terze parti?

Esempio da C #:
se sto creando un'applicazione desktop, dovrei trattare tutte le classi .Net come codice di terze parti?

Esempio da Java:
dovrei trattare tutte le librerie in JDK come librerie di terze parti?

Alcune persone dicono che se una libreria è stabile e non cambierà spesso, non è necessario avvolgerla. Tuttavia non riesco a vedere come si testerebbe una classe che dipende da un codice di terze parti senza racchiuderlo.

— Songo
fonte

8

Il voto negativo può spiegare perché?

— Songo,

Ho sentito parlare di software di terze parti, ma non di codice di terze parti. La maggior parte delle terze parti non ti fornisce il proprio codice sorgente.

— Tulains Córdova,

18

I tuoi esempi sono tutti codice 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 uno strato di astrazione tra il codice e la libreria. Hai bisogno di questa astrazione solo quando scopri che una libreria non fornisce buone API per la cosa specifica che stai facendo. Quindi potresti creare il wrapper per semplificare il tuo codice e nascondere il fatto che le chiamate API sono scomode.

Il tuo codice sarà testabile se usi l'iniezione di dipendenza. Nei test delle unità è possibile scambiare la dipendenza della libreria con un oggetto simulato, che consente di isolare il codice in prova.

— M. Dudley
fonte

+1 per spiegare quando può essere necessario un involucro o una facciata, se lo desideri.

— Joshua Drake,

Grazie per la risposta, ma per quanto riguarda l'ultimo paragrafo sui test unitari potresti dare un'occhiata a questa domanda in cui sto provando a testare un'unità di una classe che ha una dipendenza diretta da un framework di librerie?

— Songo,

@Songo: la tua strategia di test dovrebbe essere quella di creare un Zend_Mailfinto che passi al tuo Loggeroggetto sotto test. PHP non supporta la tipizzazione anatra? Se è così, non dovrebbe essere banale creare un oggetto finto ...? Non conosco davvero PHP, ma potresti guardare esempi dalle librerie beffardo di PHP per vedere come è fatto in genere. In lingue che non supportano la tipizzazione duck, penso che dovresti passare Zend_Maila un'interfaccia e quindi creare un wrapper sottile che implementa l'interfaccia ed eredita Zend_Mailo delega semplicemente tutte le sue chiamate.

— M. Dudley,

@emddudley, sì, ma stavo cercando una soluzione più generale al problema in altre lingue che non supporta la dattilografia. In realtà la tua soluzione per avvolgere Zend_Mailera il mio primo pensiero, ma come puoi vedere nel mio post originale prima di modificarlo ho usato un'interfaccia e un wrapper che lo implementano. Tuttavia, l'unico scopo del wrapper è quello di poter deridere la sua interfaccia. È comune nelle lingue che non supportano la tipizzazione anatra? Costruire un numero infinito di involucri, intendo?

— Songo,

@Songo: penso che sia molto specifico per la lingua e la libreria e devi accontentarti di qualunque cosa la tua piattaforma supporti. A volte potresti essere bloccato con la scrittura di involucri. L'iniezione di dipendenza e il derisione di oggetti sono sviluppi abbastanza recenti (2004?), Quindi non tutte le lingue e le biblioteche li supportano molto bene. La "soluzione generale" che stai cercando è solo una mentalità: come puoi progettare il tuo codice per accoppiamento lento e test unitari efficaci?

— M. Dudley,

6

L'obiettivo del wrapping di una libreria è di interrompere la dipendenza del proprio codice da quella libreria per consentire:

Test unitario - Devi essere in grado di testare il tuo codice. Se una libreria non ti consente di deridere le classi o forzare le risposte di cui hai bisogno per il tuo test, dovrai avvolgere quella libreria. Questo è un problema ovvio, e probabilmente non è il caso che ti stai chiedendo.
Implementare le modifiche: come autore del codice è necessario comprendere le modifiche che probabilmente stanno arrivando sulla tua strada e quanto costeranno queste modifiche per prepararle rispetto alla loro probabilità. Puoi passare da .NET a JVM? È difficile e improbabile; tuttavia, è molto probabile che tu cambi le tecnologie dell'interfaccia utente in futuro o i motori XML.

L'isolamento di librerie e framework di terze parti è solo un sottoinsieme dell'isolamento del cambiamento.

— Ben
fonte

Ottimo punto sui test unitari. Non sto dicendo sempre a capo per poter testare l'unità sulla tua applicazione, ma è una buona strategia per disaccoppiare le dipendenze quando necessario.

— Sergio Acosta,

2

Non tratterei i membri della libreria standard come un codice di terze parti - dopo tutto sono standard e si può ragionevolmente presumere che siano disponibili e funzionali sulla piattaforma che si sta utilizzando.

Per quanto riguarda qualcosa come Zend, penso che non lo avremmo avvolto - probabilmente avresti bisogno di riscrivere il programma se prendessi un framework diverso. Ad essere sincero, non vorrei concludere molto che non fosse una seria dipendenza dalla configurazione esterna o se non avessi davvero intenzione di rendere quel pezzo sostituibile.

— Wyatt Barnett
fonte

2

Considererei le biblioteche fornite da un linguaggio di programmazione specifico solo parte del linguaggio.

Pertanto, considererei terzi, 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. Costruirò anche la mia applicazione in modo tale che la mia logica di business principale non dipenda da Zend.

Wikipedia definisce il componente di terze parti come:

Nella programmazione informatica, un componente software di terze parti è un componente software riutilizzabile sviluppato per essere distribuito o venduto liberamente da un'entità diversa dal fornitore originale della piattaforma di sviluppo.

— Patkos Csaba
fonte

1

Nel senso più stretto, ogni esempio che hai dato è un codice di terze parti. Tuttavia, non tutto il codice di terze parti dovrebbe essere racchiuso. Tutte le librerie di terze parti dovrebbero essere raggruppate. I frame, per definizione, non possono essere raggruppati perché diventano parte integrante del tuo codice. Ecco perché dovresti avvolgere la tua libreria di log, ma non il framework .NET o il framework Zend. Non puoi davvero separare il tuo codice da .NET: sono intrecciati. Naturalmente, i buoni framework avranno interfacce su cui programmare, che ti consentiranno di aggirare il problema in una certa misura.

Vedi anche: /programming/148747/what-is-the-difference-between-a-framework-and-a-library

— Michael
fonte