Sta evitando che i campi che rappresentano lo stesso oggetto in diverse classi di comunicazione siano ragionevoli?

Question

Sta evitando che i campi che rappresentano lo stesso oggetto in diverse classi di comunicazione siano ragionevoli?

#1 da (1 voti)
#2 da (0 voti)

5

Sto sviluppando un programma che comunica con diversi tipi di dispositivi (con i rispettivi protocolli). Dovrebbe contemporaneamente acquisire i messaggi dai dispositivi e scriverli in un file con un formato specifico. Il tempismo è molto severo, quindi si decide di essere implementato come 2 thread: uno riceve i messaggi dal dispositivo e il secondo li scrive. L'oggetto comune per entrambi i thread è una coda di messaggi.

C'è una discussione DeviceHandler , che avvia il thread di acquisizione DeviceDriver . A mio parere, messageQueue oggetto dovrebbe appartenere a DeviceHandler ed è ridondante per essere a DeviceDriver e aumenta l'accoppiamento. Ho deciso di passarlo al metodo DeviceDriver acquire che dovrebbe iniziare questo thread, ma non so come combinarli entrambi senza creare messageQueue una variabile di istanza.

Inoltre, dal momento che ottenere messaggi da dispositivi è un compito importante, gli implementatori di DeviceDriver usano i propri richiedenti messaggi, che a loro volta dovrebbero in qualche modo ottenere la coda e in effetti riempirla di messaggi. Lo stesso problema qui. Inoltre, a causa dei dettagli di implementazione, DeviceBDriverRequestor potrebbe essere eseguito come thread.

Quindi ho delle domande:

Ho ragione di evitare di rendere messageQueue una variabile di istanza di DeviceDriver? O è accettabile averlo ovunque?
Quale sarebbe un buon modo per implementare la classe DeviceDriver (combinazione di metodi run() e acquire(Queue messageQueue) ) in un modo che ho proposto?
Ci sono forse delle buone pratiche nell'affrontare tali situazioni?

Grazie in anticipo!

coding-style design java coupling

posta miuser 10.11.2016 - 15:57

fonte

2 risposte

Leggi altre domande sui tag coding-style design java coupling

Oggetto dominio framework entità come oggetto business Modo più sicuro di utilizzare e archiviare le credenziali di terze parti dell'utente

score 1 · Answer 1

A differenza di C in cui non è possibile avviare una discussione con più argomenti (pthread void ** param: D), il thread Java consente solo di eseguire il metodo run senza argomenti. (vedi link grazie a @RobertHarvey).

Non hai scelta di usare il campo per passare il parametro a un Thread.

Tuttavia è possibile disaccoppiare DeviceDriver dal suo aspetto di thread, dal momento che sul lato astratto, DevideDriver non è necessariamente un thread.

Quindi puoi spostare il metodo run() di DeviceDriver in DeviceDriverThread e aggiungere un metodo eseguito (coda MessageQueue) a DeviceDriver

Questo DeviceDriverThread avrà come campi MessageQueue e il concreto DeviceDriver da eseguire e questo metodo eseguirà quanto segue:

private MessageQueue queue;
private DeviceDriver deviceDriver;
public void run(){
     deviceDriver.run(queue);
}

Suppongo che avrai bisogno anche del metodo stop in DevideDriverThread .

Pensa ad esso come a un semplice motivo dell'adattatore.

score 0 · Answer 2

Perché non nascondi la coda all'interno di DeviceDriver e esponi i metodi necessari ( get , clear , qualsiasi cosa) dalla delega thread-safe?

In questo modo l'utente della tua classe DeviceDriver non si preoccuperà della sua realizzazione e utilizzerà solo ciò che è effettivamente necessario, e il tuo DeviceDriver non avrà dipendenza non necessaria.