Evitar que os campos que representam o mesmo objeto em diferentes classes de comunicação sejam razoáveis?

Question

Evitar que os campos que representam o mesmo objeto em diferentes classes de comunicação sejam razoáveis?

#1 resposta do (1 votos)
#2 resposta do (0 votos)

5

Estou desenvolvendo um programa que faz comunicação com diferentes tipos de dispositivos (com os respectivos protocolos). Ele deve adquirir simultaneamente mensagens de dispositivos e gravá-las em um arquivo com formato específico. O tempo é muito rigoroso, por isso decidimos ser implementados como 2 threads - um recebendo mensagens do dispositivo e o segundo - escrevendo-os. O objeto comum para ambos os encadeamentos é uma fila de mensagens.

Existe um encadeamento DeviceHandler , que inicia o encadeamento de aquisição DeviceDriver . Na minha opinião, messageQueue objeto deve pertencer a DeviceHandler e é redundante estar em DeviceDriver e aumenta o acoplamento. Decidi passá-lo ao método DeviceDriver acquire, que deve iniciar este encadeamento, mas não sei como combiná-los sem tornar messageQueue uma variável de instância.

Além disso, como a obtenção de mensagens de dispositivos é uma grande tarefa, os implementadores de DeviceDriver usam seus próprios solicitantes de mensagens, que por sua vez devem, de alguma forma, ficar na fila e realmente preenchê-los por mensagens. O mesmo problema aqui. Além disso, devido aos detalhes da implementação, DeviceBDriverRequestor pode ser executado como um encadeamento.

Então eu tenho perguntas:

Estou certo de evitar fazer messageQueue uma variável de instância do DeviceDriver? Ou é aceitável tê-lo em todos os lugares?
Qual seria uma boa maneira de implementar DeviceDriver class (combinação dos métodos run() e acquire(Queue messageQueue) ) de uma forma que eu propus?
Existem algumas boas práticas para lidar com tais situações?

Obrigado antecipadamente!

design coding-style java coupling

por miuser 10.11.2016 / 15:57

fonte

2 respostas

Tags design coding-style java coupling

OAuth é um bom ajuste aqui? Estratégia para exibir valor para um HTML selecionado

score 1 · Answer 1

Ao contrário de C, onde você não pode iniciar um thread com vários argumentos (pthread void ** param: D), o encadeamento Java apenas permite executar o método run sem argumento. (veja link obrigado @RobertHarvey).

Você não tem escolha de usar o campo para passar o parâmetro para um Thread.

No entanto, você pode dissociar o DeviceDriver de seu aspecto de thread, já que no lado abstrato, o DevideDriver não é necessariamente um thread.

Assim, você pode mover o método run() de DeviceDriver para um DeviceDriverThread e adicionar uma execução de método (fila MessageQueue) a DeviceDriver

Este DeviceDriverThread tomará como campos o MessageQueue e o concret DeviceDriver para executar e este método executado fará o seguinte:

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

Eu acho que você precisará do método parar em DevideDriverThread também.

Pense nisso como um simples padrão de adaptador.

score 0 · Answer 2

Por que você não oculta a fila dentro de DeviceDriver e expõe os métodos necessários ( get , clear , o que for) pela delegação de thread-safe?

Dessa forma, o usuário de sua classe DeviceDriver não se importará com a sua realização e usará apenas o que realmente precisa, e seu DeviceDriver não terá dependência desnecessária.