Executando verificação de segurança...
12
GustavoFurtadoFatality
3 min de leitura ·

[Dúvida] Porque muitos acham que a Orientação a Objetos é ruim?

Sou um adolescente e não tenho experiencia real de emprego então talvez possa estar falando merda de muitas coisas que vivenciei, mas tento ser lógico e analisar as situações :v.

Não tenho dados para provar que muitos achem isso, mas muitos por ai, pensam nisso.
E tudo bem de certa forma, porque cada um tem sua opinião, mas muitos opinam sobre algo sem ter experiencia ou habilidade, daquilo que falam, muitos falam e afirmam sobre coisas que não sabem direito, e tudo bem de certa forma também, todo mundo pode opinar, mas muitas dessas pessoas inexperientes ou iniciantes, acabam definindo a narrativa da internet, com frases tipo, "C é dificil", "X não escala" (ah sim, como se sua única experiencia individual conta-se ;-;), novamente, não tenho dados para provar isso, mas acontece, acontece, que muitos acabam odiando algo, porque alguem mais experiente odeia tambem, e certas vezes acontecendo que pessoas odeiam a mesma coisa por motivos totalmente diferentes, muitas vezes por imaturidade própria. Hoje em dia, é muito mais acessivel programar do que antigamente, e isso é bom! mas, hoje em dia fazer um projetinho ou resolver algum algoritmo, e a pessoa acha que já é programador, orientação a objetos é muito mais do que classes ou campos de dados, e também não é apenas uma coisa, e sim um conjunto de coisas (muitas dessas coisas de separadas ja existiam e eram aplicadas antes do OO ser amplamente adotado), consigo então afirmar que muitos usam OO, mas não sabem como usar (pra ser sincero, eu também não sei muito), fazer OO não é tão dificil, fazer correto é dificil. Já vi algumas pessoas dizer que OO foi apresentado como a solução de todos nossos problemas, e pra ser sincero, acredito que isso realmente aconteceu, mas agora o coice que a OO esta tomando pela programação funcional(não que isso seja realmente verdade, mas é oque algumas pessoas da internet acreditam), e agora, a programação funcional está se tornando endeusada, muitas adotam a programação funcional, linguagem Rust, por modinha e hype, oque me entristece um pouco. Há criticas válida de pessoal experiente da nossa área com propriedade para criticar sobre assunto, pessoas menos experientes acabam repetindo sem entender de fato oque foi dito, e ainda distorcer isto. Ainda assim fico muito em dúvida nessas situações, quando há duas pessoas com propriedade, com opiniões bem opostas (ou pelo menos que parece do meu ponto de vista). Eu pessoalmente não gosto que alguem tente fazer tudo em OO ou tudo em programação funcional (se é que de verdade eles estão fazendo apenas isso, provavelmente estarão fazendo a programação estruturada junto).
Concluindo, acredito que OO seja mal usado, e muitos pode ter motivos banais não gostarem, mas tambem pode ter otimos motivos, cada programador tem suas ferramentas preferidas. Gostaria de compartilhar algumas visões na internet sobre o assunto que achei boas:

"Por que tantos desenvolvedores odeiam programação orientada a objetos?"
Resposta de Jose Morins sobre a pergunta:

Resposta do Maniero sobre a pergunta:






mas lembre-se, isso aqui é uma pergunta, estarei feliz de ler as respostas.

Outra pergunta: que maneiras boas de programar sem usar o paradigma OOP e sem usar o paradigma funcional?

Carregando publicação patrocinada...
6
maniero

muitos falam e afirmam sobre coisas que não sabem direito

Verdade.

muitas dessas pessoas inexperientes ou iniciantes, acabam definindo a narrativa da internet

Isso mesmo.

muitos usam OO, mas não sabem como usar

Perfeito.

fazer OO não é tão dificil, fazer correto é dificil

Exatamente.

a programação funcional está se tornando endeusada

Assim como acontece com OOP, mas os problemas de se adotar cada uma é diferente. De fato o funcional puro não é tão útil assim. Anedoticamente o criador de Haskell disse que a linguagem dele não serve para nada real. Adotar o paradigma funcional dentro de um código imperativo pode ser bem interessante em certos casos.

por modinha e hype

Modinha é o que usamos no Brasil para o hype. OOP é modinha. O que as pessoas não entendem sobre moda é que ela não efêmera, o entendimento de quase todo mundo, ela é sobre principalmente algo usado porque outras pessoas estão usando. OOP é muito modinha, mesmo que ela exista a décadas, esteja consolidada e vá durar por muito mais tempo. Note que muitos casos ela será a melhor solução, o que não impede de ser adotada por modinha. Até eu faço isso.

Funcional é modinha para algumas pessoas, não é para outras, mas assim como OOP, em geral é adotado por modinha.

pessoas menos experientes acabam repetindo sem entender de fato oque foi dito, e ainda distorcer isto

Isso mesmo. Eu estudo e pratico (pra ficar claro) OOP há 40 anos. Mais recentemente (poucos anos) eu comecei achar que entendi OOP, mesmo assim estou alerta porque posso ter entendido algo errado, mas o básico eu sei. Sei por exemplo que existem duas escolas de OOP e que a maioria adota um pedaço de cada criando uma definição toda própria, embora ela acabe sendo popular em tempos de internet e influenciadores.

não gosto que alguem tente fazer tudo em OO ou tudo em programação funcional

Uma coisa não elimina a outra, para entender melhor sobre paradigmas:

