Eu acredito que o SRP é útil se for usado com moderação. Muitos acreditam que ele se refere a quantidade de métodos dentro de uma classe, mas não é bem assim. É possível ter mais de uma responsabilidade tendo apenas um método. Imagine um Controller usando persistencia, acessando serviços externos diretamente dentro de si e coisas do tipo. Isso é uma violação do SRP. Mas, uma classe que tem mais de um método não necessariamente tem mais de uma responsabilidade. Se os diferentes métodos têm relação entre si, não há nenhum sentido segregá-los em classes diferentes. Até porque, se for pra fazer assim, é melhor adotar uma linguagem funcional, deixando de fora todo o paradigma orientado a objetos. Já vi pessoas segregarem todos os métodos de um repository em inúmeros repositories diferentes que só atendem a uma forma de persistência diferente. Isso até faz sentido em algumas situações, mas na maioria das vezes é Overengineering, pois de fato dentro de um repository há métodos que fazem parte da mesma responsabilidade. Na minha opinião, um repository com todas as operações de CRUD tem apenas uma responsabilidade, não 4.
@@vitorpaulinogoncalves936 eu tinha uma duvida em relacao a isso, estou trabalhando em um projeto onde tenho um serviço responsável por gerenciar assinaturas, logo, possui alguns métodos pra orquestrar a lógica de gerenciamento dessas assinaturas (que inclui criar um cliente, que é delegado a um outro serviço), e estava na dúvida se isso feria o SRP ou não
Muito legal que você colocou os exemplos e fez na prática a refatoração. Muito conteúdo na internet só fala a mesma coisa de sempre, deixando só na teoria. Parabéns!
Balta, poderia me informar qual é o marker que vc usa no video? (me refiro as setas vermelhas - como dou aula, achei interessante a forma que é marcado o video)
Pois é, fico me causa estranheza, no caso de de um Crud, vou precisar criar uma class para o create, outra para o update e por aí vai? Não gosto muito não
geralmente se vê o principio aplicado a métodos de uma classe, como vocês estão falando. Em abstrações simples dá para aplicar só nos métodos pois a classe é pequena e vc consegue deixar ela enxuta e SOLID facilmente. No exemplo ele usou a classe de Relatórios, que é muito mais complexa e difícil de finalizar em 1 dia. Colocar todos os recursos de um Gerador de relatórios em apenas uma classe é impossível. Não é uma classe, é uma feature/funcionalidade. Então, ele aplicou o SOLID dividindo os recursos em várias classes, tendo cada classe uma responsabilidade única. Resumindo, sim .. É possível dividir uma classe gigantesca em diversas classes menores. Um exemplo: Crie a classe veículo. Coloque nesse veículo tudo que ele tem. O aparelho multimídia, a direção elétrica, o freio ABS, a caixa de marcha, o sistema de direção e o sistema de suspensão, o sistema de som, etc. Nesse veículo haverá várias sub classes, não é?? Então, é disso que ele está falando
Balta, qual o curso na sua plataforma é aplicado o SOLID? Poderia me enviar o link direto para que analise o conteúdo, caso seja apenas para Premium, tenho interesse.
O SRP não se trata apenas de que um componente deva fazer apenas uma coisa, ele diz também em segregar uma função para diferentes atores e áreas de responsabilidade, agora sobre ter apenas uma responsabilidade, se você pensar uma classe repositório que possui vários métodos para manusear dados no banco de dados, não infringe o princípio SRP, pois a responsabilidade desse componente é persistir dados no banco.
Se modela em partes... o canivete é o conjunto, seria o domínio todo... o SRP seria aplicado a cada parte dele. Depois testamos cada parte individualmente para garantir que elas funcionam Em seguida testamos o canivete todo, com todas as partes juntas. O melhor do SOLID é que se você precisar adicionar funcionalidades a este canivete, será fácil!!
Não concordo em nada com essa paranoia de uma classe só ter um metodo. Se tenho uma classe "ManagerClient" é para ter toda a responsabilidade de lidar com "Clients" logo deve conter todos os metodos insert, update, delete e até Report... Portanto facilmente se sabe que sobre "Clients" tudo está "ManagerClient" e o metodo Report até pode ser depois implementado noutra classe.... Apenas concordo com esse SRP sobre metodos esses sim devem ter apenas uma responsabilidade. Já agora podias nos teus exemplos ter colocado "static" nas classes e nos metodos que é outra paranoia moderna !!!! Isso cheira-me a programação funcional !!!! portanto não Orientada a Objectos
BLACK FRIDAY 2024 ⚡ Está chegando a maior e melhor da nossa história! Não perca.
INSCREVA-SE NA LISTA DE ESPERA: go.balta.io/black-friday?TH-cam&
Eu acredito que o SRP é útil se for usado com moderação. Muitos acreditam que ele se refere a quantidade de métodos dentro de uma classe, mas não é bem assim. É possível ter mais de uma responsabilidade tendo apenas um método. Imagine um Controller usando persistencia, acessando serviços externos diretamente dentro de si e coisas do tipo. Isso é uma violação do SRP.
Mas, uma classe que tem mais de um método não necessariamente tem mais de uma responsabilidade. Se os diferentes métodos têm relação entre si, não há nenhum sentido segregá-los em classes diferentes. Até porque, se for pra fazer assim, é melhor adotar uma linguagem funcional, deixando de fora todo o paradigma orientado a objetos.
Já vi pessoas segregarem todos os métodos de um repository em inúmeros repositories diferentes que só atendem a uma forma de persistência diferente. Isso até faz sentido em algumas situações, mas na maioria das vezes é Overengineering, pois de fato dentro de um repository há métodos que fazem parte da mesma responsabilidade. Na minha opinião, um repository com todas as operações de CRUD tem apenas uma responsabilidade, não 4.
🚀
@@vitorpaulinogoncalves936 eu tinha uma duvida em relacao a isso, estou trabalhando em um projeto onde tenho um serviço responsável por gerenciar assinaturas, logo, possui alguns métodos pra orquestrar a lógica de gerenciamento dessas assinaturas (que inclui criar um cliente, que é delegado a um outro serviço), e estava na dúvida se isso feria o SRP ou não
Muito legal que você colocou os exemplos e fez na prática a refatoração. Muito conteúdo na internet só fala a mesma coisa de sempre, deixando só na teoria. Parabéns!
🚀
Adorei a aula, parabéns e obrigado!
Nós que agradecemos!🚀
Vai rolar um video pra cada conceito SOLID?? 🤤
Aba vídeos, clique nas notificações. dias 07, 11, 14, 18 e 21 de novembro.
Sim, já estão agendados inclusive!!!
Excelente conteúdo
🚀
Excelente conteúdo!
Obrigado 😃
Balta, poderia me informar qual é o marker que vc usa no video? (me refiro as setas vermelhas - como dou aula, achei interessante a forma que é marcado o video)
Uso o Presentify no Mac e ZoomIt no Windows
Poderia monta uma aula sobre o mesmo conteudo, porém voltado pro frontend ?
É o mesmo, SOLID independe de linguagem ou área de atuação!
Hypei duzentos e tantos
Nem todo herói usa capa 🥹
Obrigado!!
Excelente conteudo! Lança um plano mensal balta 😢
Muito ruim para o negócio! Não tem previsibilidade de caixa
No livro Clean Architecture, o Uncle Bob explica o SRP de forma diferente: "Um módulo deve ser responsável por somente um ator".
É exatamente isto! Um item deve ter uma única responsabilidade!
Eu também aprendi de outro jeito, me disseram que assobiar e chupar cana ao mesmo tempo viola o SRP.
Pois é, fico me causa estranheza, no caso de de um Crud, vou precisar criar uma class para o create, outra para o update e por aí vai? Não gosto muito não
geralmente se vê o principio aplicado a métodos de uma classe, como vocês estão falando. Em abstrações simples dá para aplicar só nos métodos pois a classe é pequena e vc consegue deixar ela enxuta e SOLID facilmente. No exemplo ele usou a classe de Relatórios, que é muito mais complexa e difícil de finalizar em 1 dia. Colocar todos os recursos de um Gerador de relatórios em apenas uma classe é impossível. Não é uma classe, é uma feature/funcionalidade. Então, ele aplicou o SOLID dividindo os recursos em várias classes, tendo cada classe uma responsabilidade única. Resumindo, sim .. É possível dividir uma classe gigantesca em diversas classes menores. Um exemplo: Crie a classe veículo. Coloque nesse veículo tudo que ele tem. O aparelho multimídia, a direção elétrica, o freio ABS, a caixa de marcha, o sistema de direção e o sistema de suspensão, o sistema de som, etc. Nesse veículo haverá várias sub classes, não é?? Então, é disso que ele está falando
Balta, qual o curso na sua plataforma é aplicado o SOLID?
Poderia me enviar o link direto para que analise o conteúdo, caso seja apenas para Premium, tenho interesse.
Dos mais avançados quase todos... mas agora no novo teremos um módulo dedicado ao SOLID!
O SRP não se trata apenas de que um componente deva fazer apenas uma coisa, ele diz também em segregar uma função para diferentes atores e áreas de responsabilidade, agora sobre ter apenas uma responsabilidade, se você pensar uma classe repositório que possui vários métodos para manusear dados no banco de dados, não infringe o princípio SRP, pois a responsabilidade desse componente é persistir dados no banco.
03:30 Eu assistindo esse vídeo enquanto corrijo um bug em uma classe de 700 linhas 🤡🤡
😂 (RAIZ)
Que a força esteja com você!
Eu quero ver como vai ficar o teste de unidade dela.
Eu aqui imaginando como se modela uma canivete-suíço que por natureza tem a principal funcionalidade de fazer tudo.
Se modela em partes... o canivete é o conjunto, seria o domínio todo... o SRP seria aplicado a cada parte dele.
Depois testamos cada parte individualmente para garantir que elas funcionam
Em seguida testamos o canivete todo, com todas as partes juntas.
O melhor do SOLID é que se você precisar adicionar funcionalidades a este canivete, será fácil!!
Não concordo em nada com essa paranoia de uma classe só ter um metodo.
Se tenho uma classe "ManagerClient" é para ter toda a responsabilidade de lidar com "Clients" logo deve conter todos os metodos insert, update, delete e até Report...
Portanto facilmente se sabe que sobre "Clients" tudo está "ManagerClient"
e o metodo Report até pode ser depois implementado noutra classe....
Apenas concordo com esse SRP sobre metodos esses sim devem ter apenas uma responsabilidade.
Já agora podias nos teus exemplos ter colocado "static" nas classes e nos metodos que é outra paranoia moderna !!!!
Isso cheira-me a programação funcional !!!! portanto não Orientada a Objectos
Até faz sentido, mas você não vai conseguir confeccionar testes de unidades enxutos. É só seguir as boas práticas que no final tudo acaba bem.
Outra coisa, não é uma classe ter apenas um metodo. É ter apenas um motivo para ser alterada, apenas uma responsabilidade.
show!