Register/Resolver e suas implicações para a modelagem e reaproveitamento
Publicado em: quarta-feira, 7 de out de 2020
Categorias: Architecture

Você já notou que desde a chegada do .NET Core, consistentemente reaproveitamos menos nossas classes, principalmente de infraestrutura. Escrevemos mais classes e cada vez reaproveitamos menos nosso código?

Bom se você não notou isso, então ao invés de 1 problema, temos 2!

Quando você desenha uma classe ela está ali para prover funcionalidade para quem a consome. Sempre que construo uma classe eu penso não só nas suas responsabilidades, mas também em como ela será consumida.

A fase de lapidação que detalho, por exemplo no RingBuffer (post) e projeto Oragon.Common.RingBuffer (GitHub), trata-se de endereçar essa preocupação, transformando em ocupação, para prover um design que de fato favoreça o consumo.

Essas preocupações consistem em:

  • Avaliar todos os métodos
    • Entender quais parâmetros são necessários para operar usar essa classe.
    • Identificar parâmetros com potencial para serem promovidos a estado da instância.
  • Avaliar as propriedades
    • Identificar propriedades com potencial para serem despromovidos para parâmetros de método (identificando qual/quais métodos).
  • SOLID – Estar alinhado com SOLID

Essa simples preocupação, com o que é parâmetro e o que é propriedade (ou estado) da instância é fundamental para uma arquitetura limpa.

Exemplo: Envio de Email

Vamos supor o clássico exemplo de envio de email. Se nosso cenário precisa levar em conta a utilização de um servidor SMTP então precisamos de:

  • Texto da Mensagem
  • Destinatários do email
  • Credenciais de conectividade com o servidor SMTP

Note, a classe de infraestrutura que prove essa funcionalidade tem todas essas características, mas do nosso lado, há boas chances de que devamos construir uma abstração que promova as credenciais de envio para propriedades e estado de um serviço de envio de email.

Isso para que quem consuma nossa classe, não precise lidar com a obtenção desses dados.

É uma bobeira, mas que limpa substancialmente o código.

Outra coisa é talvez, uma infraestrutura de template engine, que faça o papel de ter os templates de email e faça o parser desses emails.

Exemplo: Log

Log é um bom exemplo disso, onde usamos um ILogger sem nos preocuparmos com os detalhes de sua implementação. Não nos preocupamos com o tipo de persistência usada.

Isso tudo por conta de como essa interface foi desenhada. Houve uma ocupação ali para desenhar algo que produzisse o mínimo de acoplamento.

Exemplo: DBContext do Entity Framework

E se você usa um DBContext do EF, está aqui um exemplo: Você não passa a connectionstring para cada método. Ela é um estado do DBContext. Isso tudo para que você tenha uma experiência de uso, que seja direta ao ponto.

Busque exemplos

Você vai achar esse tipo de preocupação em toda boa modelagem. Aliás, até nas ruins!

E porque será que não fazemos isso com os nossos projetos?

Se você concorda que isso é importante para a saúde e longevidade do código, será que de fato está sendo coerente e fazendo seu dever de casa?

Quando comecei o Oragon.Common.RingBuffer desde os primeiros dias já havia um pequeno roadmap. Mas falando a verdade, na real em geral eu conduzo esse tipo de roadmap na cabeça mesmo. É tão pequeno, tão simples, tão dia-a-dia, que escrever no papel toma mais tempo que fazer de fato.

Mas dessa vez eu resolvi documentar o processo, passo-a-passo. Como uma forma de mostrar como essas preocupações acontecem.

O Register/Resolver nesse contexto

A injeção de dependência produz implicações diretas na forma como modelamos. A forma como desenhamos nossas dependências injetadas leva em conta o estado vs parâmetros em que elas se encontram.

Em um cenário onde eu tenha 2 tipos de envio de email, com 2 conjuntos de credenciais, poderíamos ter apenas 1 classe, com 2 instâncias, onde cada uma teria consigo a credencial certa. Injetaríamos a instância correta de acordo com a classe a ser construída.

Mas é aí que o register/resolver dificulta a coisa. Como somos obrigados a pensar em 1 tipo, mapeado para outro tipo, não temos parâmetros adicionais para construir nossas dependências, então somos empurrados a criar managers, factories, ou mesmo Service Locators.

E note, o Register/Resolver em geral tem condições de oferecer a implementação que te permite ter esse controle, no entanto, não é intuitivo e você precisa claramente saber o que quer, para conseguir realizar a melhor modelagem, na minha opnião.

E a melhor modelagem na minha opinião é aquela que não ignora o que suas classes são, o que elas fazem, como fazem em como são consumidas.

Eu fico encantado com projetos que ao ser dissecado você enxerga os pedaços como um conjunto de peças de um lego. E você? O que te encanta nos projetos que curte?

Luiz Carlos Faria

Mensagem do Autor

Espero que goste desse post. Não deixe de comentar e falar o que achou. 

Se acha que esse post pode ajudar alguém que você conheça, compartilhe!

 

Eventos passados

outubro 2020
setembro 2020
agosto 2020
Nenhum evento encontrado!
Carregar Mais

Publicidade

Assine

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.

Agenda & Eventos

setembro

outubro 2020

novembro
DOM
SEG
TER
QUA
QUI
SEX
SAB
27
28
29
30
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
1
2
3
4
5
6
7
Events for 30th setembro
Events for 1st outubro
Events for 2nd outubro
Sem Eventos
Events for 3rd outubro
Sem Eventos
Events for 4th outubro
Sem Eventos
Events for 5th outubro
Sem Eventos
Events for 6th outubro
Sem Eventos
Events for 7th outubro
Sem Eventos
Events for 8th outubro
Sem Eventos
Events for 9th outubro
Sem Eventos
Events for 10th outubro
Sem Eventos
Events for 11th outubro
Sem Eventos
Events for 12th outubro
Sem Eventos
Events for 13th outubro
Sem Eventos
Events for 14th outubro
Sem Eventos
Events for 15th outubro
Sem Eventos
Events for 16th outubro
Sem Eventos
Events for 17th outubro
Sem Eventos
Events for 18th outubro
Sem Eventos
Events for 19th outubro
Sem Eventos
Events for 20th outubro
Sem Eventos
Events for 21st outubro
Sem Eventos
Events for 22nd outubro
Events for 23rd outubro
Sem Eventos
Events for 24th outubro
Sem Eventos
Events for 25th outubro
Sem Eventos
Events for 26th outubro
Sem Eventos
Events for 27th outubro
Sem Eventos
Events for 28th outubro
Sem Eventos
Events for 29th outubro
Sem Eventos
Events for 30th outubro
Sem Eventos
Events for 31st outubro
Sem Eventos
Share This