O Princípio da Responsabilidade Unica (SRP do SOLID) é um mantra a ser seguido, quando o assunto é fraco acoplamento e alta coesão.
Quem faz tudo não faz nada. Diz o ditado.
Onde se tem muita generalização não é possível ter especialização. E em software, especializar é boa prática, premissa para uma boa modelagem.
Misturar responsabilidades não é uma boa.
No contexto da Orientação a Objetos, o Princípio da Responsabilidade Unica (SRP) do SOLID define que uma classe deve possuir apenas uma responsabilidade, e esta responsabilidade deve estar totalmente encapsulada na respectiva classe. A seguir alguns exemplos descritivos.
Responsabilidade Unica
Uma Classe deve conter somente responsabilidades que são suas.
Por exemplo, manter informação de vendas é algo que deve ser feito por uma classe Venda e não por uma classe Produto. Manter informação de Produto não deve ser feito por uma classe ItemEstoque e sim por uma classe Produto.
A responsabilidade deve estar totalmente encapsulada na Classe.
Encapsulamento
Aqui entra o conceito de Encapsulamento do paradigma da Orientação a Objetos, onde a boa prática nos recomenda aplicar um pouco do que o SRP prega, no que refere-se à esconder o que não deve ser de “domínio público”.
Falando mais tecnicamente, não devemos manter informação de Venda diretamente, acessando um atributo público como _ValorTotal diretamente, devemos fazê-lo através de sua propriedade correspondente, usando seus métodos públicos de acesso padrão (get() e set()) para acessar o atributo privado _ValorTotal.
O uso de Propriedades na classe é a aplicação do Encapsulamento da Orientação a Objetos.
Exemplificando
Abaixo temos dois diagramas de Classes, ambos representando um mesmo cenário. São exemplos simples, didáticos.
O primeiro demostra o atendimento ao Princípio da Responsabilidade Unica (SRP), o segundo demonstra uma violação deste princípio.
No diagrama acima percebemos que ha coerência no todo, em função da coesão em suas partes. Notemos que:
- Todos os atributos estão encapsulados em propriedades, não estão expostos para acesso direto.
- O Endereco é uma única classe, composta por classe Bairro, que é composta pela classe Cidade, que é composta pela classe Estado.
- Cada classe possui apenas uma responsabilidade, e o processo se dá através de relacionamentos de Composição.
- E havendo a necessidade, outras classes alem de Endereco podem utilizar recursos das classes Bairro, Cidade e Estado, pois estes conceitos não estão inseridos diretamente (através de atributos) no Endereco.
No diagrama ao lado percebemos que as responsabilidades estão misturadas, pois além dos dados de Endereço, dados de Bairro, Cidade e Estado estão na mesma classe.
Você pode pensar assim: “Mas não é mais rápido ignorar o Princípio da Responsabilidade Unica e ter uma única classe invés de quatro classes? Assim fazemos o mesmo em menos tempo!”. Na Engenharia de Software, como em quase tudo na vida, definitivamente a pressa é inimiga da perfeição.
Concluindo
Projetos de software sempre atrasam, são replanejados diversas vezes e muitos são um fracasso total.
Em função de problemas como o alto acoplamento gerado por estruturas onde não uma adequada separação de responsabilidades, empresas todos os anos perdem milhões sem perceberem. Basta pensar em causa e efeito!
Vale a pena refletir. E fazer certo da primeira vez!
Abraço!