Por que muitas linguagens de programação dinâmica tipadas por pato usariam uma abordagem baseada em classe em vez de OOP baseado em protótipo?

23

Como muitas linguagens de programação dinâmicas têm o recurso de digitação de pato , elas também podem abrir e modificar métodos de classe ou instância a qualquer momento (como Ruby e Python ), então…

Pergunta 1) Qual é a necessidade de uma aula em um idioma dinâmico? Por que a linguagem é projetada dessa maneira para usar uma classe como algum tipo de "modelo", em vez de usar o protótipo e apenas usar um objeto?

Além disso, o JavaScript é baseado em protótipos, mas o CoffeeScript (a versão aprimorada do JavaScript) escolhe a maneira baseada em classe. E é o mesmo para Lua (baseado em protótipo) e MoonScript (baseado em classe). Além disso, há aula no ES 6. Então…

Pergunta 2) Está sugerindo que, se você tentar melhorar uma linguagem baseada em protótipo, entre outras coisas, deve alterá-la para baseada em classe? Caso contrário, por que é projetado dessa maneira?

— iceX
fonte

9

Muitos programadores não querem se incomodar em aprender algo novo. (É muito estranho e "difícil"). Daí todas as bibliotecas e linguagens baseadas em classe que são compiladas a elas.

— Thomas Eding

1

Eu concordo com Thomas, mas o engraçado é que, depois de aprender a abordagem dinâmica, é realmente mais fácil (não mais difícil). O conceito de objetos ainda está lá, é justo que os objetos possam ser alterados sem recompilar primeiro um "plano" estúpido. Se eu quiser colocar uma quinta perna em uma cadeira, não quero alterar um plano primeiro, só quero adicionar a perna. Linguagens dinâmicas modelam mais de perto a realidade na minha opinião.

— Lonnie Best

1

OOP foi inventado em um contexto estaticamente tipado, onde os tipos precisam ser declarados. Lá, as aulas são um passo sensato a partir dos registros e módulos. OOP baseado em protótipo foi apenas um tópico de pesquisa interessante para a linguagem Self e, de alguma forma, transformou-o em JavaScript como a maneira mais simples de marcar a palavra de efeito "OOP" para uma linguagem essencialmente funcional. O bom é que você pode implementar classes sobre os protótipos. Embora eu goste de metaobjetos, separar classes de suas instâncias facilita a escrita de códigos bem fatorados, simples e pouco acoplados.

— amon

3

Primeira coisa: o próprio JavaScript suporta a classpalavra - chave a partir do próximo padrão ECMAScript (ECMAScript 6). O suporte para aulas em JavaScript foi planejado por um longo tempo. Agora, o que é - as classes são apenas açúcar sintático, mais fácil de raciocinar sobre o modelo de objetos do mesmo tipo. É assim em JS e é assim em Python e outras linguagens dinâmicas.

— Benjamin Gruenbaum

1

@BenjaminGruenbaum "... as aulas são apenas açúcar sintático ..." uau, essa é uma idéia bastante nova para mim, realmente, para linguagens como ruby e python, parece que não importa se deve usar um objeto ou classe como modelo - ambos podem ser modificados rapidamente, de qualquer maneira. E realmente não importa como eles lidam com a herança também. Então, talvez não há nenhuma necessidade de distinguir entre a abordagem baseada em classes e abordagem baseada em protótipo para uma linguagem dinâmica :)

— ICEX

12

Pergunta 1) Qual é a necessidade de uma classe em um idioma dinâmico? Por que a linguagem é projetada dessa maneira para usar uma classe como algum tipo de "modelo", em vez de fazer o protótipo e apenas usar um objeto?

A primeira linguagem OO (embora não fosse chamada "OO"), Simula, não tinha herança. A herança foi adicionada no Simula-67, e foi baseada em classes.

Na mesma época, Alan Kay começou a trabalhar em sua idéia de um novo paradigma de programação, que mais tarde chamou de "Orientação a Objetos". Ele realmente gostava de herança e queria tê-la em seu idioma, mas também não gostava de classes. No entanto, ele não conseguiu encontrar uma maneira de ter herança sem classes, então decidiu que não gostava mais de classes do que gostava de herança e projetou a primeira versão do Smalltalk, Smalltalk-72 sem classes e, portanto, sem herança.

Alguns meses depois, Dan Ingalls apresentou um design de classes, onde as próprias classes eram objetos, ou seja, instâncias de metaclasses. Alan Kay achou esse design um pouco menos assustador do que os anteriores, então o Smalltalk-74 foi projetado com classes e com herança baseada em classes.

Depois do Smalltalk-74, Alan Kay sentiu que o Smalltalk estava se movendo na direção errada e não representava realmente o que era o OO, e ele propôs que a equipe abandonasse o Smalltalk e começasse do zero, mas ele foi derrotado. Assim, seguimos o Smalltalk-76, o Smalltalk-80 (a primeira versão do Smalltalk a ser lançada aos pesquisadores) e, finalmente, o Smalltalk-80 V2.0 (a primeira versão a ser lançada comercialmente e a versão que se tornou a base do ANSI Smalltalk) .

Como o Simula-67 e o Smalltalk-80 são considerados os avós de todos os idiomas OO, quase todos os idiomas que se seguiram copiaram cegamente o design de classes e herança com base em classes. Alguns anos depois, quando surgiram outras idéias como herança baseada em mixins em vez de classes e delegação baseada em objetos em vez de herança baseada em classes, a herança baseada em classe já havia se tornado muito arraigada.

Curiosamente, o idioma atual de Alan Kay é baseado na delegação de protótipos.

— Jörg W Mittag
fonte

"... o idioma atual de Alan Kay ..." que é ...?

— Javier

