Existe uma teoria / abstração por trás do POO?

13

A programação funcional tem o muito elegante Lambda Calculus e suas variantes como uma teoria de backup. Existe algo assim para OOP? O que é uma abstração para o modelo orientado a objetos?

Viclib
fonte
5
Cargas e cargas. Você já experimentou o Google? Por exemplo, há uma série de oficinas chamada FOOL, dedicada às Fundações de Linguagens Orientadas a Objetos, em funcionamento desde 1993. Isso apenas arranha a superfície.
Dave Clarke
@DaveClarke. Eu não concordo completamente. O cálculo Lambda é uma base para a programação funcional em um sentido muito preciso. Por exemplo, o relatório Haskell diz que toda a linguagem Haskell pode ser considerada apenas um açúcar sintático para uma linguagem principal que é equivalente ao cálculo lambda digitado. Não conheço nenhuma linguagem orientada a objetos que faça uma afirmação semelhante em relação a um cálculo. Então, você está certo que há "cargas". Mas nada disso está certo.
Uday Reddy
@UdayReddy: Talvez isso se deva à riqueza da linguagem orientada a objetos.
58514 Dave Clarke
1
@DaveClarke A riqueza de um tópico pode significar que (1) é uma boa palavra da moda, (2) realmente não entendemos o assunto o suficiente para a construção de um consenso, (3) estamos misturando várias questões que são praticamente ortogonais . Embora eu não tenha seguido de perto a literatura (recente) sobre programação OO, sempre tive a sensação de que estava misturando questões sem ser muito explícito a respeito (é claro que isso se aplica mais às línguas do que ao trabalho teórico). Esses problemas incluem digitação, abstração, estado, paralelismo, reutilização de código. É improvável que uma (uma) teoria seja responsável por todas as variantes.
babou 16/03/2015

Respostas:

15

