Princípios SOLID

Olá a todos! Neste artigo discutirei os princípios SOLID, detalhando o propósito de cada princípio e como aplicá-lo.

Se você está se perguntando o que significa SOLID, é a sigla formada com a primeira letra de cada princípio em inglês.

O que são princípios SOLID?

São um conjunto de princípios ou regras que nos ajudam a manter nosso código mais flexível e fácil de entender. Os princípios SOLID são fundamentais para o desenvolvimento de software orientado a objetos, evitando que tenhamos que utilizar más práticas em nosso código.

Abaixo descrevo cada princípio:

Princípio de Responsabilidade Única (Single Responsibility Principle)

Uma classe deve ter um único motivo para mudar, ou seja, uma classe deve lidar com uma única tarefa para evitar que a classe mude constantemente.

O objetivo principal é evitar o acoplamento de métodos para uma classe e assim promover a coesão. Dividir as responsabilidades em classes diferentes nos ajuda a ter um código mais limpo e compreensível.

Um exemplo com PHP

Suponha que desenvolvamos um aplicativo para gerenciamento de tarefas. Neste ponto temos uma classe chamada Tareas (Tarefas em espanhol) que representa as funcionalidades que a aplicação terá.

Violando o princípio

A classe Tareas tem diversas responsabilidades:

• Salve em um banco de dados.
• Envie notificações.
• Gere relatórios.

Isso viola o princípio, torna a classe mais difícil de entender e tem muito acoplamento de métodos.

Aplicando o princípio

Separamos as responsabilidades em diferentes classes.

Princípio Aberto/Fechado (Open/Closed Principle)

As classes devem ser abertas à extensão e fechadas à modificação. Isso significa que as classes devem ser projetadas para adicionar funcionalidade sem alterar o código existente da classe.

O objetivo deste princípio é que possamos reaproveitar código e, no longo prazo, facilitar a manutenção e agilidade do software.

Vejamos um exemplo: Suponha que trabalhamos com figuras geométricas onde calcularemos a área de cada figura. Temos uma classe chamada Figura onde gerenciamos as figuras necessárias ao sistema.

Violando o princípio

Quando trabalhamos com uma estrutura condicional como if-else if-else ou switch, estamos propensos a ter uma nova condição. Neste exemplo, uma nova figura como o quadrado pode surgir, então devemos modificar o método calcularArea().

Aplicando o princípio

Para evitar estruturas condicionais, atribuímos uma classe por figura e as estendemos para uma classe abstrata para reutilizar seu código.

Princípio da Substituição LISKOV (LISKOV Substitution Principle)

Estabelece que uma subclasse pode ser substituída por sua superclasse. Este princípio visa aplicar herança estrita entre classes, ou seja, quando temos uma classe filha, ela deve reutilizar todos os métodos e atributos de sua classe pai.

Vejamos um exemplo: suponha que atribuímos tarefas para cada desenvolvedor de uma empresa. Como parte do exposto, definimos uma classe Tareas como uma superclasse e uma subclasse Frontend.

Se a classe filha não puder substituir um método da classe pai, violaremos o princípio. Neste caso, um desenvolvedor Frontend não tem a tarefa de testar.

Aplicando o princípio

Separamos as tarefas em interfaces para que as classes implementem apenas o que precisam. Neste caso, temos 3 interfaces e a classe Frontend implementa apenas 2 interfaces porque é tudo o que precisa.

Lembremos que interfaces são contratos onde as classes que as implementam são obrigadas a substituir o que cada interface possui: se a interface tiver 5 funções, então a classe será forçada a ter essas 5 funções. Essa é uma forma de ter uma herança mais rígida.

Princípio de segregação de interface (Interface Segregation Principle)

Ele afirma que uma interface deve ser pequena. Podemos interpretar isso como a frase “dividir para conquistar” que nos dá a compreensão de que podemos usar várias interfaces em vez de ter apenas uma.

O objetivo deste princípio é que as interfaces não fiquem sobrecarregadas com funções irrelevantes em todas as classes que irão implementar a interface.

Vejamos um exemplo: Vamos supor que temos uma interface com vários métodos de controle de funcionários de um sistema, mas os métodos calcularSalario (calcularSalário) y generarInformePlanilla (gerarRelatórioPlanilha) não se referem ao controle dos empregados como tal, mas ao controle das folhas de pagamento dos empregados. Então, as classes serão forçadas a depender de métodos que não utilizarão.

Aplicando o princípio

Como diz o princípio, separamos o trabalho em duas interfaces para evitar o acoplamento de métodos e para que as classes não sejam forçadas a ter métodos desnecessários.

Princípio de Inversão de Dependência (Dependency Inversion Principle)

Afirma que classes ou módulos de alto nível não devem depender de classes ou módulos de baixo nível, mas sim de abstrações.

O objetivo deste princípio é desacoplar classes e gerenciar um intermediário entre elas, como uma interface ou uma classe abstrata para reutilizar seu código.

Vejamos um exemplo: Temos uma classe User que precisa fazer registros de algum tipo de evento ou ação (por exemplo, fazer um registro de algum arquivo ou um registro em um banco de dados). Como aplicamos o princípio?

Para isso foi criada uma interface Logger, que será nossa abstração. Então criamos duas classes: FileLogger e DatabaseLogger que implementam a interface. Essas classes serão os módulos de baixo nível, enquanto injetamos a abstração na classe User, nosso módulo de alto nível (Logger) através do construtor.

Isso ajuda a classe de alto nível (User) reutilizar código de todas as classes que implementam a abstração (Logger). Caso o usuário queira fazer um cadastro no banco de dados, poderá utilizar DatabaseLogger, mas se o usuário quiser cadastrar um arquivo ele pode usar FileLogger quando for necessário.

Nenhuma classe depende da outra, apenas da interface.

Em resumo, os princípios SOLID servem para:

• Melhore a modularidade do código e facilite a reutilização de componentes.
• Incentive a manutenção do software conforme os requisitos mudam.
• Reduza o acoplamento para tornar o código mais flexível e resistente a alterações.
• Promova boas práticas de design, como o uso de interfaces e injeção de dependências.
• Ajude a criar sistemas de software mais escaláveis ​​e sustentáveis ​​ao longo do tempo.

Espero que este artigo tenha sido útil para conhecer e aplicar os princípios SOLID em seus projetos, bem como para continuar aprendendo boas práticas para seu código.

Boa sorte e muito sucesso!