SRP - Single Responsability PrincipleO Princípio da Responsabilidade Única                                             “Um...
O SRP é a base de praticamente todos os outros princípios. Como demonstrado noexemplo acima, é muito simples de ser compre...
implementadas e controladas. Em se tratando de métodos ágeis, onde a mudança é cotidiana,é de fundamental importância que ...
Próximos SlideShares
Carregando em…5
×

Artigo - Single responsabilityprinciple-final

267 visualizações

Publicada em

  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Artigo - Single responsabilityprinciple-final

  1. 1. SRP - Single Responsability PrincipleO Princípio da Responsabilidade Única “Uma classe deve possuir apenas uma razão para mudar...” Este é o pensamento-chave para o princípio citado pela primeira vez por Tom DeMarco em1979, no livro Structured Analysis and Systems Specification. O SRP combate o desenvolvimentode Classes “faz tudo” e também é conhecido como o Princípio da Coesão.Entendendo melhor o Princípio Ao desenvolvermos uma classe, geralmente temos o hábito de agrupar responsabilidades, e oresultado é algo parecido com isso: Perceba, neste exemplo clássico, que a Classe Retângulo possui dois métodos aparentementepertinentes. Afinal de contas, um deles calcula a área e o outro desenha o retângulo. Onde está oproblema então? O método Area() utiliza um modelo matemático para realizar o cálculo da área, enquanto ométodo Desenhar() utiliza uma interface gráfica para fazer seu trabalho. Logo, qualquer modificação feitano modelo matemático poderá causar uma modificação na geração do desenho, e vice-versa.Aplicando o Princípio Com a utilização do Princípio da Responsabilidade Única obteremos a seguinte arquitetura: Agora cada classe possui uma razão única de existir. Caso haja mudança, esta iráafetar somente a classe correspondente, e não ambas as classes.
  2. 2. O SRP é a base de praticamente todos os outros princípios. Como demonstrado noexemplo acima, é muito simples de ser compreendido. Ainda assim é preciso ter um cuidadoespecial para não acoplar as responsabilidades sem se dar conta disso.É isto mesmo? Vários desenvolvedores cometem o erro de interpretar este princípio achando queele se refere a implementar as classes com apenas um método. Por isso, vamos rever aexplicação com algumas dicas:Primeiro identifique as responsabilidades da sua Classe:“Ei Classe, o que você faz?”Se a resposta for algo do tipo:“Eu faço isto, isso e aquilo....”sua classe claramente possui mais de uma responsabilidade. Lembrando que o que deve serconsiderado não é a quantidade de métodos da classe, e sim a coesão entre estes métodos.Vamos a mais um exemplo Imagine uma classe Pedido. Ela deve possuir todos os métodos relacionados comum pedido (adicionarItem, valorTotal, removerItem, cancelar...), até aqui existe coesão entreseus métodos. Agora, se para obter o valorTotal for preciso calcular algum tipo de política dedesconto, esse política NÃO deve estar na classe Pedido, pois não possui coesão.Para lembrar 1. Se uma classe possuir mais de uma responsabilidade, deve-se considerar sua decomposição em duas ou mais classes; 2. Baseado no princípio da coesão funcional, uma classe deve ter uma única responsabilidade; 3. Cada responsabilidade é um eixo de mudança e as fontes de mudança devem ser isoladas.Finalizando Programar usando este princípio torna as mudanças de requisitos mais fáceis de serem
  3. 3. implementadas e controladas. Em se tratando de métodos ágeis, onde a mudança é cotidiana,é de fundamental importância que a equipe ágil tenha a habilidade de utilizar corretamente osprincípios básicos de programação Orientada a Objetos.Referênciaswww.macoratti.net/08/06/net_srp1.htmhttp://viniciusquaiato.com/blog/responsabilidade-unica-uma-historia-bem-contada/www.devmedia.com.br/post-18700-Arquitetura-O-Principio-da-responsabilidade-unica.html

×