@Javier: Eu não acho que tenha um nome, e o nome do sistema continua mudando.

— Jörg W Mittag 01/02

Esta deve ser uma boa resposta para apontar para próxima vez que alguém listas herança como um requisito para OO :)

— Hey

1

@iceX: Alan Kay fundou o Viewpoints Research Institute para trabalhar em suas idéias. Infelizmente, as informações estão realmente espalhadas no site.

— Jörg W Mittag 02/02

3

Citação de Alan Kay no OO: "OOP para mim significa apenas mensagens, retenção e proteção local e ocultação de processos estatais e vinculação tardia extrema de todas as coisas. Isso pode ser feito no Smalltalk e no LISP. Existem outros sistemas em o que é possível, mas não estou ciente deles. "

— Joeri Sebrechts 02/02

23

Muitos programadores preferem trabalhar com aulas. É um conceito muito fácil de entender que é um bom modelo de processos de pensamento humano sobre o mundo (ou seja, instintivamente relacionamos objetos reais ao grupo abstrato de itens que consideramos pertencer, que é o que é uma classe) . Além disso, as classes facilitam o raciocínio sobre tipos de objetos: em uma linguagem baseada em classes, aplicar princípios como a substituição de Liskov é mais simples do que em uma linguagem em que apenas temos objetos que podem ter métodos diferentes ou cujo tipo pode até mudar em tempo de execução , como é o caso do JavaScript.

Observe que, mesmo em JavaScript, uma enorme quantidade de código simplesmente usa o recurso de protótipo para emular classes. Isso ocorre principalmente porque muitos programadores preferem pensar dessa maneira.

Há também outro motivo pelo qual as linguagens baseadas em classe são preferidas: é mais fácil compilá-las para um código eficiente. As VMs JavaScript mais eficientes criam dinamicamente classes para representar os tipos de objetos JavaScript à medida que seus métodos e protótipos mudam. Veja esta descrição da implementação da V8 para uma justificativa sobre por que isso é feito.

— Jules
fonte

4

Seu último parágrafo, na verdade, suporta exatamente o oposto do que você está dizendo: A V8 prova que você não precisa de classes no idioma para compilar um código baseado em classe eficiente.

— Jörg W Mittag 01/02

4

Sim, você não precisa deles - mas o fato de o V8 (e provavelmente o Self, embora eu não tenha lido muito sobre o design desse sistema) criar classes virtuais efetivamente significa que, a partir de uma linguagem que usa classes nativamente, é quase certamente mais fácil e, portanto, provavelmente acabaria com o JIT precisando gastar menos tempo compilando o código.

— Jules

11

Claro, e o fato de o V8 criar efetivamente se GOTOregistra significa que apenas desistir de todas as abstrações e escrever diretamente na montagem é quase certamente mais fácil e, portanto, provavelmente acabaria com o JIT precisando gastar menos tempo compilando o código. O trabalho de um compilador é oferecer suporte a abstrações de nível superior.

— Jörg W Mittag 01/02

1

Sim, mas é uma troca, já que a abstração de nível superior é na maioria dos casos mais difícil de implementar e geralmente tem uma penalidade no desempenho em tempo de execução, especialmente ao trabalhar com um JIT em vez de um compilador AOT. Suspeito que muitos designers de linguagem escolham uma estrutura baseada em classe por um ou ambos os motivos; Eu sei que é por isso que escolhi classes com membros fixos para o idioma (de outra forma dinâmico) em que estou trabalhando, mas só posso especular sobre outros idiomas.

— Jules

1

Eu diria que a única maneira que os programadores preferem "pensar nas aulas" é porque é assim que a maioria de nós é ensinada. Definitivamente, consigo me lembrar de muitos dos meus colegas de faculdade que tiveram problemas para compreender e entender alguns conceitos realmente orientados a objetos realmente fundamentais por vários anos. Parece apenas óbvio e fácil em retrospectiva.

— KChaloux

3

Ouvi dizer que em grandes projetos, onde equipes de pessoas trabalham juntas no mesmo código, linguagens flexíveis (onde você pode modificar as propriedades e os métodos de um objeto durante o tempo de execução) são liberdades que outros membros da equipe não querem. Ter.

Eles querem saber, quando estão lidando com um objeto, que o objeto agirá exatamente como o modelo diz, e não de alguma maneira que algum outro desenvolvedor ambicioso decidiu alterá-lo para concluir sua própria tarefa.

Portanto, a única razão pela qual posso conceber que alguém não gostaria das flexibilidades oferecidas por essas linguagens dinâmicas impressionantes é que eles querem simplificar o desenvolvimento da equipe, a depuração e a documentação automática.

Pessoalmente, desenvolvi aplicativos nas duas metodologias e concluo as coisas com mais rapidez com linguagens dinâmicas. Não uso nenhuma dessas estruturas projetadas para transformar minha linguagem dinâmica novamente em uma linguagem baseada em classe novamente. Tais coisas são uma regressão aos meus gostos.

— Lonnie Best
fonte

1

OOP para mim significa apenas mensagens, retenção e proteção local e ocultação de processos estatais e vinculação tardia extrema de todas as coisas - Alan Kay

Então, o que ele está dizendo aqui é que OO tem tudo a ver com fazer caixas pretas que respondem às mensagens. De certa forma, o REST é o sistema OO definitivo, na medida em que usa verbos (por exemplo, uma mensagem) e recursos (por exemplo, uma caixa opaca que contém alguns dados).

Portanto, a questão de por que alguns são baseados em classes e outros baseados em protótipos perdem o ponto de que realmente não importa, são meras implementações. Um sistema que usa apenas mensagens em vez de chamadas de método é tão OO quanto as duas instâncias mencionadas.

— gbjbaanb
fonte