Artigo - Single responsabilityprinciple-final
0 gostou119 visualizações
O documento descreve o Princípio da Responsabilidade Única (SRP), que diz que cada classe deve ter apenas uma razão para mudar. Isso promove classes coesas e isola fontes de mudança. O documento fornece exemplos de como aplicar o SRP corretamente, dividindo classes com múltiplas responsabilidades em classes com responsabilidades únicas.
Artigo - Single responsabilityprinciple-final
- 1. SRP - Single Responsability Principle O 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 em 1979, no livro Structured Analysis and Systems Specification. O SRP combate o desenvolvimento de 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 o resultado é algo parecido com isso: Perceba, neste exemplo clássico, que a Classe Retângulo possui dois métodos aparentemente pertinentes. Afinal de contas, um deles calcula a área e o outro desenha o retângulo. Onde está o problema então? O método Area() utiliza um modelo matemático para realizar o cálculo da área, enquanto o método Desenhar() utiliza uma interface gráfica para fazer seu trabalho. Logo, qualquer modificação feita no 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. O SRP é a base de praticamente todos os outros princípios. Como demonstrado no exemplo acima, é muito simples de ser compreendido. Ainda assim é preciso ter um cuidado especial 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 que ele se refere a implementar as classes com apenas um método. Por isso, vamos rever a explicaçã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 ser considerado 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 com um pedido (adicionarItem, valorTotal, removerItem, cancelar...), até aqui existe coesão entre seus métodos. Agora, se para obter o valorTotal for preciso calcular algum tipo de política de desconto, 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. 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 os princípios básicos de programação Orientada a Objetos. Referências www.macoratti.net/08/06/net_srp1.htm http://viniciusquaiato.com/blog/responsabilidade-unica-uma-historia-bem-contada/ www.devmedia.com.br/post-18700-Arquitetura-O-Principio-da-responsabilidade-unica.html