¿En qué formalismo matemático se basa la programación orientada a objetos (OOP)? ¿Se desarrolló algún formalismo después de que la POO se generalizó?

La programación orientada a objetos no se basa en conocimientos matemáticos, sino en las ideas del lenguaje de programación Simula desarrollado en la década de 1960 en el Centro Noruego de Computación por Ole-Johan Dahl y Kristen Nygaard. La intención detrás de Simula era (como su nombre lo indica) crear un lenguaje de programación que permitiera describir la solución a un problema mediante un “modelo físico” (aunque no en el sentido de la física). No había un modelo matemático subyacente de Simula (a pesar de que Dahl y Nygaard eran matemáticos); Esto probablemente también se deba al hecho de que la semántica del lenguaje de programación todavía estaba en sus primeras etapas en ese momento.

Ha habido mucho trabajo tratando de proporcionar lenguajes de programación orientados a objetos con una buena base matemática. Martín Abadi y Luca Cardelli hicieron un intento muy ambicioso en la década de 1990 y lo describieron en una serie de documentos que más tarde se convirtieron en el libro A Theory of Objects. La idea es idear una familia de cálculos de objetos cada vez más expresivos que estén equipados con sistemas de tipos cada vez más expresivos. Cada cálculo de objeto tiene entre sus pocas primitivas sintácticas la capacidad de definir objetos como una colección de métodos (los campos se ven como un caso particular), la capacidad de modificar y extender objetos y, por supuesto, también la capacidad de llamar a los métodos de un objeto.

Bueno, la respuesta sería que la Programación Orientada a Objetos no es realmente un paradigma de programación independiente.

Hay tres tipos principales de paradigmas de programación, a saber:

1. Programación imperativa (Java, C, etc.)
2. Programación funcional (Scala, Lisp, etc.)
3. Programación lógica (Mercury, Prolog, etc.)

La programación orientada a objetos se puede combinar con la programación imperativa (eso es lo que está sucediendo en el escenario actual) pero también se puede combinar con la programación funcional (¡Scala ofrece esto!) O lógica.

Al igual que todos los lenguajes imperativos, puede analizar lenguajes OO con cálculo de predicados: antes de cada enunciado se mantiene un predicado (que describe el estado de todas las variables), después de cada enunciado se mantiene otro predicado, y existen reglas precisas sobre cómo la declaración transforma un predicado en otro. (Este tipo de análisis no es muy popular, pero es una mierda decir que no existe una teoría matemática que rija los lenguajes imperativos).

Pero eso vale para cualquier lenguaje imperativo. La programación orientada a objetos se puede modelar con el modelo de actor: cada objeto es un programa independiente con el comportamiento de estado descrito anteriormente, que cambia su estado dependiendo de los mensajes recibidos de otros actores (objetos).

Para las personas que realmente están metidas en la teoría, aquí hay un buen enlace:
Una teoría de los objetos (monografías en informática): Martin Abadi, Luca Cardelli: 9780387947754: Amazon.com: Libros
También: una semántica denotativa de la herencia

La programación orientada a objetos se originó en lenguajes imperativos, y los lenguajes imperativos en su conjunto no tienen formalismos matemáticos bien entendidos que los describan.

En los últimos años, han aparecido lenguajes como Ocaml y Scala que son más funcionales y, por lo tanto, pueden formalizarse al menos parcialmente, que tienen características OO. Debido a esto, se han desarrollado formalismos que capturan al menos aspectos de OO. Hay toda una industria artesanal de papeles que dan semántica operativa o denotacional a los lenguajes OO de juguete. Martin Odersky, el inventor de Scala, ha publicado uno sobre un esquema de tipos de objetos dependientes (DOT) que captura la parte OO del sistema de tipos de Scala.

Como regla general, el subtipo, que por supuesto es esencial para OO, es un poco difícil de integrar en cualquier sistema formal.

OOP no se basó en un principio / concepto matemático como la inspiración inicial para bases de datos relacionales o lenguajes especializados como Lisp o Prolog. Le sugiero que lea la siguiente publicación de blog de 2 partes que analiza la POO desde el punto de vista de la teoría de conjuntos y los defectos obvios que resultan:
http://lukepalmer.wordpress.com/

