SOLID — Princípio da Responsabilidade Única
SOLID — Princípios de design
Vou começar uma sequência de artigos aqui sobre SOLID Design Principles, onde falaremos dos cinco pilares essenciais para a programação orientada a objetos. É um assunto que você precisa entender e aplicar constantemente durante o seu dia-a-dia.
Mas o que é SOLID?
SOLID é um acrônimo, que significa:
- Single Responsibility Principle (Princípio da Responsabilidade Única)
- Open Closed Principle (Princípio Aberto Fechado)
- Liskov Substitution Principle (Princípio de Substituição de Liskov)
- Interface Segregation Principle (Princípio da Segregação de Interface)
- Dependency Inversion Principle (Princípio da Inversão de Dependência)
Eles, que são a base da programação orientada a objetos, foram identificados por Robert C. Martin (Uncle Bob) lá por volta dos anos 2000. Esses princípios devem ser aplicados para se obter os reais benefícios da orientação a objetos. SOLID não é um padrão de design, é um fundamento, você precisa entender muito bem e saber o por quê de cada um deles.
Alguns dos benefícios são:
- Código fácil de manter
- Código testável
- Extensível para alterações com o menor esforço
- Reaproveitamento
Nesse primeiro artigo vamos falar do primeiro princípio, o Princípio da Responsabilidade Única (SRP), vamos lá.
Princípio da Responsabilidade Única (SRP)
A regra do SRP, diz que:
“A class should have one, and only one, reason to change”
Uma classe deve ter um, e apenas um, motivo para ser modificada. Esse princípio, além de ser o primeiro, também é o mais simples e importante deles. A questão da responsabilidade se dá através do que a classe tem que fazer, então se ela tem apenas um motivo para ser modificada, é por que ela faz apenas uma coisa
Os exemplos mostrados aqui serão escritos em C#, mas pode ser usada qualquer linguagem que seja orientada a objetos.
Vamos ver o exemplo de uma classe que viola esse princípio:
Temos muitas violações do SRP aqui, analisando a classe Customer.cs, de início conseguimos ver que ela:
- Tem as informações da entidade Customer
- Faz a persistência dos dados no banco
- Realiza o envio de e-mail
Essa classe tem diversas atribuições, isso quer dizer que ela tem mais de um motivo para ser alterada. Por exemplo, caso precisamos mudar alguma informação da entidade Customer, caso mude o jeito de realizar a persistência dos dados no banco ou caso mude o jeito como é enviado o e-mail. Ela tem muito mais de um motivo pra mudar e isso é um problema.
Vamos fazer uma refatoração e quebrar essa classe em mais de uma:
Agora temos seis novas classes, cada uma fazendo sua devida tarefa.
Temos a classe CustomerService.cs que orquestra todo o fluxo que antes tínhamos numa mesma classe.
Ela recebe um Customer, essa entidade valida seus dados. Temos a classe CustomerRepository.cs que é responsável por fazer a persistência no banco de dados e a classe EmailService.cs que é responsável por fazer o envio do e-mail. E aí você pode estar pensando que no final a classe CustomerService.cs continua fazendo tudo, mas não, a implementação das outras funcionalidades não é de responsabilidade dela, ela apenas usa métodos de outras classes, com isso, ela não será alterada caso alguma outra classe tenha que ser mexida por algum motivo.
A classe CustomerService.cs ainda pode ser melhorada usando outros princípios do SOLID, vamos voltar nela quando abordarmos o tópico Dependency Inversion Principle.
Com isso finalizamos esse artigo sobre o Princípio da Responsabilidade Única.
No próximo artigo falaremos sobre o Princípio Aberto Fechado (OCP), até a próxima.
Esses exemplos estão disponíveis no meu GitHub.
Links para todos os artigos sobre SOLID:
Princípio Aberto Fechado (OCP)
Princípio de Substituição de Liskov (LSP)
