O Single responsibility principle – Entendendo SOLID – Parte 1

O Single responsibility principle – Entendendo SOLID – Parte 1

Hoje daremos início a mais uma série entendendo conceitos mais avançados para te tornar um melhor desenvolvedor no mundo da Orientação a Objetos. Provavelmente você já se deparou com o termo SOLID. Mas você sabe de fato o que ele significa?

Um dos pilares da orientação a objetos é que devemos criar classes que são fáceis de serem alteradas se necessário e além disso, que seu código seja transparente e o mais simples possível. Mas daí surgem algumas questões: O que minha classe deveria ter, o quanto eu devo expor meus métodos, quais comportamentos implementar, etc. A boa notícia é que os princípios SOLID podem te ajudar a responder essas questões.

Os princípios fazem parte de um compilado criado por Robert C. Martin, onde juntos tornam “fácil” o ato de desenvolver softwares que são fáceis de se manter e extender. Além disso, eles nos ajudam a manter nosso código refatorável e em sintonia com um ambiente ágil. Sendo eles:

  • Single responsibility principle
  • Open closed principle
  • Liskov substitution principle
  • Interface segregation principle
  • Dependency inversion principle

Nesse post, daremos foco no primeiro princípio, o Single Responsibility Principle.

Single Responsibility Principle

O primeiro princípio basicamente diz que: “Uma classe deve ter um e apenas um motivo para mudar, significando que a classe deve ter apenas um dever”. Bem, apenas com a leitura da frase ainda fica um pouco abstrato definir o que o princípio diz, então vamos direto para o exemplo.

Imagine o código abaixo onde temos uma classe abaixo que representa um item em um software de supermercado:

falha_no_principio_single_responsibility

Perceba que essa classe pode ter dois motivos para mudar. Se quiséssemos adicionar mais algum atributo para nosso Item, como peso por exemplo, essa classe mudaria. Ou se nossa lógica, infraestrutura ou forma de salvar um item fosse alterada, ela também mudaria.

Aqui percebemos um acoplamento entre nossa representação de um Item e a lógica do banco de dados.O que é ruim e impede a evolução saudável de nosso sistema. Por exemplo, se desejamos futuramente que todos os itens agora são salvos em  XML, teríamos que mudar todas as classes que possuem um método salvar com a lógica atual.

Assim, como podemos melhorar nosso código neste exemplo?

exemplo_principio_single_responsibility

Perceba agora que na imagem acima dividimos as responsabilidades. A classe Item é apenas responsável por modelar como é um item, a classe ServicoDePersistencia cuida da lógica de nossa infraestrutura de banco de dados e por fim a classe ServicoDeItens cuidaria de realizar de fato as ações estritamente ligadas às nossas regras de negócio no que diz respeito ao Item.

Dessa forma, a refatoração e a extensão do nosso sistema fica facilitada, onde a mudança em uma classe, desde que o contrato entre elas não seja quebrado, não afeta em nada a estrutura de outra classe ou de como ela funciona. Perceba também que usamos outra técnica muito conhecida que é a injeção de dependências. Nossa classe ServicoDeItens recebe como parâmetro qual serviço de persistência iremos utilizar (mesmo tendo um valor default). Isso também nos ajuda a diminuir o acoplamento entre as classes e nos abre também a possibilidade de usar diversos serviços de persistência diferentes dependendo do caso. Mas não se preocupe, abordaremos a injeção de dependências em um post futuro.

Espero que tenha ficado claro o que é o Single Responsibility Principle. Na semana que vem abordaremos o segundo princípio, o Open Closed Principle, então não perca porque vem muita coisa boa por aí aqui no Blog da Agência F12.

Deixe seu comentário! Críticas, dúvidas e sugestões são sempre bem vindas.

Algumas fontes utlizadas nesse post:

Sobre nós

Vivemos em uma era onde a tecnologia se faz presente em todo setor corporativo, independente do ramo de atividade. Surgimos visando esta crescente demanda.

Nossos contatos

+55 (11) 2528 7798
+55 (11) 98081 4290