É hora de ficar longe de OOP
OOP é considerado o maior diamante da coroa da ciência da computação. A melhor maneira de organizar seu código. A solução para todos os problemas. A única maneira segura de escrever nossos programas. O Deus da programação nos enviou de cima ... Só que agora o programador OOP é forçado a remexer um monte de todos os tipos de abstrações, manter o controle de todos os objetos compartilhados, lembrar toneladas de "padrões de programação" - e gastar seu tempo e energia em tudo isso, em vez de resolver o problema em si.
Muitos criticam o OOP há muito tempo e há muitos programadores altamente respeitados entre esses críticos. E até mesmo Alan Kay - o inventor do OOP está em suas fileiras!
O principal objetivo de qualquer desenvolvedor é escrever um código confiável. Se o código tiver bugs e não funcionar conforme o esperado, nada mais importa. Qual é a melhor maneira de escrever um código confiável? Mantenha o código simples. Simplicidade é o oposto de complexidade . Conclui-se que o objetivo principal do desenvolvedor é reduzir a complexidade do código.
Disclaimer:
Eu não sou um fã de OOP, então não é surpresa que este artigo pareça tendencioso para muitos. No entanto, vou apresentar argumentos em defesa da minha posição.
Eu também entendo muito bem que criticar OOP é muito doloroso para muitos. Muitos leitores se sentirão pessoalmente ofendidos. No entanto, pretendo declarar o que acredito ser correto. Pois meu objetivo não é ofender, mas apontar os problemas que OOP tem. Não estou criticando
a OOP de Alan Kay . Ele geralmente é um gênio. Pessoalmente, gostaria que OOP fosse exatamente o que Alan Kay pretendia. O que eu critico é o OOP em uma implementação C # ou Java.
O problema é que OOP há muito tempo é considerado o padrão para organizar código de software. E tantas pessoas pensam, incluindo aqueles que ocupam cargos sérios na indústria de software, e é por isso que outras abordagens de programação nem mesmo são consideradas na maioria das empresas.
Tive que superar muitas dificuldades quando escrevi em idiomas OOP. E sempre me perguntei por que essas dificuldades surgiram. Talvez eu não fosse muito bom? Talvez eu precisasse aprender mais algumas dezenas de "padrões de programação"? No final, eu simplesmente não tive forças para tudo isso.
Este artigo contará a longa jornada de uma década que passei de OOP para programação funcional. Desde então, não me lembro de um caso em que me deparei com um projeto para o qual OOP seria mais adequado. Além disso, os projetos em que OOP foi usado caíram sob o peso da complexidade do código - a partir de algum ponto, era impossível mantê-los e desenvolvê-los.
TLDR
"Os programas orientados a objetos são a alternativa aos programas certos."
Edsger W. Dijkstra, pioneiro da ciência da computação
O objetivo do OOP era um - lidar com a complexidade do código procedural. Em outras palavras, OOP foi projetado para melhorar a organização do código. Mas desde então não houve nenhuma evidência de que OOP seja melhor do que a velha programação procedural.
A dura verdade é que OOP não fez a única coisa que foi projetado para fazer. Tudo parecia ótimo no papel - tínhamos hierarquias estritas de animais, cachorros, pessoas ... (E, claro, formas: retângulos, quadrados e círculos - onde podemos ir sem eles!) Mas conforme a complexidade do código do aplicativo aumentou, OOP não ajudou a reduzi-la , mas ao contrário aumentou - com toneladas de "padrões de programação" necessários e tornando difícil para o programador acompanhar onde e como os valores das variáveis mudam. OOP tornou muitos procedimentos comumente usados, como refatoração e teste, desnecessariamente complexos.
Muitas pessoas discordam de mim, mas o fato é que o design de OOP em C # ou Java não foi cientificamente pensado, não foi resultado de pesquisa científica séria. Ao contrário da programação funcional, por exemplo, em Haskell, onde o cálculo lambda é uma base teórica sólida. OOP não é baseado em nada parecido.
Em pequenos projetos, OOP tem um desempenho muito bom. Mas o que acontece quando o projeto cresce? OOP é uma bomba-relógio que inevitavelmente explodirá quando o código do projeto atingir um determinado tamanho. Os projetos começam a atrasar, os prazos falham, os desenvolvedores ficam sem energia e a adição de novos recursos torna-se quase impossível. No final, as empresas são forçadas a marcar esse código como "obsoleto" e forçar os desenvolvedores a reescrevê-lo.
OOP não se encaixa muito bem com a maneira como nossos cérebros pensam. Estamos acostumados a nos concentrar na ação: passear, conversar com um amigo, comer pizza. Nosso cérebro evoluiu para "fazer algo", e não para a construção de uma hierarquia complexa de objetos abstratos.
O código OOP é não determinístico (ao contrário da programação funcional): não podemos ter certeza de que, com os mesmos dados de entrada, obteremos o mesmo resultado todas as vezes. Isso torna muito difícil entender como o programa funciona. Aqui está um exemplo simples: compare 2 + 2 e calculator.Add (2, 2) . A última expressão, em teoria, deve sempre retornar 4, mas pode retornar 5, 3 ou até 1004, pois as dependências do objeto Calculadora pode mudar seu comportamento das maneiras mais imprevisíveis.