Princípios SOLID no Java desde o início: é uma boa decisão?

Já reparou como a barreira de entrada da área de tecnologia está cada vez mais alta? O Mercado de Trabalho não é mais o mesmo, e as vagas vem se tornando mais e mais exigentes. Essa demanda por profissionais melhor capacitados nos força a ter que ir além de apenas escrever código "de qualquer jeito", sem pensar muito na estrutura e nos padrões utilizados.

⚠️AVISO:⚠️ Se você estiver vindo do absoluto zero, seu foco deverá ser aprender e entender os conceitos de lógica de programação, pular etapas só irá te deixar confuso e frustrado. Dito isso, vamos ao artigo.

O que é Programação Orientada a Objetos

Programação Orientada a Objetos, comumente abreviada em POO, é uma maneira de escrever código em que tudo é tratado como "objeto" (como o nome sugere) ou como suas propriedades. Porém isso é muito abstrato, o que deveria significar?

Fazendo uma comparação, o "objeto" da programação é como o substantivo da língua portuguesa. Pode ser algo material ou imaterial, concreto ou abstrato e etc. Todo substantivo pode ter adjetivos (características) e verbos (ações) certo? Na POO é a mesma coisa, todo objeto possui atributos (características) e métodos (ações).

Exemplificando, um PC é um objeto que, dentre muitas coisas, possui:

Gabinete;
Placa-mãe;
Fonte;
Processador;
CPU Cooler;
Memória RAM;
Armazenamento;
Placa de vídeo;

E faz a ação de:

Ligar;
Desligar;
Executar software;

(Em código seria algo assim)

É o mínimo que o PC precisa para ser o que ele é e funcionar. Existem ainda os conceitos fundamentais da POO: Herança, Polimorfismo, Encapsulamento e Abstração, entretanto, não vou me aprofundar neles. O que quero que você entenda, é que essa é uma forma mais organizada de pensar, e consequentemente, de programar, e por isso amplamente adotada pelas empresas.

Mas nem tudo são flores. Por ter essa natureza de objetos e suas propriedades, é muito fácil de você se perder e acabar colocando funcionalidades e atributos onde não faz sentido existir, fazendo com que seja tudo muito mais difícil de manter e escalar. Se não for seguido um padrão, uma estrutura bem definida, mesmo programando em POO vai ser como se estivesse programando proceduralmente (a maneira mais "comum" de codificar, geralmente ensinada primeiro)

Aí que entram os princípios SOLID, uma forma padronizada de organizar a codebase, que muitas empresas pedem e muita gente nem sabe o que é.

SOLID: Os 5 "mandamentos" para um bom código

Apesar de não terem surgido junto da sigla, os princípios SOLID foram criados e popularizados por Robert C. Martin (Uncle Bob), ninguém menos que o autor do famigerado livro Clean Code.

SOLID é um acrônimo onde cada letra significa um princípio diferente a ser seguido:

S — Single Responsiblity Principle (Princípio da responsabilidade única);
O — Open-Closed Principle (Princípio Aberto-Fechado);
L — Liskov Substitution Principle (Princípio da substituição de Liskov);
I — Interface Segregation Principle (Princípio da Segregação da Interface);
D — Dependency Inversion Principle (Princípio da inversão da dependência);

Resumidamente, os "mandamentos" dizem o seguinte:

I - Delegarás apenas uma responsabilidade ou tarefa para cada classe e método;

II - Não farás de seu objeto aberto à modificações. Ao invés disso, torná-lo-o livre para ser extendido;

III - Construirás classes de forma que as classes Filhas poderão ser substituídas por suas classes Pai, de forma que não quebrarás o programa;

IV - Serás específico ao criar classes e interfaces, para que um objeto não venha a ter uma propriedade não utilizada;

V - Tornarás abstrações a base, e todo módulo, seja de alto, seja de baixo nível, e todo detalhe, dependerão das abstrações;

A importância de aprender ambos AO MESMO TEMPO

O que me faz pensar que aprender uma linguagem orientada a objetos aplicando tudo isso desde o início é essencial? É muito simples na verdade. Assim como tudo na vida, essa medida tem prós e contras, mas acredito que o benefício compense o esforço, aqui está o porquê:

Contras:

Curva de aprendizado maior: mais tempo e mais esforço pra aprender como as coisas funcionam e se relacionam entre si;
Necessidade nem sempre existente: em projetos pequenos e MVPs, talvez aplicar esses padrões seria over-engineering, fazendo perder mais tempo em boilerplate e menos tempo no que a aplicação deve fazer;
Cuidado com o equilíbrio: no início, pode ser difícil de balancear a quantidade de abstração com o requisito de fazer o programa simplesmente funcionar;

Prós:

Recompensa também maior: capacidade de análise do código para fazer dele mais limpo e organizado, o simplificando muito e clareando a mente;
Demanda das empresas: como foi dito no início, a porta de entrada do Mercado TI está cruel. Se você já aprender POO aplicando da maneira "correta", vai se destacar bastante (sem contar o tempo poupado);
Costume: como desde o início você vai ter aplicado boas práticas na sua maneira de programar, não vai existir um esforço mental posterior pra se acostumar com os princípios, o aprendizado foi todo de uma vez;

Os contras são desafiadores, mas os prós te dão uma vantagem avassaladora, o colocando na frente de grande parte dos "Juninhos" querendo um primeiro emprego, e até mesmo em seus próprios projetos pessoais.

Concluindo minha linha de raciocínio: Vale sim a pena estudar os dois juntos, POO e SOLID, porém com cuidado. É preciso ter uma base muito forte antes de sequer aprender orientação a objeto, somando com SOLID esse requisito só aumenta. E não se mantenha na teoria! Se não praticar, pode ler e assistir vídeos o quanto for, nada vai fazer sentido.

E o que você acha? Vale a pena ou não?