Existem quatro abordagens principais, embora elas apenas arranhem a superfície do que está disponível:

  • via lambdas e registros: a idéia é codificar objetos, classes e métodos em termos de construções mais tradicionais. O trabalho de Benjamin Pierce, em meados dos anos 90, é representativo dessa abordagem.
  • Cálculo de objetos de Abadi e Cardelli (consulte o livro A Teoria dos objetos de Abadi e Cardelli : sua principal abstração é um registro de métodos, e a abordagem está mais próxima da realização baseada em protótipo da programação orientada a objetos, embora classes e herança possam ser codificadas em termos dos elementos mais primitivos.
  • Cálculo multimétodo de Castagna (consulte o livro de Castagna Programação Orientada a Objetos - Uma Fundação Unificada ): sua abordagem leva os multimétodos a principal abstração.
  • Cálculos baseados em classes (como no livro de Kim Bruce, Foundations of Object-oriented Languages: Types and Semantics ou Featherweight Java ): essas abordagens visam capturar a essência da programação baseada em classes e focar em classes e herança.
Dave Clarke
fonte
12

A conexão entre o núcleo do modelo de objeto e a teoria dos conjuntos é descrita nos seguintes documentos:

Os documentos apresentam a estrutura das relações de instância e herança entre objetos. Essa estrutura pode ser considerada a mais alta abstração possível de OOP. É mostrado como a estrutura se aplica a linguagens de programação específicas (Ruby, Python, Java, Scala, Smalltalk-80, Objective-C, CLOS, Perl, Dylan, JavaScript) e também a linguagens de ontologia (RDF Schema e OWL 2 Full).

Nos documentos, as classes são objetos, a abordagem é adotada para que a estrutura principal seja classificada de maneira única. Na forma principal, a estrutura pode ser expressa como (O, ϵ , ≤, .ec) em que

  • O é o conjunto de objetos ,
  • ϵ é a relação de associação (objeto) , um refinamento da instância de relação,
  • ≤ é a relação de herança e
  • .ec é o mapa da classe de potência que é uma sub -relação distinta, possivelmente vazia, de ϵ.

Uma estrutura de núcleo de amostra de acordo com o modelo de objeto Ruby é mostrada no diagrama a seguir. Os links verdes mostram a relação de herança na redução transitiva reflexiva, os links azuis mostram a relação de associação na "redução de subsunção" - um link azul de x aponta para o menor contêiner de x . O mapa da classe power .ec é formado por links azuis horizontais. Os objetos da imagem deste mapa são classes de força (em cinza). Em Ruby, eles são chamados classes próprias ou também classes singleton (o último termo é bastante obsoleto). Os objetos s , u e v (em rosa) são terminais, os objetos restantes são descendentes da raiz da herança r .

  r = BasicObject; c = Class; A = c.new(r); B = c.new(A); s = A.new; u = B.new; v = B.new; class << s; end; class << v; end

As partes principais do modelo de objeto de todas as linguagens acima podem ser vistas como especializações da estrutura, com nenhum ou apenas alguns constituintes adicionais. Do ponto de vista teórico, o caso mais significativo de um constituinte adicional é o mapa de singleton (denotado .ɛϲ ) introduzido por Dylan. Isso faz de Dylan a única linguagem de programação (acima mencionada) que não está sujeita à condição de monotonicidade (≤) ○ (ϵ) ⊆ (ϵ) onde o símbolo de composição ○ é interpretado da esquerda para a direita.

Uma maneira de formalizar a conexão entre o núcleo do modelo de objeto e a teoria dos conjuntos é através da família de estruturas (O, ≤, r, .ec, .ɛϲ) denominadas estruturas de metaobjetos nos documentos referenciados, pois x.ec ou x.ɛϲ podem ser considerados como meta-objetos de x . Nessas estruturas, x.ec é definido para todo objeto x e x.ɛϲ é definido para todo objeto limitado ("pequeno") x . As estruturas estão sujeitas aos nove axiomas abaixo. A axiomatização utiliza uma extensão de definição bastante simples para os oito primeiros axiomas ( Tdenota o conjunto de objetos terminais - aqueles que não são descendentes de r , e .ec é o fechamento transitivo reflexivo de .ec ), mas envolvido pelo último axioma.

  1. A herança, , é uma ordem parcial.
  2. O mapa da classe de potência, .ec , é uma incorporação de ordem de (O, ≤) em si mesmo.
  3. Os objetos de T.ec são mínimos.
  4. Toda classe de poder é descendente de r .
  5. O conjunto r.ec não tem limite inferior.
  6. O mapa singleton, .ɛϲ , é injetivo.
  7. Os objetos de O.ɛϲ.ec são mínimos.
  8. Para todos os objetos x , y , de modo que x.ɛϲ é definido, x.ɛϲ ≤ y.ec ↔ x ≤ y .
  9. Para cada objeto x , x.ɛϲ é definido como xd <ϖ .

No último axioma, ϖ é um ordinal de limite fixo e .d é a função de classificação derivada pela extensão de definição. A relação de associação ao objeto, ϵ, é obtida como (( .ɛϲ ) ∪ ( .ec )) ○ (≤). De acordo com o último axioma, a restrição de domínio de ϵ para o conjunto de objetos delimitados é igual a ( .ɛϲ ) ○ (≤). Nos documentos referenciados, essa relação é chamada associação limitada e denotada ∊. Como característica significativa, essa relação é bem fundamentada. Isso contrasta com ϵ que ​​não é fundamentado desde que r ϵ r. Acontece que a principal correspondência entre (a parte principal) da tecnologia de objetos e a teoria dos conjuntos pode ser expressa como

∊ ↔ ∈

ou seja, associação limitada corresponde à associação de conjuntos entre conjuntos bem fundamentados. Como um caso especial, o universo parcial de von Neumann da classificação ϖ + 1 é uma estrutura de metaobjeto por extensão de definição. Em geral, toda superestrutura ( ϖ + 1 ) - (O,) é definitivamente equivalente a uma estrutura completa de metaobjetos. Toda estrutura de metaobjeto pode ser fielmente incorporada a uma estrutura completa de metaobjeto que, por sua vez, pode ser fielmente incorporada ao universo de von Neumann.

O termo estrutura básica é usado para uma generalização de estruturas de metaobjetos. Nesta generalização, .ec e .ɛϲ podem ser (arbitrariamente) parciais, possivelmente vazios. Em particular, estruturas básicas finitas são possíveis, com a estrutura mínima contendo apenas a raiz da herança r . Toda estrutura básica pode ser estendida a uma estrutura de metaobjeto por uma conclusão de classe de poder seguida por uma conclusão de singleton que, por sua vez, torna estruturas básicas fielmente incorporáveis ​​ao universo de von Neumann.

paon
fonte
@ Rafael Muito melhor - obrigado, Paon!
David Richerby