Provavelmente preciso revisar algumas coisas aí, mas farei só nas minhas iniciativas próprias (veja mais no fim desta resposta). Tem coisas aí com mais de 10 anos, eu certamente aprendi melhor sobre o assunto durante esse período e mudaria alguns pontos.

Isso algo que todos deveriam entender, até mesmo algo escrito pelos melhores programadores (que não é o meu caso), pode ficar datado e a pessoa não vai lá corrigir o erro que cometeu naquela época. Desconfie de tudo o que lê (ou vê ou ouça), sem entrar em paranoia ou se tornar arrogante achando que sabe tudo.

provavelmente estarão fazendo a programação estruturada junto

Entenda melhor nos links acima e pesquise mais por conta própria.

A postagem do José Morins é quase perfeita. OOP não depende de classes para existir.

Vai ajudar: https://pt.stackoverflow.com/q/205482/101.

Não vou comentar prints de resposta minha;)

Concordo com os demais prints mesmo não sabendo que quem são, acho que alguma é minha.

Como eu já disse acima, existe o paradigma Modular, mas ele é pouco adotado pelas linguagens, então ele não se torna popular, mas mesmo sem mecanismos específicos é possível programar assim na maioria das linguagens. Mas ficará pouco idiomático. Veja https://pt.stackoverflow.com/q/223549/101. Para esmagadora maioria dos problemas o ideal é ter a programação imperativa com vários mecanismos de funcional e alguma forma de modularizar a base de código, e não tem como não dizer que o mais fácil hoje é com OOP. Fugiu disso você está sendo "mosca branca" e terá algumas dificuldades por causa do mercado. Tem horas que devemos ceder à modinha porque todo mundo trabalha em prol dela. Mas podemos fazer de forma crítica, podemos fazer sem radicalismos. Me lembro que teve uma época que se ouvia muito algumas pessoas "denunciando" que algo foi feito sem OOP e isso é ruim por si só, mas não vejo muito isso mais, ou caíram na real, ou perderam espaço ou teve algum outro fenômeno.

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).

2
marcomvidal

Ola, Gustavo.

Sua reflexão é bem interessante e eu pessoalmente me identifico com ela, pois percebi algo parecido quando estava aprendendo programação. Em especial, naquele momento que comecei a aprender os primeiros conceitos de orientação a objetos, olhei para meus primeiros algoritmos e tentei inaginar como faria para aplicar esse conceito a eles.

