Programação orientada a objetos é um paradigma que nos traz uma série de possibilidades para criarmos softwares mais eficazes a partir de códigos mais elegantes e otimizados. Contudo, para nos beneficiarmos dessas potencialidades, é preciso compreender realmente o que é a Orientação a Objetos.
Muitas faculdades ensinam POO de forma desconectada da realidade. Assim, deixa-se de lado partes fundamentais desse modelo de programação. Gasta-se muito tempo ensinando exemplos que não têm aplicação prática e que não ajudam a resolver problemas da vida real.
Por isso, neste artigo, vou te mostrar por que a maneira como muita gente aprende POO está errada e quais as consequências disso. Também vou falar sobre o verdadeiro trunfo da orientação objeto, que muitas vezes é deixado de lado nas aulas das universidades.
Orientação a classes ou orientação a objetos? (o que não é POO)
Um dos principais problemas, por exemplo, é que na verdade a maioria das pessoas aprenderam Orientação a Classes em vez de orientação a Objetos.
Eu lembro como se fosse hoje a tortura que foi na faculdade passar um semestre inteiro brigando com diagramas abstratos e exemplos de hierarquias de animais que não faziam o menor sentido. Enquanto o foco estava na modelagem de classes, todo o real poder da interação entre os objetos acabou ignorado.
Foi uma tortura, e mais que isso. Foi um baita desperdício, porque a essência da Orientação a Objetos tem o poder de materializar ideias, algoritmos e abstrações sofisticadas em um código simples e elegante.
O que sinto é que se foca muito na estrutura, mas não no processo. Como resultado, passa a se pensar em objetos estáticos e não em objetos interagindo durante a execução do programa. Essa estrutura linear e sequencial acaba mais refletindo uma característica da programação procedural, que trabalha mais a sequência de passos, do que o poder de representação simbólica que a POO traz.
Como já comentei aqui, na POO, não basta saber criar classes, definir métodos, modos de acesso público ou privado de atributos. Você precisa orquestrar bem a relação entre os objetos. Para isso, é necessário usar o poder de abstração para pensar no resultado que queremos com o código que está sendo escrito, e não ficar preso somente às tarefas.
Para fortalecer esse mindset, é preciso compreender o grande trunfo da POO, que muitas vezes não recebe o destaque necessário. É sobre isso que vamos falar no próximo tópico.
O tesouro esquecido
A POO nos permite criar softwares com um constante aprimoramento do processo, sem que isso implique um rearranjo de todo o sistema. Você não precisa mexer no código inteiro e retreinar todo mundo só porque mudou o procedimento todo e agora nada funciona mais. Essa é a diferença entre um foco em procedimentos e um foco em orientação a objetos.
A POO te dá uma interface melhor para que exista uma cooperação sem a regulação da ação do outro. É exatamente o que faz um bom time. Um bom time, quando trabalha junto, não foca em tarefa, foca em resultado. É o paradigma da confiança, e não do controle.
Quer ver um exemplo na vida real sobre a diferença entre esses dois paradigmas?
Uma vez eu precisei ir no Banco do Brasil resolver um problema da Associação Python Brasil enquanto eu era Diretor Financeiro, e surpreendentemente havia um atendente a menos que saiu do balcão para ficar controlando a fila para o atendimento. Ele anotava o nome e cpf das pessoas por ordem de chegada. Então ficava vigiando os demais atendentes e quando um se liberava ele chamava a pessoa pelo nome, a encaminhava ao balcão correto e atualizava o seu controle riscando o nome da pessoa.
Esse claramente é um exemplo procedural, onde o Banco alocava recursos para controlar todo o processo acumulando 2 responsabilidades: atender e gerir a fila.
Em vez de focar apenas em fazer o melhor atendimento possível, ele reduziu a capacidade de realizar sua atividade fim, para despender energia com uma atividade meio. Um desperdício que certamente aumentou o tempo processamento da fila de clientes.
Esse exemplo você vê no seu código sempre que tem um loop de “for” ou “while” responsável pela seleção do próximo item misturado com o processamento do item em si. Um clássico acoplamento.
Paradigma da eficácia
Em oposição, outro dia eu eu precisei levar minha filha para tomar vacina e o posto de saúde implementou uma estratégia diferente. As enfermeiras focaram totalmente em concentrar os seus poucos recursos para dar o melhor atendimento possível à população.
Elas não tinham como organizar uma fila e delegou essa responsabilidade para outra parte do sistema.
Quando eu cheguei com a minha pequena, identifiquei um pessoal esperando na frente da porta e perguntei: Quem é o último da fila? Me apontaram para a pessoa, confirmei, me apresentei como o novo último da fila e me pus a esperar. Logo em seguida chegou outra pessoa, que reproduziu a mesma dinâmica comigo e se pôs a esperar também.
Na sequência, a porta do atendimento se abriu e a enfermeira simplesmente gritou: próximo. Então o primeiro da fila levantou e se encaminhou para o atendimento. Toda vez que a porta abria, a enfermeira apenas gritava essa palavra mágica: próximo.
Isso demonstra a completa separação de responsabilidades entre a organização da fila e o atendimento em si. Para as enfermeiras, os pacientes estavam encapsulados em um objeto iterador que sempre que recebia a mensagem “próximo” apenas fornecia o próximo paciente, independente de quem fosse e de como estivessem organizados.
Nesse caso, dentro do iterador os pacientes se organizaram em uma lista duplamente encadeada onde um determinado paciente apenas conhecia seu antecessor e seu sucessor, mas não precisava se preocupar com a ordem da lista inteira.
Essa separação de responsabilidades permite inclusive que a implementação da fila mudasse sem impactar em nada o procedimento das enfermeiras. Porque pra elas tudo que importa é saber quem é o próximo. Não precisa saber cpf, nome, índice nem qual a estrutura de dados interna que está sendo usada para organizar as coisas. Só importa o próximo.
Esse é o poder de você sair do foco em controle e passar para o foco em confiança com interfaces melhor definidas para que os objetos cooperem na solução do problema.
Orientação a Objetos: Muito além da superfície
Para ser capaz de visualizar e implementar esse tipo de estratégia, você tem que trabalhar muito mais focado na forma como o processamento vai acontecer em vez de ficar excessivamente preso à superfície e a objetos óbvios (classes, métodos, atributos, etc). No final das contas, o mais importante não são os objetos em si, mas sim a interação entre eles.
O pulo do gato é compreender qual o melhor fluxo que pode ser estabelecido entre os objetos para oferecer o conjunto mais eficaz de soluções possíveis para o problema que queremos resolver. Quando entendemos essa lógica invisível por trás da POO, conseguimos criar códigos mais eficiente, que ocupam menos espaço de memória e evitam procedimentos desnecessários.
É sobre isso que vou falar no meu novo treinamento Orientação a Objetos NA PRÁTICA. É um programa completo que vai te mostrar como usar a POO para aumentar sua produtividade e para criar softwares que de fato resolvem problemas. Tudo isso de forma segura e prática.
As inscrições já estão abertas. Será um prazer ter você crescendo com a gente!
Clique na imagem abaixo e conheça o programa do curso:
