Best practice per la creazione di librerie che utilizzano spazi dei nomi .NET

Question

È una cattiva pratica scrivere una libreria che definisce un'interfaccia dipendente da un'altra libreria?

So che l'accoppiamento stretto è negativo, ma si applica ancora quando si utilizzano le classi .NET?

Ad esempio, in .NET, se si dispone di una libreria che restituisce un oggetto Color, imporrebbe una dipendenza su System.Drawing su qualsiasi cosa utilizzi la mia libreria. Sarebbe meglio creare la mia classe di tipo Color nella mia libreria?

Answer 1

distinguo tra Volatile e dipendenze stabili.

In generale, colori sembra una dipendenza stabile perché è già nel BCL, è deterministico in natura e non comporta alcun out-of comunicazione di processo molte risorse, e né si basa su un particolare set-up del suo ambiente di runtime.

L'unica considerazione qui è che quando si tratta di colori, ci sono più di una di queste classi nel BCL, quindi assicurati di voler veramente indirizzare solo le applicazioni Windows Form con la tua API, perché WPF ha una sua definizione di colore.

Se è sufficiente che il colore dipinga parti dell'interfaccia utente in un determinato colore, la classe di colori incorporata probabilmente è soddisfacente, ma se Colore è un concetto principale nel modello di dominio e è necessario scegliere come target diversi UI (WPF, Windows Forms, Web) probabilmente starai meglio definendo la tua astrazione.

In un caso più avanzato, è possibile creare successivamente adattatori e mappatori attorno all'astrazione per colmare il divario tra l'astrazione e le classi di colore concreti.

Answer 2

Se si tratta di una libreria .NET standard, non mi preoccuperei. Nessun motivo per mappare da una classe all'altra ... cosa succederebbe se System.Color fosse cambiato nella prossima versione di .NET? Dovresti cambiare anche il tuo codice di mappatura e possibilmente dover rilevare la versione e la mappa di conseguenza. È un vero dolore.

Answer 3

Con tutte le mie librerie, restituisco oggetti che dipendono solo da elementi presenti nella libreria.

Mi chiederei perché stavo scrivendo una libreria che dipenderebbe da un altro spazio dei nomi che non era implicito. Sembra andare contro l'intero concetto di "incapsulamento".

Quindi, semplicemente uscendo dal mio stesso ragionamento e conoscenza di OOP, direi che sei sulla strada giusta con la restituzione del tuo oggetto non dipendente.

Answer 4

Si pone una domanda eccellente. La risposta è, dipende. Nel caso di librerie standard che saranno sempre disponibili, allora va bene; la libreria di base fa riferimento a DLL diverse in ogni momento.

Nel caso di una libreria di terze parti si riscontrano problemi. Non è sempre una buona idea fare da soli se qualcos'altro fa ciò che vuoi, ma poi hai una dipendenza da un'altra libreria, che è un problema logistico per gli utenti.

Non c'è una risposta giusta qui, devi solo andare con ciò che ha più senso per il tuo progetto. Cerca di disaccoppiare il più possibile, sì, ma a volte devi solo coccolarti e fare il lavoro.

Answer 5

Dipende dall'utilizzo della classe.

Se è necessario ottenere un'istanza della classe Color di sistema da un'istanza della classe Color (ad esempio se si disegna su un modulo di Windows), sarebbe meglio usare la classe System - salva l'utente sforzo di dover convertire tra i due tipi e ti dà il vantaggio di essere in grado di utilizzare tutte le "Caratteristiche" della classe Color gratuitamente (come costanti incorporate per "Rosso", "Nero", "Verde" ecc. ..

Se d'altra parte si sta semplicemente lavorando con valori arbitrari RGB (forse per i calcoli scientifici) e mai necessità di convertire a un'istanza di System.Color, allora potrebbe avere senso per creare la propria classe

Con ogni probabilità si sta meglio usando la classe System.Color - sì incapsulamento e tutto ciò è una buona idea, ma non a scapito del risparmio di grandi quantità di tempo!

Answer 6

Non dovresti preoccuparti di utilizzare qualcosa nella libreria di base .NET. Non andresti molto lontano nello scrivere una DLL senza di essa. L'unico posto che potrebbe essere cauto attorno ad esso è lo spazio dei nomi System.Web come credo. NET 4 ha un programma di installazione del profilo del client che significa in sostanza che se si utilizza questo programma installerà solo le cose che dovrebbero essere utilizzate su un client. Personalmente ritengo che sia una cattiva idea su parte di Microsoft in quanto aggiunge solo complicazioni inutili per il salvataggio di una piccola quantità di tempo di download.