O primeiro princípio SOLID diz que “The class should have one, and only one, reason to change”. Ou, em bom português, “A classe deve ter um e apenas um motivo para mudar”.

Este princípio traz uma importante visão relacionada à forma habitual de se pensar nas abstrações necessárias para construir uma classe que cumpra um objetivo proposto. Quando alguém aprende a modelar uma classe, geralmente pensa no que ela tem e no que ela deve fazer; pensa somente em suas propriedades e seus métodos e muitas vezes, começa 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, você já perguntou “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 que não viole a SRP (Single Only Responsibility).

Se refletir sobre essas questões, em muitos casos, você vai acabar repensando na modelagem existente, sendo muito provável que chegue em um novo modelo, no qual as “coisas” parecem estar mais separadas e também mais organizadas, fazendo mais sentido. Quando isso começar a acontecer, certamente você estará a caminho de atingir o primeiro princípio SOLID.

Por meio da resposta destas três perguntas é possível chegar a um design que aplica o Princípio da Responsabilidade Única.

1. Qual propósito da sua classe?

Aqui, é preciso pensar no problema que a classe resolve, qual é o seu objetivo, a sua intenção. Questione-se se 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, o próximo passo é pensar no que é preciso para atingir esse propósito. Tão importante quanto é ter, de forma clara e definida, as propriedades da classe, pois são importantes para manter a classe coesa. Faça a análise e veja se todas as propriedades são realmente internas a essa classe, se não há propriedades que não deveriam estar ali; observe se essa propriedade não é mais cabível em outra classe. Olhe 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: aqui você 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 trabalhar de forma clara 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 à primeira pergunta, “qual propósito da classe?”. No caso, deveria ser enviar arquivos, mas também cria diretórios. Agora é preciso 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, então 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 você pode 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 você está ao menos aplicando o modelo, 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 a SRP (Single Only Responsibility).