É o primeiro princípio SOLID, o qual diz respeito :
“The class should have one, and only one, reason to change.”
“A classe deve ter um e, apenas um motivo para mudar.”
Este princípio traz uma importante visão relacionada à forma que costuma-se pensar nas abstrações necessárias para construir-se uma classe que cumpra um objetivo proposto. Quando aprendende-se a modelar uma classe, geralmente pensa-se no que ela tem e no que ela deve fazer. Pensa-se somente em suas propriedades e seus métodos e muitas vezes, começa-se a escrever o código que irá compor a classe. Seguir assim parece a forma mais comum de se pensar em como construir uma classe mas, quantas vezes ao fim desse processo de modelagem já pergunta-se, “Qual o real propósito da classe?”, “Será que é realmente isso que a classe deve ter ?” ou ainda, “Será que é realmente isso que a classe deve fazer ?”. Três perguntas aparentemente simples, mas com um poder de resposta relevante para a construção de um design orientado a objeto o qual não viola SRP (Single Only Responsibility).
Se refletir sobre essas questões, em muitos casos, acaba-se repensando na modelagem existente, sendo muito provável que acabe por ter um novo modelo, onde as "coisas" parecem estar mais separadas, e também mais organizadas, fazendo mais sentido. Quando isso começar acontecer certamente estará a caminho de se atingir o primeiro princípio SOLID.
Por meio da resposta destas 3 perguntas pode-se chegar a um design que aplica o princípio da responsabilidade única.
1 - Qual propósito da sua classe ?
Deve-se aqui pensar no problema que a classe resolve, qual seu objetivo, qual é sua intenção, ela "é uma classe que envia arquivos para o servidor?”, por exemplo. É a pergunta mais importante, pois o motivo para que mude algo nela é o fato de que mudou algo em seu propósito, mas não o propósito em si.
2 - Será que é realmente isso que essa classe deve ter ?
Tendo o propósito bem definido, deve-se pensar no que é preciso para atingir esse propósito, tão importante quanto, deve-se ter de forma clara e definida, as propriedades da classe, pois são importantes para manter a classe coesa. Deve-se fazer a analise se todas as propriedades são realmente internas a essa classe, ver se não há propriedades que não deveriam estar ali, observar se essa propriedade não é mais cabível a outra classe. Deve-se olhar para a utilidade dessas propriedades ao se cumprir o propósito.
3 - Será que é realmente isso que a classe deve fazer ?
Não confundir com o propósito da classe, deve-se atentar para os métodos existentes para a classe. Tais métodos devem ser condizentes com o propósito desta classe e, também com suas propriedades, pois é a partir daí que o propósito é atingido. Quais são os métodos necessários para que se cumpra o propósito, qual a relação entre eles(métodos) e, suas propriedades.
Os métodos devem de forma clara trabalhar todos os comportamentos necessários para que se atinja o propósito da classe, não se deve ter métodos que não sejam cabíveis ao propósito da classe, como por exemplo, uma classe que realiza o envio de arquivos para o servidor e, para que faça isso, ela precisa ter seus diretórios já criados, e acabamos na mesma classe tendo, além do método de envio de arquivo, um método que cria o diretório. Isso é problemático, pois, para uma classe que tenha tais métodos em sua interface, torna-se difícil responder a primeira pergunta "Qual propósito da classe?”, deveria ser enviar arquivos, mas também cria diretórios. Agora deve-se relembrar parte do princípio, “um e, apenas um motivo para que mude”. Logo, é possível acontecer o seguinte: caso haja necessidade de mudar algo na forma como acontece a criação de diretórios para o envio de arquivos, deve-se mexer na classe que realiza o envio de arquivos, se houvesse a necessidade de mudar a forma como acontece o envio de arquivos, deve-se mexer na mesma classe, fazendo com que aquilo que é proposto pelo princípio seja violado pois, na mesma classe existem dois motivos eminentes para alteração.
Como pode-se perceber, a aplicação do princípio está intimamente relacionada com as responsabilidades que sua classe deve ter que por sua vez tem forte relação com aquilo que se abstrai para construir a classe. Uma das formas de se conseguir saber se o modelo está aplicando pelo menos, o primeiro princípio SOLID, é realizando as três perguntas citadas acima. Sempre que estiver modelando alguma classe, pergunte antes de começar a modelar e, depois de já ter modelado sua classe, as respostas irão auxiliar a não violar SRP (Single Only Responsibility).