Conheça o S.O.L.I.D. — Parte 1

Um dos maiores desafios de um desenvolvedor é manter a qualidade do código, fator importantíssimo para sua manutenção e escalabilidade. Isso se torna ainda maior quando temos uma equipe atuando simultaneamente na criação do produto.

Existem algumas orientações para lidar com essa questão, sendo uma delas o S.O.L.I.D., um conjunto de princípios e boas práticas de programação. O objetivo deste artigo é apresentar seu contexto de criação e uma visão geral dos princípios, que serão apresentados de forma mais detalhada nas próximas publicações.

Contexto e Princípios

S.O.L.I.D. é um acrônimo para cinco princípios de programação. Os princípios não foram construídos por uma só pessoa, mas um dos grandes nomes que falam sobre esse assunto é Robert C. Martin, no artigo Design Principles and Design Patterns.

Cada princípio tem como objetivo criar estruturas de softwares intermediárias que sejam tolerantes a mudanças, fáceis de serem compreendidas por diferentes desenvolvedores e que sirvam como uma base de componentes que possam ser usados em diferentes sistemas.

Abaixo, apresentamos o princípio abordado por cada letra do termo:

Obs: Por classe, leia-se o agrupamento de função e dados. O uso da palavra classe não deve implicar que esses princípios são aplicáveis somente à softwares feitos sob a ótica do paradigma de programação orientada a objetos.

• [S] ingle Responsibility Principle (Princípio da Responsabilidade Única) — Uma classe só deveria ter um motivo para mudar, ou seja, deveria ter somente uma responsabilidade.
• [O] pen/Closed Principle (Princípio do Aberto/Fechado) — O comportamento esperado de uma classe é que ela seja aberta para extensão e fechada para modificação.
• [L] iskov Substitution Principle (Princípio da Substituição de Liskov) — Uma subclasse deveria substituir a classe Pai de modo que não quebre a funcionalidade.
• [I] nterface Segregation Principle (Princípio da Segregação de Interfaces)— Classes não devem implementar métodos que não irão utilizar.
• [D] ependency Inversion Principle (Princípio da Inversão de Dependências) — Classes de alto nível não devem depender de classes de baixo nível, ambos devem depender de abstrações.

Motivos para a aplicação desses princípios

• Melhora na estrutura do código, removendo os chamados design smells;
• Organização das funções e estruturas de dados dentro de classes e como essas classes devem se conectar;
• Códigos mais limpos, separando responsabilidades e diminuindo acoplamentos de modo a facilitar na refatoração e estimular o reaproveitamento de código.

E ai, o que achou do post? Comente! No próximo artigo falaremos detalhadamente a respeito do Single Responsibility Principle.