Como se menciona en el artículo, puede pensar en una clase como un conjunto de todas las instancias posibles de esa clase. Supongo que eso hace que la herencia múltiple sea la intersección de 2 clases. Estoy de acuerdo en que los árboles de herencia largos están lejos de ser escalables y también tienen problemas reales de rendimiento. En la programación de juegos es bastante común ahora construir entidades de juego a partir de componentes para evitar problemas de herencia (solo como un ejemplo de que causa problemas en el mundo real)
http://cowboyprogramming.com/200

OO realmente puede ayudar al desarrollo de las personas, tiene algunas herramientas de desarrollo útiles como interfaces y creo que refleja la forma en que las personas ven el mundo, aunque quizás haya un mejor método basado en conjuntos que también pueda aprovechar las matemáticas establecidas.

En la década de 1980, mientras OOP estaba en su infancia industrial, en un trabajo seminal, Luca Cardelli construyó un modelo matemático de OOP de denotación (también conocido como dominio teórico). En la década de 1990, junto con Abadi, Cardelli construyó un modelo operativo de OOP. Los modelos de Cardelli eran estructurales, veían los objetos como simples registros e ignoraban la información crucial de los nombres de clase y, en consecuencia, ignoraban el papel que desempeña la nominalidad de la relación de herencia de tipo OO en la decisión de la relación de subtipo OO. Como se indicó claramente en su investigación, la visión estructural de Cardelli y Abadi de la POO estuvo fuertemente influenciada por la investigación sobre programación funcional, que era dominante entre los investigadores en ese momento. Sin embargo, en su trabajo, Cardelli aconsejó investigar la escritura nominal en idiomas OO.

En 2011, mientras trabajaba con el Prof. Robert Cartwright (Rice University), desarrollé el trabajo seminal de Cardelli para construir NOOP como un modelo teórico de dominio más preciso de los principales lenguajes OO de tipo nominal como Java, C #, C ++ y Scala. (En 2014 se publicó un resumen conciso de la construcción de NOOP).

Aquellos interesados ​​en más formalismos matemáticos para modelar OOP deben verificar los siguientes resultados de búsqueda personal de arXiv, que incluyen mi trabajo hasta ahora sobre el modelado de genéricos OO y sobre la aplicación de la teoría de categorías en el modelado de OOP.

La respuesta a la primera pregunta es NINGUNA , en el sentido de que no hay formalismo que haya impulsado el desarrollo de OOP. Solo hay formalismos ex post que están destinados (o simplemente proclamados) a estar relacionados con la POO. La mayoría de estos formalismos intentan imitar el éxito del cálculo lambda como base de la programación funcional (FP). La idea es ajustar el cálculo lambda para que el sistema resultante contenga características orientadas a objetos. Es decir, comience con FP y luego reemplace ‘F’ con ‘OO’ para que se establezca OOP. (Alternativamente, comience con P y agregue OO delante de P.) Como resultado, OOP se ve más o menos como una subramificación de FP (ajustada).

La otra forma: comenzar con OO y agregar P posteriormente (o comenzar con OOAD y luego reemplazar ‘AD’ por ‘P’) es mucho menos compatible. Esta falta de soporte contrasta un poco con el lema del objeto introducido por Bertrand Meyer: no preguntes primero qué hace el sistema: ¡pregunta qué hace! . Ver ¿Qué es una metaclase? para un enfoque sin cálculo de las bases OOP (también disponible en PDF).

OO fue desarrollado desde una perspectiva de ciencia cognitiva. Las primeras ideas se pueden ver, por ejemplo, en la escritura de Lakoff ( http://polaris.gseis.ucla.edu/gl …) y no se diseñó desde una perspectiva matemática.

En los últimos años, se han desarrollado lógicas descriptivas cuyo objetivo es describir objetos y relaciones entre objetos. En concreto, la semántica de los diagramas de clases UML se ha traducido a lógicas en la familia de las lógicas de descripción. Esta traducción ayuda a encontrar inconsistencias lógicas en los diagramas de clase UML. Ver por ejemplo https://www.inf.unibz.it/~calvan… . He comenzado a escribir sobre esto en las Notas de Henriette que apunta a no ser demasiado matemático.

La investigación está en curso en esta área. Para una investigación que analiza la formalización de los aspectos dinámicos de OO, consulte por ejemplo http://www.inf.unibz.it/~calvane… .