Definição formal / contraparte em matemática para "objetos" de modelos orientados a objetos

Esta é uma pergunta que fiz no fórum de matemática SE, e fui encaminhada aqui. Então aqui está a questão-

Eu sou um novato em matemática formal e em ciência da computação teórica, então, por favor, tenha paciência comigo se achar que minha pergunta não está devidamente enquadrada. A Modelagem Orientada a Objetos parece muito útil na definição de interações complexas ao simular o mundo real. Mas é usado principalmente em programação. Eu queria saber se temos um conceito semelhante em matemática. Quando estamos fazendo programação, podemos entender o conceito de "Objetos" e "Programação Orientada a Objetos" e apenas implementá-lo. Mas temos uma definição formal de "Objetos" em termos da Teoria dos Conjuntos? Ou, nesse caso, qualquer outra teoria matemática formal?

Podemos implementar / definir formalmente três conceitos principais de modelagem orientada a objetos: 1. Encapsulamento 2. Herança 3. Polimorfismo

Eu sei que a pergunta é muito ampla, mas realmente apreciaria se você também pudesse fornecer alguns indicadores para que eu possa entender melhor esses conceitos.

A resposta é complicada, por duas razões.

1. Pessoas diferentes na Ciência da Computação interpretam o termo "objeto" de maneira diferente. Uma é que um objeto consiste em alguns dados e operações agrupados. A outra é que um objeto é tudo isso, mas também tem "estado", isto é, é alguma forma de uma entidade mutável .

2. Existem questões filosóficas profundas relacionadas ao que "mudança" significa (e o que "entidade" significa, pois muda constantemente), e se as descrições matemáticas realmente capturam entidades alteráveis.

Objeto no sentido de dados + operações : isso é bastante padrão em matemática. Tome qualquer livro de texto de teoria de grupos. Terá em algum lugar uma definição como $h_g(x) = g x g^{-1}$ . (É um operador de conjugação.) O é um "objeto" nesta terminologia. Possui alguns dados ( g ) e uma operação x ↦ g x g - 1 . Ou você pode torná-lo mais objeto-y, tendo o par ⟨ g , x ↦ g x g - $h_g$$g$$x \mapsto g x g^{-1}$ Ou o triplo ⟨ g , x ↦ g x g - 1 , x ↦ g - 1 x g ⟩ . Você pode construir esse tipo de "objetos" em qualquer linguagem de programação funcional que possua abstração lambda e alguma forma de formar tuplas. A "Teoria dos Objetos" de Abadi e Cardelli lida extensivamente com objetos desse tipo.$\langle g, x \mapsto gxg^{-1}\rangle$$\langle g, x \mapsto gxg^{-1}, x \mapsto g^{-1}xg\rangle$

Objetos com estado (ou objetos que mudam ): A matemática tem essas coisas? Acho que não. Eu não vi um matemático falar sobre algo que muda, não em sua vida profissional. Newton costumava escrever para a posição de uma partícula, que supostamente está mudando, e$x$ para a sua taxa de mudança. Os matemáticos, eventualmente, descobriu que o que Newton estava falando era uma funçãox(t)de números reais em um espaço vetorial, e ˙ x foi outro tal função que foi a primeira derivada dex(t)em relação à$\dot{x}$$x(t)$$\dot{x}$$x(t)$$t$. A partir disso, muitos matemáticos de pensamento profundo concluíram que a mudança realmente não existe e tudo que você tem são funções do tempo. Mas o que estava mudando na mecânica newtoniana não era a posição, mas a partícula . A posição é seu estado instantâneo. Nenhum matemático ou físico pretenderia que uma partícula é uma idéia matemática. É uma coisa física.

O mesmo acontece com os objetos. São coisas "físicas" e os estados são seus atributos matemáticos. Para uma boa discussão sobre esse aspecto, consulte o Capítulo 3 da Estrutura e interpretação de programas de computador de Abelson e Sussman . Este é um livro-texto do MIT e eles o ensinam a todos os cientistas e engenheiros, que eu acho que entendem perfeitamente as coisas "físicas".

$x_1(t)$$x_2(t)$

Da mesma forma, a maneira matemática padrão de modelar programas orientados a objetos é tratar cada objeto como um índice no espaço de estados. A única diferença é que, como os objetos vêm e vão, e a estrutura do sistema é dinâmica, precisamos estendê-lo a um modelo de "mundo possível", em que cada mundo é basicamente uma coleção de índices. A alocação e desalocação de objetos envolveria a mudança de um mundo para outro.

Há um problema, porém. Diferentemente da mecânica, queremos que o estado de nossos objetos seja encapsulado . Mas as descrições matemáticas dos objetos colocam estados em todo o lugar, destruindo completamente o encapsulamento. Existe um truque matemático chamado "parametridade relacional" que pode ser usado para reduzir o tamanho das coisas. Não vou entrar nisso agora, exceto para enfatizar que é um truque matemático, não uma explicação muito conceitual do encapsulamento. Uma segunda maneira de modelar objetos matematicamente, com encapsulamento, é aperfeiçoar os estados e descrever o comportamento do objeto em termos de eventos observáveis. Para uma boa discussão de ambos os modelos, posso encaminhá-lo ao meu artigo intitulado Objetos e classes em linguagens semelhantes a Algol .

[Nota adicionada:]

Uma boa análise dos fundamentos matemáticos dos objetos pode ser encontrada no artigo de William Cook " On Understanding Data Abstraction, Revisited ".

acho que há uma boa descrição teórica dos objetos no livro clássico antigo "estrutura e interpretação de programas de computador" [1] de abelson & sussman, com base no esquema (uma variante lisp). agora grátis online! isso mostra como o conceito de orientação a objetos pode ser incorporado até no cálculo lambda (~ aka Lisp) se você tiver algum mecanismo para armazenar o estado local. pelo que entendi, esse foi um livro-padrão do MIT por muitos anos. não dizendo que este é o melhor árbitro do assunto; Tenho certeza que existem outros melhores neste pt.

Eu não acho que isso tenha sido totalmente formalizado em qualquer lugar que eu tenha ouvido falar, mas objetos frouxos são basicamente compostos de código + dados na forma de

• métodos (com parâmetros)
• estado, ou seja, variáveis ​​de instância

de alguma forma encapsulada. indiscutivelmente outros aspectos como herança não são fundamentais. como afirma em abelson & sussman, o que eles chamam de "açúcar sintático".

[1] estrutura e interpretação de programas de computador por abelson & sussman