O que são os princípios S.O.L.I.D.?

S.O.L.I.D. é um acrônimo para 5 princípios para design de software, voltados à programação orientada a objetos. Eles foram introduzidos por Robert C. Martin em um artigo. Estes princípios ajudam a escrever um código melhor nos quesitos de entendimento, manutenção e melhor reaproveitamento.

Esse acrônimo significa:

• Single Responsibility Principle (Princípio da Responsabilidade Única)
• Open/Closed Principle (Princípio do Aberto/Fechado)
• Liskov Substitution Principle (Princípio da Substituição de Liskov)
• Interface Segregation Principle (Princípio da Segregação de Interfaces)
• Dependency Inversion Principle (Princípio da Inversão de Dependências)

Neste artigo será apresentado o primeiro dos princípios do S.O.L.I.D., o Single Responsibility Principle. Usaremos a linguagem C# para todos os exemplos.

Single Responsibility Principle(SRP)

Uma classe deve ter um e somente um motivo para mudar, ou seja, ela deve ser responsável por apenas uma parte específica de um sistema.

Isso significa que cada classe deve ser especializada, podendo fazer apenas um trabalho e não vários. Assim, focando na sua atividade principal.

Quando uma classe tem muitas responsabilidades, existe mais chances dela precisar de ser modificada e também de possuir mais bugs.

Exemplo prático

Vamos usar exemplo inspirado na franquia dos jogos do Mario, da Nintendo. Abaixo temos a classe Cogumelo, ela representa os itens de cogumelo que dão um benefício ao entrar em contato com o jogador.

Esta classe contém três métodos: darBeneficio(), sumir() e somBeneficio(). Dessa forma, ela é responsável por dar o benefício ao Mario, e ao entrar em contato com o personagem o item desaparece e reproduz o som de feedback. Porém, a função principal do item é de dar uma vantagem a quem o obtém.

using UnityEngine;
using System.Collections;

public class Cogumelo : MonoBehaviour
{
    public int id;
    public string cor;

    public void darBeneficio(){
        //lógica para atribuir o beneficio ao Mário
    }
    public void sumir(){
        //lógica para desaparecer o cogumelo
    }
    public void somBeneficio(){
        //lógica para reproduzir o som beneficio na tela
    }
}

Nessa abordagem, a classe Cogumelo tem mais de uma ação e responsabilidade. No caso da modificação do som de feedback, por exemplo, isso acarretaria em uma mudança na classe Cogumelo como um todo. Consequentemente um erro em somBeneficio(), iria impactar os outros métodos da classe. Assim nesse acoplamento há maiores chances de produzir um bug.

Além disso, ao reutilizar os métodos somBeneficio() e sumir() em outros itens faria com que instâncias de Cogumelo existam em outras classes. Assim, mais classes seriam dependentes de Cogumelo, o que gera um acoplamento maior no sistema e tornam mudanças mais difíceis. Outro fator é que essas outras classes teriam acesso ao método darBeneficio(), mesmo sem precisar dele.

Aplicando o princípio da responsabilidade única, separando as responsabilidades pelos comportamentos que são realizados, obtemos a modificação abaixo.

using UnityEngine;
using System.Collections;

public class Cogumelo : MonoBehaviour
{
    public int id;
    public string cor;

    public void darBeneficio(){
        //lógica para dar beneficio
    }
}

public class Some : MonoBehaviour{
    public void sumir(){
        //lógica para desaparecer o cogumelo
    } 
}

public class ReprodutorSom : MonoBehaviour{
    public void somBeneficio(){
        //lógica para reproduzir o som beneficio na tela
    }     
}

Dessa forma acima, é possível reutilizar as classes em outros objetos do jogo, como as moedas, blocos e outros itens diferentes. Também com esta modificação todas as três classes ficam mais coesas, tendo apenas uma responsabilidade, o que facilita a manutenção do código e evita mais bugs no futuro.

Um dos possíveis problemas que podem acontecer ao não usar o SRP, é o alto acoplamento entre classes, dificuldade de reaproveitamento de código e a falta de coesão. Estes três fatores atrapalham a realização de futuras modificações, deixando as classes muito dependentes entre si e dificultando o seu entendimento.

Logo, o single responsibility principle ajuda na manutenção de um projeto e na legibilidade dele. Além de ser base para outros princípios e padrões de projetos, como o Factory, Builder e o Command.