Single responsibility principle (SRP) – Principio da responsabilidade unica

Salve, salve galera, conforme tínhamos conversado aqui, vamos começar a falar sobre os princípios SOLID.

O primeiro principio a falarmos sera o principio da responsabilidade unica.

Esse principio se trata o de mais fácil entendimento, o de mais fácil aplicação e um dos que menos vemos no dia-a-dia. O SRP define que :

Uma classe deve ter um e apenas um motivo para ser modificada.

Mas podemos ser mais claros ainda, dizendo que cada classe pode representar apenas uma responsabilidade, ou em termos mais comuns do dia-a-dia , fazer apenas uma coisa, para que assim, possamos muda-la apenas se essa função tiver que ser modificada.

Esse princípio atua entre outras coisas:

  • Na facilitação do entendimento do código
  • Diminuição na complexidade do código
  • Leitura mais clara
  • Baixo acoplamento
  • Mudanças certas do impacto

Tudo bem, mas e ae ? Cade o exemplo ????

Imaginem que temos uma classe (isso mesmo uma classe apenas) que faz o seguinte:

  • Cadastra um pedido de venda.
  • Cadastra um pedido de compra.
  • E ainda por cima cadastra as solicitações de orçamento.

De maneira simplista e minimalista, o SRP pede que tenhamos uma classe para manutenção nos pedidos de venda, uma para os pedidos de compra e uma para solicitação de orçamentos.

Mas onde esta a vantagem ? Eu criei 3 classes sendo que eu poderia ter (da forma que eu tenho ate hoje) apenas uma.

Imaginem agora que, o departamento de compra solicita um atributo (ou um campo) a mais no pedido de compra, para indicar um possível “Fornecedor TOP OF MIND“, o que isso interessa para o pedido de venda ? e para o orçamento?

Nada concordam ?????

Ja temos um motivo pelo qual implementar o SRP.

Mais uma pergunta, depois de feita a implementação o que precisaremos testar ? Quem disse o pedido de compra infelizmente não acertou 100% pois a classe que gerencia os pedidos de venda e orçamentos estão juntas, por consequência, vamos ter que testar tudo novamente, e caso passe algo pelos testes podemos interferir em processos sem relação com o pedido de compras.

Pessoal, vale ressaltar aqui que estamos falando sobre implementação de classes, e não de telas ou de bancos de dados heim….

Bom pessoal  de maneira simples e pratica o SRP diz isso.

Então cuidado quando forem implementar uma classe PATO. Para quem não teve contato com esse termo ainda o PATO ele VOA, ANDA e NADA, em termos gerais tenta fazer tudo, só que na prática, não faz nada 100%.

Anúncios

Um pensamento sobre “Single responsibility principle (SRP) – Principio da responsabilidade unica

  1. Pingback: SOLID – Princípios e definição | Guilherme Silva Cardoso

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

w

Conectando a %s