OK, eu entendi o conceito do Observer, mas usá-lo dentro de um Builder não seria dar mais responsabilidades ao Builder do que ele realmente deveria ter (instanciar objetos complexos)? No exemplo, qual seria o melhor lugar para aplicar as ações?
OK, eu entendi o conceito do Observer, mas usá-lo dentro de um Builder não seria dar mais responsabilidades ao Builder do que ele realmente deveria ter (instanciar objetos complexos)? No exemplo, qual seria o melhor lugar para aplicar as ações?
Rodrigo, tudo bem ?
O Builder te ajuda a criar objetos, nem precisam ser tão complexos. Se você quer que todo objeto ao ser criado já avise ao Observer, não é tão ruim assim unir esses patterns.
Oi Rodrigo no caso no curso, o padrão é explicado em cima da classe do padrão anterior que é o Builder, onde tínhamos a complexidade de criar uma nota fiscal, então em cima desse padrão já aprendido na aula anterior dissertamos sobre o Observer, que exemplifica uma sequencia de ações que serão executadas após a geração da nota fiscal, a primeira ideia é criar métodos privados que representam cada uma dessas ações, logo depois percebemos que a classe fica muito cheia fazendo muitas coisas, então quebramos essa classe grande em pequenas classes que representam as ações, logo em seguida verificamos que elas ficam muito acopladas, para diminuir o acoplamento pegamos o que é comum entre essas ações e criamos uma interface para representar este comportamento. Então apenas passamos para a lista todas as ações a serem executadas, desacoplando as classes, adicionar uma nova seria também bem simples devido a flexibilidade do padrão. Em muitas cursos e livros sobre padrões você vai encontrar a explicação de um padrão sendo desenvolvida ao longo de diversas refatorações que vamos fazendo em nosso sistema. Além disso é muito comum a relação entre padrões.No caso temos uma padrão para criação do objeto(Builder) nota Fiscal e outro para o comportamento do objeto em Ações a serem executadas(Observer).
Espero ter ajudado e bons estudos