Olá, queria confirmar se essa implementação é a maneira que se faz quando o Decorator é implementado, pois tentei da outra forma, injetar a dependência como normalmente fazemos no construtor, porém deu dependência circular.
Obrigado.
Solucionado
Olá, queria confirmar se essa implementação é a maneira que se faz quando o Decorator é implementado, pois tentei da outra forma, injetar a dependência como normalmente fazemos no construtor, porém deu dependência circular.
Obrigado.
Esse é um problema bem comum Jefferson ao utilizar o Service Layer com Injeção de Dependência (independente da questão do Decorator). https://martinfowler.com/eaaCatalog/serviceLayer.html
Na teoria ao utilizar Service Layer, um Service não pode depender do outro, veja que na maioria das vezes você até consegue injetar ou instanciar um Service em outro, contanto que o outro Service não dependa deste que iniciou o processo, caso contrário vai gerar a referência circular.
Pense no Service Layer como se fossem os Controllers, você instanciaria ou injetaria um Controller no outro?
Esse pattern tem como objetivo isolar todo o core do sistema de qualquer interface (no sentido mais amplo), por exemplo, APIs, WebPages, Desktop. Todas essas interfaces podem fazer uso do Service Layer e a regra de negócio fica encapsulada.
Ai fica a pergunta: e quando eu tenho um Service que precisa chamar outro que já tem uma regra encapsulada e eu não quero duplicá-la?
Nesse caso temos diversas opções, vou da mais simples para a mais complexa.
1 - Mova o máximo possível de regra de negócio para as entidades (exceto código de acesso a banco - DAO), assim fica mais fácil reaproveitá-las em diversos Services.
2 - Se a regra for sempre usada pelo Service cliente, então mova para lá.
3 - Evite criar Services vinculados a entidades e foque a camada de Service mais em comportamentos relacionados.
4 - Se ainda assim precisar chamar regras de 2 Services em um processo (Chamada API de um Controller), então você terá que fazer uso de um desses patterns: Observable ou Mediator, que vai faciliar um Service delegar para o outro a continuação do processo ao terminar de fazer sua parte.
Sobre a questão do Decorator, ele é mais utilizado quando precisamos lidar com um código que não podemos alterar ou então, um código legado que estamos refatorando e queremos evitar alterações nele para não gerar impacto em classes que já o utilizam (possíveis bugs). O Decorator permite que que você estenda o comportamento de uma classe, sem precisar alterá-la ou herdá-la, assim quem já utilizava essa classe não é afetado. Segue uma referência que explica cada detalhe dele https://refactoring.guru/design-patterns/decorator