Come progettare la comunicazione dell'interfaccia tra gli oggetti?

Question

Come progettare la comunicazione dell'interfaccia tra gli oggetti?

#1 da (4 voti)

0

Sono bloccato su una domanda leggermente filosofica per me. Ho tre lezioni e non sono sicuro di come renderle correlate l'una con l'altra. Ho pochi approcci in competizione tutti in piedi su un piano uguale per me e non sono sicuro di quale abbia più svantaggi e vantaggi.

Ad esempio sto progettando un sistema in cui posso comandare un dispositivo (ei suoi sottodispositivi) tramite Communicator:

Dispositivo (ad esempio Computer)
Sottodispositivo (ad esempio mouse, tastiera, schermo)
Communicator (ad es. rete)

Device crea e trattiene oggetti Subdevice . E il dispositivo crea Communicator . Ora diciamo che c'è JSON che entra in Communicator e deve essere passato a ciascuno di Device 's Subdevice (ex parseJSON() metodo)

I I:

Crea Device::GetSubdevices() e per ogni Subdevice chiama parseJSON all'interno di Communicator o
Crea Device::onParsedJson chiamato da Communicator , dove I iterate e instrado a Subdevice
Fai qualcos'altro

La prima scelta sembra portare la responsabilità di Device a Communicator che non è buona. Ma la seconda scelta rende Device (+) gestire l'interfaccia responsabilmente (-) pollutes (anche se è interfacciata)

patterns-and-practices

posta edin-m 01.03.2016 - 02:59

fonte

1 risposta

Leggi altre domande sui tag patterns-and-practices

Perché ObservableCollection richiede che tutte le modifiche vengano apportate sul thread dell'interfaccia utente? Modo efficiente nel confrontare due liste

score 4 · Accepted Answer

JSON è una sintassi di trasferimento dati, e come tale dovrebbe essere catturata dall'interfaccia esterna ( Communicator , in questo contesto) e immediatamente trasformata in una sorta di classi / set di classi che il resto dell'applicazione può capisci, piuttosto che passare "sporco" (e proviene da una fonte esterna, è è sporco) in un formato subpar.

Quindi, mi sembra che il Communicator debba avere un metodo parseJson che analizza i dati in un insieme di classi appropriate per rappresentarlo, e quelle classi vengono quindi passate al resto del sistema per quanto esse saranno infine consumate .

(questo potrebbe non essere applicato molto se si utilizza JSON come formato dati principale per l'intera applicazione e tutte le classi interne sono configurate per affrontarla, ma francamente è una scelta strana ... e anche così , i dati provenienti da un luogo esterno devono sempre essere scrubati / convalidati in un formato / schema noto prima di essere trasferiti comunque nelle classi interne, quindi rimane la posizione di gestire Communicator (o un adattatore appropriato in quel contesto), IMO )