Tudo bem mano, sabemos que você não gosta de POO. Se não quiser usar, não use, mas não critique quem use.
Em nenhum momento eu critiquei quem usa. Eu apenas critiquei o paradigma e os argumentos feitos a favor dele. Então, por favor, não faça acusações falsas. Também digo o mesmo, se quer usar, use. (No entanto eu não recomendo. Foi por isso que fiz esse post. E a conclusão do meu post foi que se você ignorar POO seu código vai ficar mais simples. E quem não gostaria de ter código simples?)
E você não é o primeiro a fazer acusações falsas, outra pessoa disse que o exemplo que eu usei pra comparar procedural com OO foi "meio desonesto" de acordo com ela. Sendo que a métrica principal que eu usei foi linhas de códigos e o exemplo que eu peguei de OO foi justamente o com menor linhas de código! Eu escolhi cuidadosamente o exemplo para não ter nenhum comentário desse tipo, mas foi em vão.
Meus argumentos podem não ser a prova definitiva (porque isso seria impossível de provar, visto que não há uma "fórmula" que consiga fazer isso), no entanto acredito que levantei alguns pontos que valem a pena refletir.
Por exemplo, se você pesquisar 'why OOP is bad', ou algo similar, vai achar vários posts e pessoas criticando POO. Será que todas elas não entendem ou sabem do que estão falando? Se você pesquisar o oposto, vai achar pouco ou nada sobre. Então porque será que não tem posts/vídeos que mostram como POO é boa? Dá pra perceber que esses que defendem POO só aparecem quando alguém critica. Um exemplo disso é o vídeo do Brian Will. Um dos comentários com mais upvotes fala: "Actual title: "Overengineered solutions to simple problems are bad.", e esse comentário não tem sentido nenhum, porque os exemplos que ele deu foram de pessoas que são experientes com OO. Um dos exemplos é até do próprio Robert Martin! E ele mostra como a solução OO dele é mais complexa do que a solução procedural. E por isso eu acredito que a mentalidade de OO causa código complexo e não porque o programador é ruim.
E se mesmo depois de ler e entender meu ponto de vista, e ainda assim discordar, tudo bem. O importante é utilizar o pensamento crítico pra decidir se determinada coisa é boa ou não pra desenvolver software e também ser capaz de defender sua decisão. Porque muitos apenas repetem o que leem ou ouvem de livros/influenciadores/posts/vídeos sem saber do que está falando.
Eu nem li seu texto todo, mas li o suficiente pra saber bem do que você estava falando e o que você mais argumentou foi a complexidade do código e a má performance que isso pode trazer.
Sinceramente, isso foi o mais frustrante de ver nos comentários, as pessoas simplesmente leem por cima o post (um post que deu muito trabalho pra pesquisar e organizar as ideias) e depois comentam sem saber do que estão falando. Achei que o lugar 'massinha da internet' fosse diferente dos outros fóruns da net. Resolvi não excluir o post porque no fundo queria acreditar que no futuro, caso alguém esbarrasse no post, lesse o post, os links e também as réplicas e minhas tréplicas, pra assim fazer um comentário mais assertivo. Mas a realidade foi o completo oposto.
Eu posso te garantir que, em um sistema de gestão administrativa feito em Java e que gerencia milhões de objetos, o desempenho não cai. Se fosse assim, os mais de 8 ~ 11 mil objetos que a JVM carrega em tempo de execução pesaria todo um servidor. Sem contar que ninguém tem um Pc/Server batatão (um pentium com 2gb de ram) ao ponto de não conseguir lidar com objetos que pesam bytes na memória e mesmo assim, isso nao seria um problema tão grande.
Isso não faz o menor sentido. O que determina a performance não é a quantidade de objetos que tem em memória, mas sim como você acessa eles. O primeiro link sobre performance fala justamente sobre isso. De forma resumida, em um sistema OO os objetos são alocados em regiões diferentes de memória e isso causa vários cache misses que faz a CPU executar várias instruções para mover memória da RAM para o cache do processador. E isso também se aplica as V-Tables (tabelas virtuais) que são o mecanismo por traz dos métodos polimórficos. Se tiver interesse em saber mais sobre performance, recomendo o curso Performance-Aware Programming.
No segundo link sobre performance o palestrante mostra como a equipe dele trocou uma parte do sistema de animação do Chromium que era OO por um código Data-oriented, e afirma que teve vários benefícios, que inclui: melhor performance, mais fácil realizar testes automatizados e mais fácil manter/modificar.
Objetos contêm complexidade procedural, encapsulando funções e variáveis de dados para reutilização e padronização na forma como dados são tratados.
Você também consegue fazer isso com structs e funções.
Objetos também são muito úteis ao Serializar/Deserializar dados, enviá-los pela rede
Serializar/Deserializar não é exclusivo de Objetos. Por exemplo, em C, você consegue fazer isso com qualquer struct (mesmo com hierarquia de structs!) de forma trivial (desde que a struct não tenha ponteiros), usando fwrite e fread. Já num sistema OO você precisa criar/usar um algoritmo recursivo para ignorar qualquer coisa que não seja serializável. Por exemplo, em Java você teria que usar o ObjectInputStream e ObjectOutputStream, e a implementação deles são de ~2100 e ~1100 linhas de código respectivamente. Tudo isso de código pra fazer algo que deveria precisar apenas de umas ~10 linhas de código. (Usei o programa cloc pra contar as linhas de código.)
e, o mais importante de tudo, fornecer uma maneira de isolar comportamento externo. Por exemplo, usar um objeto Session bem definido em Java pra isolar o carregamento de código arbitrário pelo usuário aumenta muito a segurança e estabilidade geral do sistema, pois a Session, se não corrompida, pode ser anexada e, se corrompida, descartada.
Como não programa em Java, não conheço muito sobre esse objeto Session, mas pela descrição não parece ser algo que seja apenas possível utilizando objetos. Você pode simplesmente ter uma struct Session e funções que operam nela, sem a necessidade de acoplar os dois numa estrutura só.
Tudo o que usamos hoje em dia é semelhante a objetos: Tvs, smartphones, Caixa de ferramentas, fogão, geladeira... Qualquer coisa que tenha comportamento ou que contenha comportamento empacotado ou que pode conter tal comportamento pode ser um objeto.
Não tô dizendo que outros modelos ou paradigmas são um lixo, mas sim que expor esse pensamento é anti produtivo. Não quer usar? Não use. Não gosta? Apenas diga que não gosta. Mas tentar provar que tal coisa é um lixo, sendo
que parte do mundo que conhecemos é feito dessa forma é um pensamento bem imaturo.
Esse argumento não faz nenhum sentido pra mim. Então eu poderia criar a Programção Orientada a Átomos e dizer que seria imaturo pensar que tal mentalidade/paradigma é um lixo, visto que tudo no universo é feito de átomos. Além disso um dos maiores defensores da OO, Robert Martin, discorda totalmente dessa ideia que OO serve para modelar o mundo real. Como eu já disse acima eu não consigo provar que POO é um lixo, apenas tentar mostrar evidências que apontam pra isso. Tudo bem se você discorda, mas pelo menos tente embasar melhor sua argumentação.
Tem coisas que não gosto em python, js e outras linguagens, mas nem por isso desestimulo os outros a usarem.
Em nenhum momento desistimulei as pessoas a usarem alguma linguagem. De novo, eu apenas critiquei o paradigma.
Eu desestimulo, sim, as pessoas a não fazerem merda. Até porque desenvolver software é uma tarefa séria e manipular dados privados de forma porca, só porque uma coisa não convém faz de você um péssimo profissional.
Concordo, por isso que fiz esse post. Pra tentar quebrar o status quo de "boas práticas" que mais causam problemas do que ajudam. Mas esse status quo é muito forte. Em outro comentário eu disse que até tinha outros posts provocativos pra postar, mas depois de ver a péssima qualidade dos comentários e o extremo repúdio, isso me fez desistir. Eu não sou o primeiro e nem serei o último a criticar POO.
E acredito que Casey Muratori tenha as melhores críticas contra OO. Segundo ele o problema está em 'orientar' seu software com objetos, ou seja, os objetos serem a peça central do seu código, e não os objetos em si. Recomendo esse post e esse. E também uma palestra recente sobre a história da POO.
O que significa 'manipular dados privados de forma porca' e como isso se relaciona com ser um péssimo profissional? Em que momento eu incentivei a fazer um trabalho porco?
Num mundo onde a segurança dos dados se tornou algo preocupante e as máquinas estão ficando cada vez mais tunadas, argumentar sobre isso se tornou algo inviável. Devemos discutir sobre melhores técnicas de segurança de dados, melhores técnicas de modelagem de dados, independente do paradigma usado, melhores abordagens pra se iniciar o desenvolvimento de um software em larga escala nos dias atuais
Fique a vontade para discutir sobre esses assuntos, basta criar seu post no Tabnews.
Um dos argumentos que os defensores de POO usam é que POO é mais adequada para software grandes e complexos. Isso eu abordei no meu post. Mas, agora imagina que algum dia alguém consiga provar que POO não é a melhor maneira de iniciar um projeto de larga escala? Não teria sido melhor ter analisado os argumentos das pessoas que criticaram pra tentar chegar numa solução melhor?
não sobre esse tipo de discussão que parece ter morrido em 2014.
E o mais irônico é que você desenterrou um post de quase dois anos de idade e com vários downvotes só pra discutir sobre isso. Mas olhando de novo pra esse tópico e baseado nas outras discussões online, percebi que falar sobre OO é puro bike shedding, já que até mesmo entre as pessoas que defendem não conseguem chegar a um consenso sobre o que realmente é OO.
Enfim, seja um Dev, não um entusiasta. Aprenda a resolver os problemas dos outros e não criar mais problemas dos que já existem. Deixe otimizações com os mantenedores da linguagem e depois rode um profiler a cada update pra ver se a técnica que você usa ainda performa bem no mais baixo nivel, em escala de bytes, nibbles e ate bits.
Ter uma opinião formada, embasada e escrito um post sobre isso não torma de mim um entusiasta. De certa forma, eu estou tentando resolver os problemas dos outros, como disse na minha conclusão do post, o seu código ficará mais simples se ignorar POO. Se você olhar no ecossistema JavaScript verá que tem muitas pessoas que reescreveram ferramentas de JavaScript para Rust ou Go para ter maior performance. Não é algo nichado como muitos pensam. Tem um vídeo do Casey Muratori que mostra várias empresas grandes que reescreveram a stack inteira para melhorar a performance, porque isso tinha um impacto direto no faturamento da empresa. E de novo você faz mais uma acusação, quais problemas eu estou criando?
Pra concluir, o seu comentário parece uma tentativa de censura. Vivemos num país com liberdade de expressão. Se você não gosta do que eu escrevo, então não leia (Esqueci, você não leu mesmo). E isso pra mim isso revela total falta de maturidade emocional. Parece que você ficou ofendido com a minha crítica porque OO é seu paradigma preferido e sentiu a necessidade de desenterrar o post e me censurar. Além disso você já conseguiu essa censura, nunca mais eu postei algo sobre POO aqui no Tabnews depois de ver a reação tão negativa e comentários tão ruins.
E também foi extremamente ridículo você tentar dar 'liçãozinha' de moral em mim.