Onde colocar os tipos de eventos comuns em um aplicativo de vários módulos?

5

Eu deparei com essa questão ao criar um aplicativo de vários módulos que se comunica com eventos. Todos os módulos são fracamente acoplados e não dependem um do outro. Eles usam tipos de eventos comuns para se comunicar uns com os outros.

A questão é, onde colocar os tipos de eventos comuns neste cenário? Vamos supor que estamos usando classes como tipos de eventos. Para se comunicar, o emissor e também o receptor precisam saber como o tipo está estruturado - então eles precisam de algum tipo de dependência comum.

Quais são as vantagens / desvantagens dos dois cenários:

  1. Coloque o evento no módulo que contém o remetente
  2. Crie um módulo comum que contenha todos os eventos
por gorootde 23.12.2016 / 12:07
fonte

2 respostas

1

Create a common module that contains all of the events

Eu iria por esse caminho. Colocar o evento no módulo emissor / receptor criará um acoplamento entre o emissor e o receptor, o que efetivamente elimina a idéia do design modular. E você pode querer evitar isso.

    
por 23.12.2016 / 16:00
fonte
1

Ao racionalizar sobre isso, sugiro que primeiro tenhamos de reconhecer que, nos sistemas do mundo real, algum acoplamento é totalmente normal. Embora você normalmente queira que isso mantenha um nível abstracional mais alto e evite o acoplamento na implementação.

Por exemplo, você pode ter um banco de dados em seu sistema. Você não será capaz de remover o acoplamento do banco de dados de todas as partes do resto do sistema, alguns outros componentes irão ter que estar ciente de que você tem um banco de dados, porque eles terão interagir com ele é de alguma forma, implícita ou explicitamente. Seus componentes abstratos em seu sistema simplesmente não podem viver em total isolamento.

Você pode ter partes interessadas que se beneficiariam da possibilidade de mudar a implementação do banco de dados facilmente, como passar do MSSQL para o MySql, então você terá que certificar-se de abstrair o banco de dados corretamente e manter seus detalhes de implementação ocultos para que o o sistema não está acoplado a um mecanismo de banco de dados específico. E, em contraste, em algum momento, a melhor opção pode ser escolher um determinado mecanismo de banco de dados e expô-lo totalmente no sistema, como se você tivesse requisitos de desempenho que superestimavam os requisitos de modularidade.

O acoplamento é normal e devemos raciocinar sobre onde colocá-lo no sistema, não apenas sobre como evitá-lo.

E quando temos o acoplamento, devemos colocá-lo onde ele pertence contextualmente, sem tentar indiretamente.

Você tem um componente de exibição que aciona algo como UserWantsToSeeDetailsForObject(id) ? Isso é algo que facilmente pode ser visto como pertencente contextualmente à abstração do próprio aplicativo, então eu colocaria isso em algo como uma classe "ApplicationEvents". Faz sentido que muitos componentes diferentes em seu aplicativo possam acionar isso.

Você tem um componente como NetworkAnalyzer que verifica sua conectividade de rede e aciona eventos como "Reconectado", "Desconectado", "Instável" e outros? Esses tipos de eventos não fazem sentido disparar em algum lugar fora de NetworkAnalyzer , portanto, evite alguma indireção e coloque-a onde ela pertence: Dentro desse mesmo componente.

Você então tem a necessidade de implementar diferentes implementações do NetworkAnalyzer ? Coloque a definição do evento na classe base.

Você descobre que o sistema não precisa apenas estar ciente da conectividade de rede, mas também de coisas como memória disponível, recursos de CPU e temperatura? Então você pode perceber que você tem um novo contexto abstracional que você poderia nomear algo como "EnvironmentTelemetry", onde faz sentido coletar essas definições de eventos.

TL; DR

O evento tem um dono claro? Basta colocá-lo com o dono e evitar indireções desnecessárias.

O evento faz sentido na aplicação sem o componente que você acabou de escrever? Ele provavelmente pertence ao aplicativo em seu todo, então coloque-o em uma construção estrutural compartilhada (por exemplo, uma classe ApplicationEvents).

O seu evento específico pertence contextualmente a um determinado grupo de outros eventos, não em um nível de aplicativo, mas acima de um componente individual? Considere criar uma classe contendo esses eventos específicos.

    
por 25.12.2016 / 12:38
fonte