oop - que - programacion orientada a objetos ejemplos
Teoría detrás de la programación orientada a objetos. (9)
¿Qué pasa con las redes de petri? Objeto puede ser un lugar , una composición y un arco , tokens de mensajes. No lo he pensado muy bien, por lo que podría haber algunas fallas que no conozco, pero se pueden investigar: hay muchos trabajos teóricos relacionados con las redes de Petri.
Encontré esto, por ejemplo:
El cálculo lambda de Alonzo Church es la teoría matemática detrás de los lenguajes funcionales. ¿Tiene la programación orientada a objetos alguna teoría formal?
Abadi y Cardelli han escrito Una teoría de los objetos , es posible que desees ver eso. A otra exposición se le da el venerable TAPL (IIRC, se acercan a los objetos como registros recursivos en un cálculo lambda mecanografiado). Realmente no sé mucho acerca de estas cosas.
En el año 2000 en mi grado me propuse este modelo; muy corto:
y + 1 = f(u, x)
x + 1 = g(u, x)
dónde:
- u: entrada
- y: salida
- x: estado
- f: función de salida
- g: función de estado
Formalmente es muy similar a la máquina de estados finitos , pero la diferencia es que U, Y, S no están definidos, pero infinitos ( numerables ) yf y g son Touring Machine (TM).
f y g togheter forman una clase ; Si agregamos un estado inicial x0 tenemos un objeto . Entonces OOP en algo más que una TM a TM es un caso específico de OOP. Tenga en cuenta que el estado x es de un nivel diferente al estado "dentro" de la TM. Dentro de la TM no hay efectos secundarios, el recuento del estado x para efectos secundarios .
La historia (simplificada) va por ese camino:
Primero vino el código spagetti. Luego vino el código procesal (como C y Pascal). Luego vino el código modular (como en modula). Luego vino el código orientado a objetos (como en smalltalk).
¿Cuál es el motivo de la programación orientada a objetos?
Solo puedes entender si recuerdas la historia.
Al principio, el código era simplemente una secuencia de instrucciones dadas a la computadora (literalmente en representación binaria) Luego vinieron los ensambladores de macros. Con mneomonics para instrucciones. Entonces la gente detectó que a veces tienes un código que se repite alrededor. Así que crearon GOTO. Pero GOTO (o rama o salto, etc.) no puede regresar al lugar donde fue llamado, ni puede dar valores de retorno directo, ni tampoco puede aceptar parámetros formales (tuvo que usar variables globales). Contra el primer problema, las personas crearon subrutinas (similares a GOSUB). Grupos de instrucciones que podrían llamarse repetidamente y regresar a donde se llamó. Luego, las personas detectaron que las rutinas serían más útiles si tuvieran parámetros y pudieran devolver valores. Para ello crearon funciones, procedimientos y convenciones de llamada. Esas abstracciones fueron invocadas sobre una abstracción llamada la pila. La pila permite parámetros formales, valores de retorno y algo llamado recursión (directa o indirecta). Con la pila y la capacidad de llamar a una función de forma arbitraria (incluso indirectamente), vino la programación procesal, que soluciona el problema GOTO. Pero luego vinieron los grandes proyectos y la necesidad de agrupar los procedimientos en entidades lógicas (módulos).
Ahí es donde entenderás por qué evolucionó la programación orientada a objetos.
Cuando tienes un módulo, tienes variables locales del módulo.
Piensa sobre esto :
Module MyScreenModule;
Var X, Y : Integer;
Procedure SetX(value : Integer);
Procedure SetY(value : Integer);
End Module.
Hay variables X e Y que son locales a ese módulo. En ese ejemplo, X e Y mantienen la posición del cursor. Pero supongamos que su computadora tiene más de una pantalla. Entónces que podemos hacer ahora ? Solo X e Y no pueden mantener los valores X e Y de todas las pantallas que tiene. Necesitas una forma de INSTALAR esa información. Ahí es donde el salto de la programación modular va a la programación orientada a objetos.
En un lenguaje no orientado a objetos usualmente harías:
Var Screens : Array of Record X, Y : Integer End;
Y luego pase un valor de índice a cada llamada de módulo:
Procedure SetX(ScreenID : Integer; X : Integer);
Procedure SetY(ScreenID : Integer; Y : Integer);
Aquí screenid se refiere a cuál de las múltiples pantallas de las que está hablando.
Orientado a objetos invierte la relación. En lugar de un módulo con varias instancias de datos (efectivamente, lo que hace Screenid aquí), conviertes a los datos en ciudadanos de primera clase y le adjuntamos un código, como este:
Class MyScreenModule;
Field X, Y : Integer;
Procedure SetX(value : Integer);
Procedure SetY(value : Integer);
End Class.
Es casi lo mismo que un módulo! Ahora crea una instancia al proporcionar un puntero implícito a una instancia, como:
ScreenNumber1 := New MyScreenModule;
Y luego procedemos a utilizarlo:
ScreenNumber1::SetX(100);
Efectivamente convirtió su programación modular en una programación de múltiples instancias en la que la variable que mantiene el puntero del módulo en sí misma diferencia cada instancia. Gotcha?
Es una evolución de la abstracción.
Así que ahora tienes múltiples instancias, ¿cuál es el siguiente nivel?
Polimorfismo. Etc. El resto son lecciones orientadas a objetos bastante estándar.
Cuál es el punto de ? El punto es que los objetos orientados (como los procedimientos, como las subrutinas, etc.) no evolucionaron desde un punto de vista teórico sino desde la práctica de muchos codificadores que trabajaron durante décadas. Es una evolución de la programación informática, una evolución continua.
La programación orientada a objetos es un conjunto de características que varios idiomas implementan de formas ligeramente diferentes. No existe una definición formal única de OOP, pero varias personas han tratado de describir la POO en función de las características comunes de los lenguajes que afirman estar orientados a objetos. De Wikipedia:
Benjamin Cuire Pierce y algunos otros investigadores consideran inútil cualquier intento de destinar la POO a un conjunto mínimo de características. No obstante, identifica características fundamentales que admiten el estilo de programación OOP en la mayoría de los lenguajes orientados a objetos:
- Despacho dinámico: cuando se invoca un método en un objeto, el propio objeto determina qué código se ejecuta al buscar el método en tiempo de ejecución en una tabla asociada con el objeto. Esta característica distingue un objeto de un tipo de datos abstracto (o módulo), que tiene una implementación fija (estática) de las operaciones para todas las instancias. Es una metodología de programación que proporciona desarrollo de componentes modulares y, al mismo tiempo, es muy eficiente.
- Encapsulación (o métodos múltiples, en cuyo caso el estado se mantiene separado)
- Subtipo de polimorfismo
- herencia de objeto (o delegación)
- Recursión abierta: una variable especial (sintácticamente puede ser una palabra clave), generalmente llamada esto o self, que permite a un cuerpo de método invocar a otro cuerpo de método del mismo objeto. Esta variable está ligada tarde; permite que un método definido en una clase invoque otro método que se define más adelante, en alguna subclase de la misma.
OMI, un buen ejemplo de lo que hace que un lenguaje OO exitoso se pueda encontrar al comparar las similitudes entre JAVA y C #. Ambos son extremadamente populares y muy similares. Aunque creo que la idea general de un lenguaje OO mínimo puede encontrarse mirando Simula67. Creo que la idea general detrás de la programación orientada a objetos es que hace que parezca que la computadora piensa más como un humano, esto está respaldado por cosas como la herencia (tanto la clase "bicicleta de montaña" como la "bicicleta de carretera" pertenecen a la clase principal "bicicleta" ", y tienen las mismas características básicas). Otra idea importante es que los objetos (que pueden ser líneas de código ejecutables) se pueden pasar como variables, lo que permite que el programa se edite en función de ciertos criterios (aunque este punto es altamente discutible, cito la capacidad de cambiar cada instancia de un objeto basado en una comparación). Otro punto a destacar es la modularidad. Dado que los programas completos se pueden pasar de manera efectiva como una variable (porque todo se trata como un objeto), es más fácil modificar programas grandes, simplemente modificando la clase o el método al que se llama, y sin tener que modificar el método principal. Debido a esto, expandir la funcionalidad de un programa puede ser mucho más simple. Esta es la razón por la que las empresas web aman lenguajes como C # y JAVA (que son OO completos). A las compañías de juegos les gusta C ++ porque les da algo del control de un lenguaje imperativo (como C) y algunas de las características de la orientación a objetos (como C # o JAVA).
Revisé la página de wikipedia en OO http://en.wikipedia.org/wiki/Object-oriented_programming Tiene los principios, los fundamentos y la historia.
Mi entendimiento es que fue una progresión evolutiva de características e ideas en una variedad de idiomas que finalmente se unió con el impulso en los 90 para que la GUI se convirtiera en la corriente principal. Pero podría estar terriblemente equivocado :-D
Edición: lo que es aún más interesante es que la gente todavía discute sobre "qué es lo que hace que un lenguaje OO sea OO". No estoy seguro de que el conjunto de características esté generalmente de acuerdo en que defina un idioma OO.
Una definición formal que he encontrado para definir fuertemente y restringir los subtipos es el Principio de Sustitución de Liskov . Ciertamente, no es toda la programación orientada a objetos, pero aún así puede servir como un enlace a las bases formales en el desarrollo.
La orientación a objetos proviene de la psicología, no de las matemáticas.
Si lo piensas bien, se parece más a cómo trabajan los humanos que a cómo funcionan las computadoras . Pensamos en los objetos que clasificamos. Por ejemplo, esta mesa es un asiento de muebles .
Tomemos a Jean Piaget (1896-1980), quien trabajó en una teoría del desarrollo cognitivo de los niños. Wikipedia dice:
Piaget también tuvo un efecto considerable en el campo de la informática y la inteligencia artificial.
Algunos conceptos cognitivos que descubrió (que implican el concepto de orientación a objetos):
Clasificación La capacidad de agrupar objetos en función de características comunes.
Inclusión de clases La comprensión, más avanzada que la clasificación simple, de que algunas clases o conjuntos de objetos también son subconjuntos de una clase más grande. (Por ejemplo, hay una clase de objetos llamados perros. También hay una clase llamada animales. Pero todos los perros también son animales, por lo que la clase de animales incluye la de perros)
Leer más: Teoría del desarrollo de Piaget http://www.learningandteaching.info/learning/piaget.htm#ixzz1CipJeXyZ