Paradigma da Programação Orientada à Objetos (POO)

Quando comecei com programação, lá no anos 90, o paradigma da orientação à objetos já era algo muito discutido. Ele foi criado na década de 60 (para saber um pouco da história, acesse http://www.webgoal.com.br/origem-da-orientacao-a-objetos) , mas vejo que até hoje as pessoas tem dúvidas, se questionam a respeito e algumas vezes vão contra ele. Existe a legião de pessoas que idolatram a orientação à objetos, e vejo recentemente uma grande tendência contra ela, que vem crescendo à cada dia. Não sei o que o futuro nos aguarda, mas pode ser que venhamos à condená-la. Assim são as coisas com a evolução. O que posso dizer, humildemente, é que eu a adoro.

A orientação à objetos tem uma característica que considero fantástica: a forma que ela consegue organizar as coisas.

Durante anos estudei programação e análise de sistemas e, no início, mas durante um período que durou alguns anos, me questionava muito se eu realmente entendia sobre orientação à objetos. Entendia de classes, de herança, de polimorfismo, de sobrecarga de métodos e todas as outras coisas relacionadas, mas não era capaz de responder à simples questão: porque as pessoas precisam disso se conseguem desenvolver sistemas sem seguir a orientação à objetos? Não pode ser simplesmente pela reutilização do código, porque uma função também pode ser reutilizada. Porque criar uma estrutura se posso ir diretamente ao ponto e resolver o problema? Felizmente, a resposta para essa pergunta me apareceu futuramente.

Somente quando comecei a trabalhar com grandes projetos, o que aconteceu depois que entrei na faculdade (sim, comecei a desenvolver muito antes disso) é que fui entender a importância da facilidade de manutenção e de comunicação com outras pessoas da equipe, referente ao código-fonte.

A grande maravilha da orientação à objetos para mim não é relacionado aos seus pilares: abstração, encapsulamento, polimorfismo e herança (não despreso esses recursos!). É a forma como ela organiza as informações que é mágico. Você pode ter milhões de arquivos no seu computador, e todos vão funcionar e você eventualmente vai encontrar todos sempre que possível, mas mesmo assim, você os organiza em pastas, não é? Por que? Porque dessa forma, fica muita mais fácil trabalhar com eles. É a mesma coisa! Ah, mas eu poderia utilizar namespaces para organizar meu código… sim, você poderia! Eu utilizo os dois (classes e namespaces), e sou feliz assim! Quer utilizar namespaces apenas, e classificar suas funções? Vai em frente! Porque não importa o que você faça, o importante é que dê certo! Não existe certo ou errado em informática, desde que  as pessoas consigam aquilo que elas busquem.

Muitos argumentam que OO não é performático. Comparado a que? Procedural? Sim, pode ser verdade. E daí? Ah, então não devemos utilizar OO para nenhum projeto? Responda-me uma coisa: quando as pessoas vão para o fundo do mar, elas vão de submarino ou de avião? Mas o avião não é mais veloz (é, forcei um pouco no exemplo!)?  O que quero dizer é que não existe uma tecnologia que resolve todos os problemas. Cada coisa tem seu papel. Se vou realizar um processamento em lote, provavelmente farei sem utilizar OO, para que tenha o máximo de performance. Provavelmente farei tudo da forma mais direta possível, porque o problema exige isso. Mas, se ao mesmo tempo, tiver um deadline muito curto e já exista uma classe preparada para o serviço, só que utiliza ORM, etc, etc, etc, talvez utilize a OO simplesmente porque tenho que entregar o projeto, e sem isso, não conseguiria atingir o prazo. É melhor meia vitória do que nenhuma. Por outro lado, prefiro utilizar OO sempre que possível, porque isso me dá um egrenciamento do código que eu preciso nas manutenções, que é essencial para o desenvolvedor. Outras formas de desenvolver sistemas podem gerar uma melhor performance do programa, mas e quanto à performance da equipe? Isso também importa.

As dificuldades em desenvolvimento de sistemas são relacionadas à prazos, regras de negócios, relacionamento com os clientes, processos internos dentro da fábrica de software. A tecnologia é só a forma de chegar lá, é o veículo para atingir os objetivos. É como ter que ir para outra cidade, podendo escolher ir de carro, ônibus ou avião. Mas o problema real ainda é ir para outra cidade. O que geralmente vejo são as pessoas discutindo que é melhor ir de carro, outros de avião. Poucos discutem sobre: por que preciso ir para outra cidade? O que vou fazer lá? Essas são as questões, porque sem isso, nada adianta qual veículo você vai usar.

Costumo falar que informática é igual time de futebol. Fulano torce para aquela tecnologia, siclano para aquela linguagem de programação específica. Isso só demonstra imaturidade profissional. O bom profissional sabe que essas coisas são passageiras e que o importante é resolver o problema, seja como for. É a satisfação do cliente que importa, e ele não está preocupado com isso. Os envolvidos nos projetos geralmente não se preocupam com a tecnologia. Os pedidos estão caindo? Minha empresa está faturando? Como estão as vendas? Está formando filas nos caixas? Nada disso tem a ver com tecnologia. Isso tem a ver com pessoas. Foco nas pessoas. A tecnologia é o veículo para a resolução dos problemas. Se o faturamento está ótimo, importa se foi feito utilizando POO ou da forma procedural? Claro que não! Importa que funciona. E pode ter certeza que dá para se fazer bem feito das duas maneiras, ou de qualquer outra.

Outra vantagem de se utilizar OO que me ajuda muito, é algo que obtenho também dos padrões de projeto. Facilidade de comunicação com a equipe. Quando as pessoas estão integradas com o código, é fácil simplesmente dizer: utilize esse ou aquele objeto para resolver isso. Faça tal sobrecarga, etc, etc. É simplesmente fácil de se comunicar, porque os objetos são abstrações das estruturas e dos comportamentos, e quando falamos de comportamento, estamos utilizando uma linguagem comum a todos.

Se sua equipe está acostumado com a forma procedural, não mude! Não tire o know-how de como ter sucesso (a não ser que você não esteja tendo)! Se sua equipe está acostumada à OO, não mude! Não tire o know-how dela. Mudar os processos internos é traumatico e retira o conhecimento daqueles que já o detém. Cade equipe precisa encontrar a própria forma de trabalhar. Eu encontrei a minha. Espero que você também encontre a sua.