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.

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