Eu gosto muito de ambos os paradigmas - Orientado a Objetos e Funcional - e tendo vivenciado programar com ambos por quase uma década em aplicações comerciais, constatei as linguagens de programação mais populares (Java, C#, JavaScript, PHP, Python, etc) bebem das duas fontes. A programação pragmática aplicada no mercado de trabalho tende a explorar as particularidades de cada um onde isso tornar o código mais expressivo, fácil de construir e manter. Tanto que linguagens puristas, como SmallTalk (em OOP) ou Haskell (em FP) tendem a ter uma difusão mais restrita.

Não que eu desencoraje que linguagens mais puristas sejam exploradas, pelo contrário. Desenvolver um projeto em Haskell, por exemplo, para quem tem uma base forte em OOP num primeiro momento pode parecer frustrante, mas é extremamente enriquecedor em termos de encontrar novas abordagens de resolver problemas e nos tornar melhores programadores de forma geral. Aprender FP pode te tornar um melhor programador OOP, ainda que isso possa parecer contraditório, já que pode te deixar consciente das limitações do paradigma e de como contorná-las da melhor forma possível.

Indo à sua questão, acredito que muito do criticismo sobre OOP é devido a tipo de programação predominante atualmente, ao menos quando falamos em software empresarial. Compare com qualquer outra ciência e vai ver que tudo que é status quo em um momento é alvo de maiores ponderações.

Com isso, quero dizer que OOP é perfeita? Certamente que não. É um paradigma muito rico conceitos e te dá muitas possibilidades de estruturar um projeto que, às vezes, pode te levar a construir software de uma forma que dificulta a manutenabilidade. Porém, isso é questão de maturidade e maestria para aplicar os conceitos de formas positivas.

Muita gente argumenta que aplicar OOP pode deixar seu código difícil de manter. Dependendo de como, isso é verdadeiro, mas com FP, é possível terminar com o mesmo problema. O conceito de currying é muito bacana, por exemplo, mas dependendo de como é aplicado, pode diminuir a legibilidade e dificultar a manutenção de um código se mal aplicado.

Sobre OOP e boas práticas, eu diria que os conceitos principais precisam ser bem compreendidos, mas a aplicação deles tem que ser cuidadosa. Herança, por exemplo, é um conceito muito interessante e útil, mas sua aplicação tem que muito cuidadosa e restrita para evitar terminar com um codigo que é desnecessariamente complexo.

Eu diria para focar no âmago do paradigma - que é sobre trocas de mensagens entre objetos -, e priorizar sempre a composição em relação a herança.

Da mesma forma, aplicar conceitos de FP quando eles facilitam a compreensão e manutenabilidade do código, como funções de primeira ordem. Que dependendo do caso, usar métodos estáticos não é nenhum crime e pode ser a melhor forma de resolver um dado problema (funções de utilidades, por exemplo).

Por fim, lembrar que código bom é que código que é seguro, veloz, que pode ser facilmente compreendido e mantido por diferentes pessoas.

2
teknolista

O criador da OOP disse que as pessoas utilizam o conceito errado, e que ele talvez devesse ter escolhido outra nomenclatura porque isso confundiu muito as pessoas.

2
maniero

Qual criador? Podemos colocar pelo menos 3 criadores (na verdade um deles é uma dupla, então 4 pessoas). Podemos considerar duas escolas porque a dupla e um dos criadores (do C++) seguiram o mesmo caminho, apesar de Simula, a primeira que usou o que conhecemos como OOP, ser um pouco diferente de C++. O biólogo Alan Kay criou o termo, mas ele mesmo reconheceu o que ele chamou inicialmente de orientação a objetos é na verdade orientação à mensagens. Ainda que ele tome pra si a criação do termo e acha errado o que o Bjarne Stroustrup criou e chamou de OOP.

2
LucasAyabe

Eu realmente amo o tema, mas quanto mais eu leio, mais eu tenho a impressão que enquanto é útil dividir entre duas escolas principalmente para não ser pedante ao conversar sobre o assunto no dia-a-dia, a verdade é que só uma representa de fato um novo paradigma.

A escola de Simula (C++, Java, etc) não é exatamente um novo paradigma.

Eu vejo que a única escola com espinha dorsal mesmo para ser um paradigma seria a tradição do Smalltalk (Pharo, Ruby, Crystal, etc) mesmo, pois é a única baseada num novo modelo conceitual de verdade mesmo.

Veja se a gente pegar os textos que deram origem a Simula, ela era só uma linguagem procedural com uma feature nova que ajudava naquele domínio que ela atuava, era quase uma DSL em cima de uma linguagem procedural comum.

Herança mesmo vinha de um paper também sobre o paradigma da época que era a programação imperativa/procedural/estruturada. Tanto que o paper falava sobre estender structs (records).

Ela focava exclusivamente em reúso de código.

"Encapsulamento" também não era exatamente algo que nasceu no contexto orientado a objetos já que information hiding já era algo bem discutido muito antes disso e tem exemplos de linguagens procedurais adotando mecanismos similares ao que a gente tem de modificadores de visibilidade já naquela época.

Como o próprio Alan Kay reclama no famoso e-mail com a definição de OO, polimorfismo é uma propriedade de funções não de objetos. Na época que eu li, eu não tinha entendido isso, mas hoje em dia, eu percebo que realmente não faz sentido falar em polimorfismo quando se tem troca de mensagens visto que elas são um mecanismo totalmente diferente de expressar comportamento (embora eu não goste do nome que ele deu também).

Simula deu origem ao sistema de objetos que usamos hoje em dia, mas não a POO.

Por outro lado, quando a gente pega a pesquisa acadêmica no pós-Simula, principalmente os trabalhos da Liskov por exemplo, a gente nota que o pessoal tinha um entusiasmo no desenvolvimento de novas técnicas relacionadas a sistemas de tipos e não sobre um novo paradigma.

Todo o hype em torno de herança, na verdade, vinha na direção contrária do que foi o interessante que fez ela nascer.

Era um hype focado nas possibilidades de ADTs e nas propriedades de substitucionalidade descobertas por Liskov (o L do SOLID).

Isso que gerou a contradição que é a feature de herança na maioria das linguagens e depois foi resolvida separando ela nos dois componentes que ela representava (interfaces + traits ou mixins).

Como dá pra notar, isso é muito mais próximo de uma evolução do próprio paradigma procedural para enquadrar elementos de programação modular no paradigma do que a criação de um novo paradigma.

O core de como se pensa numa aplicação e estrutura a lógica não muda muito.

É semelhante a como sistemas baseados em efeitos estão surgindo na FP agora, mas a gente não chama isso de programação orientada a efeitos, a gente continua chamando de FP por continuar a tradição lógica do paradigma.

Mas por que a gente tem uma impressão de que a OO muda tudo? Que procedural não se parece nada com OO?

Depois de me questionar muito sobre esse tema, a minha conclusão é que isso acontece por uma mudança de paradigma não na programação, mas sim na engenharia de software.

É interessante pegar livros influentes da era de ouro da OO de autores consagrados pra ver o que eles entendiam como OO.

E quanto mais perto você chega de autores relacionados a UML ou do OOD, mais você nota que eles não estão discutindo um paradigma de programação ali, mas sim engenharia de software.

Não a toa, as coisas se misturaram, pois na época o que trouxe o hype mesmo da OO na indústria foi uma mudança de mentalidade quanto a como a gente faz engenharia de software não sobre como se programa em si.

A gente transitou de pensar nas coisas como algoritmos e visualizar sistemas como coleções de fluxogramas para as técnicas de OOD e mais tarde se consolidando na UML.

É daí que sai a noção de que OO é programar representando o mundo real pois a gente teve uma mudança de paradigma em como nos aproximamos do problema e modelamos sistemas.

Muito embora essa definição sirva pra qualquer paradigma, em procedural já era comum dizer que você conhece o sistema pelas suas estruturas de dados e em FP a gente tem type driven development pela proeminência de sistemas de tipos algébricos nessas linguagens, mas mesmo em linguagens dinâmicas se usam módulos pra criar coisas muito semelhantes a classes em linguagens como Elixir por exemplo.

Ótimo, mas mesmo se a gente aceita essa premissa, como a tradição do Smalltalk seria diferente?

Ela é diferente pois a lógica toda tem que ser pensada num meio totalmente diferente que é a troca de mensagens.

Quando se entende isso, a gente nota que a confusão começa por chamar tudo de objeto, mas a definição de Smalltalk é diferente da de Simula.

Um objeto em Smalltalk é simplesmente um receptor de mensagens, enquanto um objeto em Simula é um conjunto de dados e funções.

Isso tem uma implicação até na semântica do código, pois uma chamada de função pode ter o seu dado inexistente, já quando você envia uma mensagem, o objeto pode não existir (por default seria null, mas ele também é um objeto), o método pode não existir e o dado também não é necessário existir.

Isso porque objetos podem lidar com mensagens que eles não conhecem então não importa se o método existe ou não, a mensagem pode ser enviada ao objeto pois ele tem um mecanismo para lidar com mensagens desconhecidas.

Você não consegue fazer isso com funções sem recriar uma estrutura que tenta imitar a infraestrutura que faz os objetos funcionarem.

Troca de mensagens implica que você tem um receptor na equação, que é um elemento que simplesmente não existe quando a gente fala de funções.

Como você não tem garantia de nada, você programa só confiando em contratos no sentido de que X sabe como responder a determinada mensagem.

Que é semelhante ao que acontece em sistemas com arquiteturas baseadas em eventos atualmente.

Isso é interessante pois você pode escolher responder, ignorar, redirecionar (delegar), fazer broadcast, modificar e reenviar, etc. Com mensagens, e isso é algo que no mínimo é bem diferente quando a gente trata de funções mesmo considerando as de alta ordem. O valor aqui é menos na composição e mais em como você decide quem lida com aquilo.

Pode não parecer tão interessante assim, até você notar o poder de programar com proxies.

Teoricamente, esse modelo é null-safe por padrão, visto que você pode ter um objeto null que simplesmente implementa o method_missing e qualquer coisa que não existe redireciona para ele que pode decidir só ignorar qualquer imagem recebida, você pode implementar o protocolo null em todos os objetos e realmente ter cada operador de null safety como um método presente em todos os objetos (o que faz sentido já que todo objeto é potencialmente nulo).

Tem um artigo ótimo da comunidade Objective-C que foi o que abriu minha mente que troca de mensagens realmente era algo completamente diferente de funções que é o paper sobre HOMs (High Order Messages).

Lá o autor discute uma técnica sobre como você usa proxies dinamicos pra reificar mensagens e assim conseguir manipular elas.

O uso principal é lidar com coleções, implementar o famoso mao, filter e reduce usando só troca de mensagens.

Mas o artigo vai além mostrando coisas que seriam difíceis de implementar só com high order functions tipo broadcast cruzado de mensagens entre duas coleções.

O truque que eu achei mais interessante é como troca de mensagens te dá concorrência de graça.

Aqui encapsulamento ganhou um significado a mais para mim.

Encapsulamento é sobre ter posse do seu próprio estado, então não é tanto sobre as garantias ou proteger contra invariantes e etc. Isso são bônus legais que você ganha com encapsulamento.

O ponto mesmo é cada unidade ser dona do seu próprio estado mesmo que ele seja público.

Isso porque se o encapsulamento realmente for perfeito, você pode converter um objeto num processo ou numa thread sem problema nenhum.

Concorrência é simplesmente colocar um proxy na frente do objeto para isolar ele fisicamente ou virtualmente, e redirecionar todas as mensagens do processo ou thread pro objeto.

Comunicação entre processos também não é nada de outro mundo, visto que ela se resume a simplesmente troca de mensagens também.

Isso é possível pois você pode escrever uma HOM que enfilera todas as mensagens recebidas de forma assíncrona, e depois faz o replay delas pro objeto dentro do proxy quase que criando um ator de pobre.

Como pro objeto as mensagens vem em sequência, você pode ter estado mutável pois isso não é compartilhado entre threads ou processos ou atores, etc. Você não tem problemas com race conditions que levam a corrupções (ainda teria algum problema de um edge case com deadlocks, mas isso teria que ser resolvido com outro paradigma como o Actor Model que é desenhado para ser 100% compatível com concorrência).

Ainda nesse assunto, acho que o que mostra como objetos são diferentes de funções é que em FP você precisa de containers pra lidar com concorrência então você tem algo como monads ou as promises do JS.

Se você se baseia em troca de mensagens, você pode escrever código assíncrono de forma sincrona sem async/await pois você não tem o problema da função colorida.

Você pode usar HOMs pra implementar promises transparentes que é como alguns dialetos de Smalltalk implementam Futures.

Do lado de como a gente pensa no código também muda bastante pois você tem que pensar em termos de conversas entre objetos.

Isso pode parecer só um jargão, mas eu vejo isso como programar com Tell Don't Ask.

Normalmente essa é só uma nota de rodapé no estudo da OO até porque o type system de muitas das linguagens mainstream não serve pra implementar double dispatch (visitors por exemplo são muito verbosos e as pessoas odeiam, por isso que pattern matching + algebraic data types ganhou tanta força como um appeal das linguagens funcionais).

Mas eu gosto muito da explicação da Sandi Metz sobre como programar com patos em Ruby, o trabalho dela é sensacional em explicar os benefícios de abraçar o TDA e muitas vezes acabar representando a conversa entre objetos por meio de double dispatch.

Isso não funciona bem numa linguagem como Java pois seria extremamente verboso e ainda teria alguns problemas com acoplamento.

Mas ao abraçar o espírito da troca de mensagens, se vê que é uma forma bem interessante até de programar e que inclusive é o que faz muitas pessoas cairem nas graças de linguagens como Go ou Elixir hoje em dia (embora o mecanismo seja invertido então você não tem os benefícios da troca de mensagens nesses casos).

Código OO tende lembrar mais uma coreografia do que uma orquestração se a gente for colocar em termos de sistemas distribuídos.

Por esses e outros motivos que eu considero que as ideias de Kay realmente eram um novo paradigma enquanto Simula foi um novo paradigma só na engenharia de software, mas não na programação, como paradigma de programação, ela é só uma continuação de como procedural já estava avançando na época.

1
maniero

A escola de Simula (C++, Java, etc) não é exatamente um novo paradigma.

Exatamente

Eu vejo que a única escola com espinha dorsal mesmo para ser um paradigma seria a tradição do Smalltalk (Pharo, Ruby, Crystal, etc) mesmo, pois é a única baseada num novo modelo conceitual de verdade mesmo

Na verdade, não, nem mesmo Smalltalk é 100% pura como OO que na verdade é orientada a mensagens e não a objetos. As demais sequer chegam perto dessa ideia, são linguagens imperativas com alguns recursos para facilitar a orientação a objetos, o resto é marketing. Aí precisaria estudar várias questões, pode ajudar ver a meu outro comentário aqui nesta página.

Veja se a gente pegar os textos que deram origem a Simula, ela era só uma linguagem procedural com uma feature nova que ajudava naquele domínio que ela atuava, era quase uma DSL em cima de uma linguagem procedural comum.

Isso.

Herança mesmo vinha de um paper também sobre o paradigma da época que era a programação imperativa/procedural/estruturada. Tanto que o paper falava sobre estender structs (records).

Não sei, tem fontes que eu possa ver sobre isso?

Ela focava exclusivamente em reúso de código.

Cuja herança é um dos piores mecanismos para fazer isto.

"Encapsulamento" também não era exatamente algo que nasceu no contexto orientado a objetos já que information hiding já era algo bem discutido muito antes disso e tem exemplos de linguagens procedurais adotando mecanismos similares ao que a gente tem de modificadores de visibilidade já naquela época.

Certo, ainda que algumas pessoas gostem de dizer que isso é o mais importante para OOP, não eu.

Como o próprio Alan Kay reclama no famoso e-mail com a definição de OO, polimorfismo é uma propriedade de funções não de objetos. Na época que eu li, eu não tinha entendido isso, mas hoje em dia, eu percebo que realmente não faz sentido falar em polimorfismo quando se tem troca de mensagens visto que elas são um mecanismo totalmente diferente de expressar comportamento (embora eu não goste do nome que ele deu também).

Se eu entendi seu texto, posso dizer que o próprio não gosta do termo que ele criou, mas ele pe resistente em falar isso de forma clara. Ele é bem apegado às coisas dele e é uma pessoa bastante orgulhosa (sem juízo de valor).

Simula deu origem ao sistema de objetos que usamos hoje em dia, mas não a POO.

Precisaria de clarificação aqui, mas acho que não. Talvez se considerar que os mecanismos não eram tão óbvios quanto em C++ e as linguagens que se inspiraram nela.

Por outro lado, quando a gente pega a pesquisa acadêmica no pós-Simula, principalmente os trabalhos da Liskov por exemplo, a gente nota que o pessoal tinha um entusiasmo no desenvolvimento de novas técnicas relacionadas a sistemas de tipos e não sobre um novo paradigma.

Sim, e com razão.

Todo o hype em torno de herança, na verdade, vinha na direção contrária do que foi o interessante que fez ela nascer.

Que muita gente não percebe.

Isso que gerou a contradição que é a feature de herança na maioria das linguagens e depois foi resolvida separando ela nos dois componentes que ela representava (interfaces + traits ou mixins).

Estamos de acordo.

Como dá pra notar, isso é muito mais próximo de uma evolução do próprio paradigma procedural para enquadrar elementos de programação modular no paradigma do que a criação de um novo paradigma.

Conforme já falamos disso e falo mais nos links do meu outro comentário. As pessoas sequer entendem o que é um paradigma, e a Wikipedia faz o desserviço de ensinar errado.

É semelhante a como sistemas baseados em efeitos estão surgindo na FP agora, mas a gente não chama isso de programação orientada a efeitos, a gente continua chamando de FP por continuar a tradição lógica do paradigma.

Talvez.

Depois de me questionar muito sobre esse tema, a minha conclusão é que isso acontece por uma mudança de paradigma não na programação, mas sim na engenharia de software.

É uma possibilidade.

A gente transitou de pensar nas coisas como algoritmos e visualizar sistemas como coleções de fluxogramas para as técnicas de OOD e mais tarde se consolidando na UML.

Quando tudo começou ficar nebuloso na programação, mas a maioria estava fazendo suas preces ao novo deus.

É daí que sai a noção de que OO é programar representando o mundo real pois a gente teve uma mudança de paradigma em como nos aproximamos do problema e modelamos sistemas.

Que é uma das maiores imbecilidades já ditas na computação. Mas atendia ao interesse do biólogo que criou isto.

Um objeto em Smalltalk é simplesmente um receptor de mensagens, enquanto um objeto em Simula é um conjunto de dados e funções.

Vamos combinar que Smalltalk é um completo fracasso porque as pessoas não querem pensar assim e Simula não teve nenhuma proeminência por questões mercadológicas (timing e ação).

Eu não tenho muito interesse em falar sobre Smalltalk ou OOP do Alan Kay, sobre troca de mensagens, porque eu não vejo tanto valor conceitual assim e não tem uso disseminado no mercado (que eu até ignoraria se fosse algo muito bom). O mesmo vale para Simula, eu nunca a usei, só serviu para entender melhor onde estamos.

Tem um artigo ótimo da comunidade Objective-C que foi o que abriu minha mente que troca de mensagens realmente era algo completamente diferente de funções que é o paper sobre HOMs (High Order Messages).

Preciso ver sobre isso, mas não acho que vá mudar muito pensamento.

O truque que eu achei mais interessante é como troca de mensagens te dá concorrência de graça.

Levando em consideração que você já paga um preço alto sem a concorrência.

O ponto mesmo é cada unidade ser dona do seu próprio estado mesmo que ele seja público.

Já é uma visão melhor que da maioria.

Isso porque se o encapsulamento realmente for perfeito, você pode converter um objeto num processo ou numa thread sem problema nenhum.

Não sei, não tenho informações suficientes para falar sobre.

Normalmente essa é só uma nota de rodapé no estudo da OO até porque o type system de muitas das linguagens mainstream não serve pra implementar double dispatch (visitors por exemplo são muito verbosos e as pessoas odeiam, por isso que pattern matching + algebraic data types ganhou tanta força como um appeal das linguagens funcionais).

Sim.

No fim, temos aí o mercado ditando o que usamos, para o bem ou para o mal. E temos profissionais que estudam isso a fundo e toma decisões idealistas ou pragmáticas e temos as pessoas que só fazem o que aprendeu com alguém em algum lugar sem se preocupar se aquilo era bom ou ruim, certou ou errado, só importava que funcionava e estava na moda.

2
LucasAyabe

Na verdade, não, nem mesmo Smalltalk é 100% pura como OO que na verdade é orientada a mensagens e não a objetos.

Eu concordo que Smalltalk poderia ser mais puro, ele toma vários atalhos de design emprestados de FP, mas o core da linguagem é puramente orientado a objetos e você consegue implementar o design correto baseado só nas ferramentas base da linguagem (o objeto como uma unidade receptora de mensagens). Isso é demonstrado no paper sobre HOMs que eu citei.

Apesar disso eu rejeito a ideia de que existe um paradigma orientado a mensagens puro, seria como dizer que existe um paradigma orientado a funções puro só porque procedures e funções puras tem como base o mesmo mecanismo. Existem tipos de trocas de mensagem, e é isso que diferencia OO de Actor Model por exemplo.

Eu também não gosto da ideia de mudar quem está correto nessa história só porque o que é popular foi quem não significa as ideias originais e nem tem elementos suficientes para ser considerado um paradigma de fato.

Então se eu tivesse que escolher alguém para desistir do nome seria a tradição de Simula, a gente pode chamar de programação orientada a classes e seguir feliz com isso. Até porque todas as linguagens derivadas do sistema de protótipos respeitam bem a ideia original de troca de mensagens do Kay (tá o JS nem tanto, mas ele é flexível o suficiente para você conseguir algo parecido mesmo com a sintaxe atrapalhando).

Eu diria que o próprio Self, origem do JS, seria mais OO que o Smalltalk por ter entendido que classes são um utilitário legal, mas a unidade irredutível é você ter um receptor de mensagens, então você pode fazer tudo simplesmente clonando os objetos e mudando como eles interpretam as novas mensagens.

Herança mesmo vinha de um paper também sobre o paradigma da época que era a programação imperativa/procedural/estruturada. Tanto que o paper falava sobre estender structs (records).
Não sei, tem fontes que eu possa ver sobre isso?

Relendo o próprio paper do criador de Simula que conta a história da linguagem, eu vejo que eles introduziram até o conceito de classes baseado nisso:
https://www.mn.uio.no/ifi/english/about/ole-johan-dahl/bibliography/the-birth-of-object-orientation-the-simula-languages.pdf

O conceito de herança vem desse paper aqui que introduzia um conceito chamado de Hoare Records:
https://archive.computerhistory.org/resources/text/Knuth_Don_X4100/PDF_index/k-9-pdf/k-9-u2293-Record-Handling-Hoare.pdf

"Encapsulamento" também não era exatamente algo que nasceu no contexto orientado a objetos já que information hiding já era algo bem discutido muito antes disso e tem exemplos de linguagens procedurais adotando mecanismos similares ao que a gente tem de modificadores de visibilidade já naquela época.
Certo, ainda que algumas pessoas gostem de dizer que isso é o mais importante para OOP, não eu.

Eu também não, a coisa irredutível do paradigma é troca de mensagens com elas podendo ser síncronas. Se você assume só mensagens assíncronas, o modelo computacional é diferente, pois ele tem implicações lógicas diferentes, e nesse caso a gente estaria falando de Actor Model que surgiu mais ou menos na mesma época. Apesar disso, se você pega aquele Kay que escreveu o texto sobre a origem do Smalltalk, eu tenho a forte sensação que seria a cara dele chamar o Actor Model de algo "bem orientado a objetos" kkkk.

Se eu entendi seu texto, posso dizer que o próprio não gosta do termo que ele criou, mas ele pe resistente em falar isso de forma clara. Ele é bem apegado às coisas dele e é uma pessoa bastante orgulhosa (sem juízo de valor).

Olha, existe mesmo um texto do Kay onde ele diz que se arrepende de ter cunhado o termo e anos depois as pessoas não terem entendido nada, e focado na ideia que era só um detalhe para ele, mas isso ele diz na troca de e-mails na comunidade do Self, no meio de uma discussão do povo se OO eram classes ou protótipos, e ele chega para falar que isso não importa.

Mas o que eu me referia ali, ele não se arrepende do termo não, o e-mail que eu cito é o e-mail onde ele está sendo perguntado qual a definição dele de OO no estilo que as pessoas fazem com os 4 pilares (ai ele fala que é retenção local do processo de dados, troca de mensagens, e late-binding extremo de todas as coisas), ai ele começa a explicar o que as pessoas entenderam errado na ideia dele, e ele comenta que um dos pontos que o pessoal não entende direito é o polimorfismo, pois não foi ele que cunhou o termo, não era isso que ele queria dizer, e nem faz muito sentido pensar nisso quando você não tem funções. Aqui a citação:

My math background made me realize that each object could have several algebras associated with it, and there could be families of these, and that these would be very very useful. The term "polymorphism" was imposed much later (I think by Peter Wegner) and it isn't quite valid, since it really comes from the nomenclature of functions, and I wanted quite a bit more than functions. I made up a term "genericity" for dealing with generic behaviors in a quasi-algebraic form.

Dá para ver ele cita isso numa fase onde ele ainda estava chegando as conclusões que troca de mensagens era simplesmente um mecanismo diferente, ele até admite isso uns parágrafos antes.

Então não era uma questão de apego ou orgulho, é só que o cara perguntou para ele qual era a definição dele, e ele aproveitou para clarificar a situação toda já que ele estava sendo associado com ideias que não eram as dele, e não tinham nada a ver com as ideias dele de qualquer forma.

Simula deu origem ao sistema de objetos que usamos hoje em dia, mas não a POO.
Precisaria de clarificação aqui, mas acho que não. Talvez se considerar que os mecanismos não eram tão óbvios quanto em C++ e as linguagens que se inspiraram nela.

Sim e não, tem um ótimo texto que investiga a historiografia dos termos, e aconteceu de muita gente usar o mesmo termo para coisas totalmente diferentes ao mesmo tempo, e acabar todo mundo sendo colocado no mesmo saco já que o movimento geral não entendia a fundo as ideias de qualquer forma, achou tudo parecido, e deixou a gente nessa confusão toda. Aqui o link:https://www.hillelwayne.com/post/alan-kay/

Teve uma atualização nesse texto que diz que talvez o Kay não tenha cunhado o termo, mas eu diria que isso não invalida a questão, pois meu argumento não é só que ele foi o primeiro a usar o termo, e sim que ele foi o primeiro a usar o termo para descrever um paradigma (mesmo que bem acidentalmente, já que a própria história do Smalltalk mostra que não era exatamente disso que eles estavam atrás), já que por essa métrica, Simula também não chegou a inventar objetos, o termo já vinha sendo usado bem antes, inclusive só se chamou assim pois eles emprestaram o termo do paper do Hoare.

Conforme já falamos disso e falo mais nos links do meu outro comentário. As pessoas sequer entendem o que é um paradigma, e a Wikipedia faz o desserviço de ensinar errado.

É uma lástima mesmo que as pessoas não se aprofundem nisso, ironicamente, o cara que cunhou o termo também não sabia o que era um paradigma kkkkkkk. Eu gosto muito desse artigo que explica essa história: https://www.arxiv.org/pdf/2505.01901

A minha posição é algo entre a abordagem taxonômica original, que é mais ou menos como a gente entende paradigmas de programação no senso comum, e a abordagem mais formal do Peter Van Roy, eu gosto principalmente da ideia de que existem elementos anteriores ao conceito de paradigma, e conseguimos entender eles avaliando como eles se diferenciam nesses critérios, apesar disso, eu rejeito a direção que o campo tomou depois de formalismo extremo, e parece até que a própria academia tem balançado entre achar um meio termo das duas abordagens, pelo menos era assim até a última vez que eu estudei sobre o tema a fundo.

É daí que sai a noção de que OO é programar representando o mundo real pois a gente teve uma mudança de paradigma em como nos aproximamos do problema e modelamos sistemas.
Que é uma das maiores imbecilidades já ditas na computação. Mas atendia ao interesse do biólogo que criou isto.

Não foi o Kay que criou essa noção, isso na verdade era o interesse dos criadores de Simula, tanto que ela tem esse nome justamente pois eles queriam uma DSL que permitissem eles criar simulações do mundo real para poder simular transito numa cidade e coisas do tipo.

O Alan Kay fez a analogia com a biologia, mas ele tava interessado num modelo de computação inspirado em agentes autonomos que respondem a estimulos, e não representar o mundo real, tanto que a outra metade do que ele tinha em mente era o background matemático dele, que levava ele a buscar como algebra seria aplicada aqui.

Vamos combinar que Smalltalk é um completo fracasso porque as pessoas não querem pensar assim e Simula não teve nenhuma proeminência por questões mercadológicas (timing e ação).

Eu não chamaria Smalltalk de completo fracasso, quando ele nasceu ele até que foi bem popular, tanto que várias das coisas que persistem na cultura da programação até hoje (pro bem e pro mal) nasceram ali como o MVC, o movimento ágil, os design patterns (o livro era baseado em C++, mas ele também teve influencia do Smalltalk, tendo até um parágrafo dedicado a ele para falar de MVC), etc.

Eu também acho que essa percepção mudou, afinal é isso que vários devs back-end fazem o dia todo desde que microsserviços e arquiteturas orientadas a eventos viraram hype. A gente só usa termos diferentes, mas a visão que o Kay tinha em mente para um modelo de programação se materializou hoje com sistemas distribuídos.

Mas no campo de linguagens de programação, a comunidade Ruby é bem expressiva até para dizer que não existem pessoas que não gostam de pensar assim.

Fora isso, o conceito de state machines ficou relativamente popular no front-end, e enquanto tem diferenças significativas nas ideias, certamente elas não são a mesma coisa, também existem várias semelhanças, e isso aponta que as pessoas não rejeitam isso ineerentemente, é mais falta de marketing mesmo. Se virar hype você faz as pessoas gostarem de qualquer coisa, o Tailwind tá ai para provar isso.

Eu não tenho muito interesse em falar sobre Smalltalk ou OOP do Alan Kay, sobre troca de mensagens, porque eu não vejo tanto valor conceitual assim e não tem uso disseminado no mercado (que eu até ignoraria se fosse algo muito bom). O mesmo vale para Simula, eu nunca a usei, só serviu para entender melhor onde estamos.

Eu fui atrás pois eu tenho interesse na parte intelectual da coisa. Eu sinceramente não me importo muito se é útil ou não, ou se é usado no mercado ou não, o que me moveu a fazer essa pesquisa foi que eu tinha muita curiosidade sobre a resposta do que seria OO, e como não tinha uma resposta única (inclusive um dos meus pontos de partida anos atrás foi a sua resposta no Stack Overflow), fui atrás de pesquisar a história do termo, opiniões online, e qualquer coisa mesmo que me ajudasse a chegar mais perto da resposta.

Talvez porque eu comecei com PHP onde não se tem primitivos na forma de objetos, Smalltalk me pareceu super interessante logo de cara, pois a ideia de que você não precisa de um for, você pode representar isso puramente com uma mensagem timesRepeat de um objeto Int, foi mind blowing, só isso já valeu ter ido atrás do tema, mudou minha perspectiva sobre como modelar boas APIs dos meus módulos, já que elas deveriam corresponder ao que você consegue derivar dos dados que mantém aquele conjunto coeso.

Outra coisa que me interessou logo de cara foi ver como você poderia modelar um if sem uma estrutura de controle de fluxo, e sem usar high order functions (que é aquele boolean encoding clássico do lambda calculus), eu achei bem interessante como você consegue atingir isso usando simplesmente herança como um isomorfismo pra union types.

Eu também tinha um interesse por entender a cabeça de quem fazia o design das APIs da linguagem para ver como ele ia pensar em usar os princípios basilares na prática.

E também tinha interesse em entender como pensavam os programadores da época, então eu li o livro Smalltalk by Example (que me fez criar um interesse tremendo sobre como Tell Don't Ask é muito mais do que só um conselho legal, se você leva ele as últimas consequências, ele vira mais algo como o "evite efeitos colaterais" da FP).

Atualmente eu to lendo o livro de design patterns do Kent Beck que é sobre patterns do Smalltalk em si, e não o clássico do GoF (acho que esse livro veio até antes).

Eu realmente tinha interesse em descobrir se troca de mensagens era só um nome legal para duck typing igual alguns Rubystas argumentam (o que tornaria ele tão não um paradigma quanto a tradição de Simula), ou se tinha um valor real na prática como um modelo distinto de computação.

E, bom, acontece que tem sim, e muito.

Toda a discussão que você tem na galera de microsserviços sobre usar orquestração ou coreografia, essencialmente é sobre desenhar algo com a mentalidade procedural, ou com a mentalidade orientada a objetos.

No campo prático, o paper das HOMs (aqui o link para essa jóia: https://dl.acm.org/doi/10.1145/1146841.1146844) elucida muitas das inovações que a gente poderia ter em APIs mais expressivas em linguagens de programação se elas fossem uma realidade.

Como eu disse Promises transparentes também me parecem ser algo muito útil na prática, visto que isso eliminaria a necessidade de async/await nas linguagens.

Em Smalltalk isso era bem lento, mas existem trabalhos posteriores que mostram que isso poderia ser feito de forma performática se as linguagens tivessem first-class support para isso.

E mesmo pro nível mais mainstream, eu diria que se aprofundar em como estruturar um programa em torno do TDA pode ser um ótimo exercício e que pode ser aplicado até em algumas linguagens mainstream com sistema de tipos estrutural.

A leitura do livro Pratical Object Oriented Design in Ruby da Sandi Metz é bem didático nesse sentido.

Eu não diria que o TDA sozinho seria a coisa mais pura do mundo, e boa parte dos conselhos do livro só é possível em sistemas de tipos estruturais (de preferencia sem tipagem estática), mas não é impossível aplicar aquilo em linguagens estáticas se você tiver um type system com inferencia agressiva como é o da linguagem Crystal.

Eu diria que boa parte das linguagens se beneficiaria simplesmente de copiar o type system do Crystal mesmo sem se importar com toda essa bagagem da OO raíz do Alan Kay.

Então, pelo menos para mim, OO é algo que poderia ser bem relevante é só que infelizmente a tradição não prosperou muito então pouca gente conhece o verdadeiro potencial que essas ideias tinham.

Mas quanto mais eu leio, mais a frente de seu tempo eu vejo que elas eram.

1
lucianoseibel

É apenas uma questão de preferência muitas vezes mas em diversas necessidades a OO apenas cria overengeniring, por exemplo firmware de dispositivos. Outro exemplo software se altíssima performance e baixíssima latência de resposta ou mesmo de boa performance em hardware escasso. Nestes caso linguagens simples, paradigmas simples são sinônimo de codigo e programas performaticos.