Quando si progettano le interfacce di input per una libreria, quando utilizzare la classe di dati piuttosto che l'interfaccia dati?

Question

Quando si progettano le interfacce di input per una libreria, quando utilizzare la classe di dati piuttosto che l'interfaccia dati?

#1 da (2 voti)

0

Diciamo che le librerie A, B e C sono tutte librerie matematiche personalizzate. Possono o non possono usare gli stessi tipi di dati. Le librerie hanno metodi che accettano input di tipo di dati come ProcessAsync(DataTypeA) o ClusterByFeature(IDataTypeB, Func<IDataTypeB, double>) .

Queste librerie saranno sviluppate per modularità. Per esempio. I futuri studenti laureati possono venire e utilizzare la biblioteca per i loro bisogni.

Ho pensato che queste librerie dovessero:

o forniscono implementazioni concrete degli input che accettano e manipolano, come DataTypeA , DataTypeB , DataTypeC
oppure, chiedi agli utenti di fornire un oggetto di tipo IDataTypeA , IDataTypeB , IDataTypeC

Quale design dovrei scegliere dipende da molti fattori.

Ne ho trovati alcuni:

Se è solo un contenitore, dovrebbe essere un'interfaccia
Se DataTypeA , DataTypeB , DataTypeC sono tutti molto simili, usa le interfacce - lascia che il framework invocante fornisca l'implementazione ereditando tutte le interfacce
Se DataTypeA richiede operazioni complicate, usa le classi
Se DataTypeA richiede operazioni semplici , utilizza le interfacce e una classe DataTypeAManipulator

Vedo che altre librerie open source utilizzano prevalentemente classi invece di interfacce, quindi penso che le classi dovrebbero essere la strada da percorrere. Ma non c'è spazio per le interfacce dati?

-

Un esempio migliore del problema che ho dovuto affrontare: C'è un oggetto 3D che deve essere manipolato. La libreria A gestisce i vertici, la Libreria B gestisce i vertici e la deformazione delle articolazioni ossee, la Libreria C gestisce i vertici e la mappatura delle trame. 3 diversi oggetti dati: sono in realtà viste differenti di un singolo oggetto dati, ma le librerie non lo dovrebbero / non dovrebbero saperlo! Quindi dovrei usare le interfacce dati per mostrare diverse prospettive di un oggetto 3D, oppure copiare i valori in classi di dati.

object-oriented interfaces

posta Cardin 15.10.2015 - 08:31

fonte

1 risposta

Leggi altre domande sui tag object-oriented interfaces

Il formattatore dovrebbe fare la convalida? Come gestire le traduzioni in JSON? [chiuso]

score 2 · Answer 1

Le classi di dati hanno senso quando vengono utilizzate come contenitore per i dati (un POCO in .NET o POJO in Java). Non contengono alcun comportamento e servono semplicemente per incapsulare i dati e semplificare il codice, ad esempio:

int CalculateSurface(int x1, int y1, int x2, int y2)

vs

int CalculateSurface(Rect area)

Quando passi una classe di dati, puoi effettivamente scrivere il metodo in modo da prendere gli argomenti separatamente. Ovviamente NON VUOI farlo perché è un serio ingannare il tuo codice, ma potresti farlo.

Una interfaccia dati ha senso quando hai effettivamente bisogno di logica o comportamento, il che significa che i metodi sull'oggetto passato devono essere implementati. Ha anche senso quando vuoi che l'oggetto su cui stai lavorando esegua qualche operazione e devi passargli un parametro, nel qual caso hai bisogno di un contratto per questo metodo, quindi un'interfaccia.