Programación orientada a objetos

La programación orientada aobjetos(POO) es unparadigma de programaciónbasado en el concepto de "objetos", que puede contenerdatosy código: datos en forma decampos(a menudo conocidos comoatributosopropiedades) y código, en forma de procedimientos. (a menudo conocidos como métodos ).

Una característica de los objetos es que los propios procedimientos de un objeto pueden acceder y, a menudo, modificar los campos de datos de sí mismo (los objetos tienen una noción de thiso self). En OOP, los programas de computadora se diseñan haciéndolos a partir de objetos que interactúan entre sí. ^{[1] [2] Los} lenguajes OOP son diversos, pero los más populares están basados ​​en clases , lo que significa que los objetos son instancias de clases , que también determinan sus tipos .

Muchos de los lenguajes de programación más usados (como C ++, Java, Python, etc.) son multi-paradigma y soporte de programación orientado a objetos, en mayor o menor grado, por lo general en combinación con imperativo , la programación de procedimiento . Los lenguajes orientados a objetos importantes incluyen: (orden de lista basado en el índice TIOBE ) Java , C ++ , C # , Python , R , PHP , Visual Basic.NET , JavaScript , Ruby , Perl , Object Pascal , Objective-C , Dart , Swift , Scala , Kotlin , Common Lisp , MATLAB y Smalltalk .

Características

La programación orientada a objetos utiliza objetos, pero no todas las técnicas y estructuras asociadas se admiten directamente en lenguajes que afirman ser compatibles con POO. Las características enumeradas a continuación son comunes entre los lenguajes que se consideran fuertemente orientados a clases y objetos (o multi-paradigma con soporte de programación orientada a objetos), con notables excepciones mencionadas. ^{[3] [4] [5] [6]}

Compartido con idiomas que no son de programación orientada a objetos

• Variables que pueden almacenar información formateada en una pequeña cantidad de tipos de datos integrados como números enteros y caracteres alfanuméricos . Esto puede incluir estructuras de datos como cadenas , listas y tablas hash que están integradas o son el resultado de la combinación de variables mediante punteros de memoria .
• Procedimientos, también conocidos como funciones, métodos, rutinas o subrutinas , que toman entradas, generan resultados y manipulan datos. Los lenguajes modernos incluyen construcciones de programación estructuradas como bucles y condicionales .

El soporte de programación modular brinda la capacidad de agrupar procedimientos en archivos y módulos con fines organizativos. Los módulos tienen un espacio de nombres para que los identificadores de un módulo no entren en conflicto con un procedimiento o variable que comparta el mismo nombre en otro archivo o módulo.

Objetos y clases

Los lenguajes que admiten la programación orientada a objetos (OOP) suelen utilizar la herencia para la reutilización y la extensibilidad del código en forma de clases o prototipos . Aquellos que usan clases apoyan dos conceptos principales:

• Clases : las definiciones del formato de datos y los procedimientos disponibles para un tipo o clase de objeto determinado; también pueden contener datos y procedimientos (conocidos como métodos de clase) en sí mismos, es decir, las clases contienen los miembros de datos y las funciones de los miembros
• Objetos : instancias de clases

Los objetos a veces corresponden a cosas que se encuentran en el mundo real. Por ejemplo, un programa de gráficos puede tener objetos como "círculo", "cuadrado", "menú". Un sistema de compras en línea puede tener objetos como "carrito de compras", "cliente" y "producto". ^[7] A veces, los objetos representan entidades más abstractas, como un objeto que representa un archivo abierto, o un objeto que proporciona el servicio de traducir las medidas de la costumbre estadounidense a la métrica.

La programación orientada a objetos es más que solo clases y objetos; es todo un paradigma de programación basado en objetos [ sic ] (estructuras de datos) que contienen campos y métodos de datos. Es fundamental comprender esto; usar clases para organizar un montón de métodos no relacionados no es orientación a objetos.

Junade Ali, Dominando los patrones de diseño PHP ^[8]

Se dice que cada objeto es una instancia de una clase en particular (por ejemplo, un objeto con su campo de nombre establecido en "María" podría ser una instancia de la clase Empleado). Los procedimientos en la programación orientada a objetos se conocen como métodos ; las variables también se conocen como campos , miembros, atributos o propiedades. Esto conduce a los siguientes términos:

• Variables de clase : pertenecen a la clase en su conjunto ; solo hay una copia de cada uno
• Variables o atributos de instancia : datos que pertenecen a objetos individuales ; cada objeto tiene su propia copia de cada uno
• Variables miembro : se refiere tanto a la clase como a las variables de instancia definidas por una clase en particular.
• Métodos de clase: pertenecen a la clase en su conjunto y tienen acceso solo a las variables de clase y las entradas de la llamada al procedimiento
• Métodos de instancia: pertenecen a objetos individuales y tienen acceso a las variables de instancia para el objeto específico al que se llaman, las entradas y las variables de clase.

Se accede a los objetos como variables con una estructura interna compleja, y en muchos lenguajes son efectivamente punteros , que sirven como referencias reales a una sola instancia de dicho objeto en la memoria dentro de un montón o pila. Proporcionan una capa de abstracción que se puede utilizar para separar el código interno del externo. El código externo puede usar un objeto llamando a un método de instancia específico con un determinado conjunto de parámetros de entrada, leer una variable de instancia o escribir en una variable de instancia. Los objetos se crean llamando a un tipo especial de método en la clase conocido como constructor . Un programa puede crear muchas instancias de la misma clase mientras se ejecuta, que operan de forma independiente. Esta es una forma sencilla de utilizar los mismos procedimientos en diferentes conjuntos de datos.

La programación orientada a objetos que utiliza clases a veces se denomina programación basada en clases , mientras que la programación basada en prototipos no suele utilizar clases. Como resultado, se utiliza una terminología significativamente diferente pero análoga para definir los conceptos de objeto e instancia .

En algunos lenguajes, las clases y los objetos se pueden componer utilizando otros conceptos como rasgos y mixins .

Basado en clases vs basado en prototipos

En los lenguajes basados ​​en clases, las clases se definen de antemano y los objetos se instancian en función de las clases. Si se instancian dos objetos manzana y naranja de la clase Fruta , son inherentemente frutas y se garantiza que puede manejarlos de la misma manera; por ejemplo, un programador puede esperar la existencia de los mismos atributos como color o sugar_content o is_ripe .

En los lenguajes basados en prototipos, los objetos son las entidades principales. Ni siquiera existen clases . El prototipo de un objeto es simplemente otro objeto al que está vinculado el objeto. Cada objeto tiene un enlace de prototipo (y solo uno). Se pueden crear nuevos objetos basados ​​en objetos ya existentes elegidos como su prototipo. Puede llamar fruta a dos objetos diferentes manzana y naranja , si el objeto fruta existe, y tanto la manzana como la naranja tienen fruta como prototipo. La idea de la clase de fruta no existe explícitamente, sino como la clase de equivalencia de los objetos que comparten el mismo prototipo. Los atributos y métodos del prototipo se delegan a todos los objetos de la clase de equivalencia definida por este prototipo. Los atributos y métodos que pertenecen individualmente al objeto no pueden ser compartidos por otros objetos de la misma clase de equivalencia; por ejemplo, es posible que el atributo sugar_content no esté presente inesperadamente en Apple . Solo se puede implementar una herencia única a través del prototipo.

Envío dinámico / paso de mensajes

Es responsabilidad del objeto, no de cualquier código externo, seleccionar el código de procedimiento que se ejecutará en respuesta a una llamada a un método, normalmente buscando el método en tiempo de ejecución en una tabla asociada con el objeto. Esta característica se conoce como distribución dinámica y 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. Si la variabilidad de la llamada se basa en más de un único tipo de objeto en el que se llama (es decir, al menos otro objeto de parámetro está involucrado en la elección del método), se habla de envío múltiple .

Una llamada a un método también se conoce como paso de mensajes . Se conceptualiza como un mensaje (el nombre del método y sus parámetros de entrada) que se pasa al objeto para su envío.

Encapsulamiento

La encapsulación es un concepto de programación orientado a objetos que une los datos y las funciones que manipulan los datos, y que los mantiene a salvo de interferencias externas y uso indebido. La encapsulación de datos llevó al importante concepto de OOP de ocultación de datos .

Si una clase no permite que el código de llamada acceda a los datos internos del objeto y permite el acceso solo a través de métodos, esta es una forma fuerte de abstracción o ocultación de información conocida como encapsulación . Algunos lenguajes (Java, por ejemplo) permiten que las clases impongan restricciones de acceso explícitamente, por ejemplo, para denotar datos internos con la privatepalabra clave y designar métodos destinados a ser utilizados por código fuera de la clase con la publicpalabra clave. Los métodos también pueden diseñarse en niveles públicos, privados o intermedios como protected(que permite el acceso desde la misma clase y sus subclases, pero no objetos de una clase diferente). En otros lenguajes (como Python) esto se aplica solo por convención (por ejemplo, los privatemétodos pueden tener nombres que comienzan con un guión bajo ). La encapsulación evita que el código externo se ocupe del funcionamiento interno de un objeto. Esto facilita la refactorización del código , por ejemplo, permitiendo al autor de la clase cambiar cómo los objetos de esa clase representan sus datos internamente sin cambiar ningún código externo (siempre que las llamadas a métodos "públicos" funcionen de la misma manera). También anima a los programadores a poner todo el código relacionado con un determinado conjunto de datos en la misma clase, lo que lo organiza para que otros programadores lo comprendan fácilmente. La encapsulación es una técnica que fomenta el desacoplamiento .

Composición, herencia y delegación

Los objetos pueden contener otros objetos en sus variables de instancia; esto se conoce como composición de objetos . Por ejemplo, un objeto en la clase Empleado puede contener (ya sea directamente o mediante un puntero) un objeto en la clase Dirección, además de sus propias variables de instancia como "primer nombre" y "posición". La composición del objeto se utiliza para representar relaciones "tiene-a": cada empleado tiene una dirección, por lo que cada objeto Empleado tiene acceso a un lugar para almacenar un objeto Dirección (ya sea directamente incrustado dentro de sí mismo o en una ubicación separada direccionada mediante un puntero) .

Los idiomas que admiten clases casi siempre admiten la herencia . Esto permite que las clases se organicen en una jerarquía que represente las relaciones "es un tipo de". Por ejemplo, la clase Empleado puede heredar de la clase Persona. Todos los datos y métodos disponibles para la clase principal también aparecen en la clase secundaria con los mismos nombres. Por ejemplo, la clase Person podría definir las variables "first_name" y "last_name" con el método "make_full_name ()". Estos también estarán disponibles en la clase Empleado, que podría agregar las variables "cargo" y "salario". Esta técnica permite una fácil reutilización de los mismos procedimientos y definiciones de datos, además de reflejar potencialmente las relaciones del mundo real de una manera intuitiva. En lugar de utilizar tablas de base de datos y subrutinas de programación, el desarrollador utiliza objetos con los que el usuario puede estar más familiarizado: objetos de su dominio de aplicación. ^[9]

Las subclases pueden anular los métodos definidos por las superclases. La herencia múltiple está permitida en algunos idiomas, aunque esto puede complicar la resolución de invalidaciones. Algunos lenguajes tienen soporte especial para mixins , aunque en cualquier lenguaje con herencia múltiple, un mixin es simplemente una clase que no representa una relación es-un-tipo-de. Los mixins se utilizan normalmente para agregar los mismos métodos a varias clases. Por ejemplo, la clase UnicodeConversionMixin podría proporcionar un método unicode_to_ascii () cuando se incluye en la clase FileReader y la clase WebPageScraper, que no comparten un padre común.

Las clases abstractas no se pueden instanciar en objetos; existen sólo con el propósito de heredarlas en otras clases "concretas" que se pueden instanciar. En Java, la finalpalabra clave se puede utilizar para evitar que una clase sea subclasificada.

La doctrina de la composición sobre la herencia aboga por la implementación de relaciones tiene-a utilizando la composición en lugar de la herencia. Por ejemplo, en lugar de heredar de la clase Person, la clase Employee podría dar a cada objeto Employee un objeto Person interno, que luego tiene la oportunidad de ocultar del código externo incluso si la clase Person tiene muchos atributos o métodos públicos. Algunos idiomas, como Go , no admiten la herencia en absoluto.

El " principio abierto / cerrado " defiende que las clases y funciones "deberían estar abiertas a la extensión, pero cerradas a la modificación".

La delegación es otra característica del lenguaje que se puede utilizar como alternativa a la herencia.

Polimorfismo

El subtipo , una forma de polimorfismo , es cuando el código de llamada puede ser independiente de en qué clase de la jerarquía admitida está operando: la clase principal o una de sus descendientes. Mientras tanto, el mismo nombre de operación entre objetos en una jerarquía de herencia puede comportarse de manera diferente.

Por ejemplo, los objetos de tipo Círculo y Cuadrado se derivan de una clase común denominada Forma. La función Dibujar para cada tipo de Forma implementa lo que es necesario para dibujarse a sí mismo, mientras que el código de llamada puede permanecer indiferente al tipo particular de Forma que se está dibujando.

Este es otro tipo de abstracción que simplifica el código externo a la jerarquía de clases y permite una fuerte separación de preocupaciones .

Recursividad abierta

En los lenguajes que admiten la recursividad abierta , los métodos de objeto pueden llamar a otros métodos en el mismo objeto (incluidos ellos mismos), normalmente utilizando una variable especial o palabra clave llamada thiso self. Esta variable tiene un límite tardío ; 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.

Historia

Notación UML para una clase. Esta clase Button tiene variables para datos y funciones . Mediante herencia, se puede crear una subclase como subconjunto de la clase Button. Los objetos son instancias de una clase.

La terminología que invoca "objetos" y "orientada" en el sentido moderno de programación orientada a objetos hizo su primera aparición en el MIT a finales de la década de 1950 y principios de la de 1960. En el entorno del grupo de inteligencia artificial , ya en 1960, "objeto" podría referirse a elementos identificados ( átomos LISP ) con propiedades (atributos); ^{[10] [11]} Alan Kay citó más tarde una comprensión detallada de los aspectos internos de LISP como una fuerte influencia en su pensamiento en 1966. ^[12]

Pensé que los objetos eran como células biológicas y / o computadoras individuales en una red, que solo podían comunicarse con mensajes (por lo que la mensajería llegó desde el principio; tomó un tiempo ver cómo enviar mensajes en un lenguaje de programación lo suficientemente eficiente como para ser útil).

Alan Kay, ^[12]

Otro ejemplo temprano del MIT fue Sketchpad creado por Ivan Sutherland en 1960-1961; En el glosario del informe técnico de 1963 basado en su disertación sobre Sketchpad, Sutherland definió las nociones de "objeto" e "instancia" (con el concepto de clase cubierto por "maestro" o "definición"), aunque especializado en interacción gráfica. ^[13] Además, una versión de MIT ALGOL , AED-0, estableció un vínculo directo entre las estructuras de datos ("plexes", en ese dialecto) y los procedimientos, prefigurando lo que luego se denominaron "mensajes", "métodos" y "funciones miembro ". ^{[14] [15]}

En 1962, Kristen Nygaard inició un proyecto para un lenguaje de simulación en el Norwegian Computing Center , basado en su uso anterior de la simulación de Monte Carlo y su trabajo para conceptualizar sistemas del mundo real. Ole-Johan Dahl se unió formalmente al proyecto y el lenguaje de programación Simula fue diseñado para ejecutarse en la Computadora Automática Universal (UNIVAC) 1107. Simula introdujo conceptos importantes que son hoy una parte esencial de la programación orientada a objetos, como clase y objeto , herencia y enlace dinámico . ^[16] Simula también se diseñó para tener en cuenta la programación y la seguridad de los datos . Por motivos de seguridad de programación, se implementó un proceso de detección para que a través de recuentos de referencias, un recolector de basura de último recurso elimine los objetos no utilizados en la memoria de acceso aleatorio (RAM). Pero aunque la idea de objetos de datos ya se había establecido en 1965, el encapsulado de datos a través de niveles de alcance para variables , como privado (-) y público (+), no se implementó en Simula porque habría requerido que los procedimientos de acceso fueran también oculto. ^[17]

En las primeras etapas, se suponía que Simula era un paquete de procedimientos para el lenguaje de programación ALGOL 60. Insatisfechos con las restricciones impuestas por ALGOL, los investigadores decidieron desarrollar Simula en un lenguaje de programación completo, que utilizaba el compilador UNIVAC ALGOL 60. Simula fue promovido por Dahl y Nygaard a lo largo de 1965 y 1966, lo que llevó a un uso cada vez mayor del lenguaje de programación en Suecia, Alemania y la Unión Soviética . En 1968, el lenguaje estuvo ampliamente disponible a través de las computadoras Burroughs B5500 , y más tarde también se implementó en la computadora URAL-16 . En 1966, Dahl y Nygaard escribieron un compilador de Simula . Se preocuparon por poner en práctica el concepto de clase récord de Tony Hoare , que se había implementado en el lenguaje de simulación de propósito general SIMSCRIPT , de forma libre y similar al inglés . Se conformaron con un concepto de proceso generalizado con propiedades de clase de registro y una segunda capa de prefijos. Mediante el prefijo, un proceso podría hacer referencia a su predecesor y tener propiedades adicionales. Simula introdujo así la jerarquía de clases y subclases, y la posibilidad de generar objetos a partir de estas clases.

Un compilador de Simula 67 fue lanzado para el System / 360 y System / 370 ordenadores centrales de IBM en 1972. ^[16] En el mismo año un compilador de Simula 67 fue lanzado de forma gratuita para los franceses CII 10070 y CII Iris 80 ordenadores centrales . En 1974, la Asociación de Usuarios de Simula tenía miembros en 23 países diferentes. A principios de 1975, se lanzó un compilador de Simula 67 de forma gratuita para la familia de mainframe DECsystem-10 . En agosto del mismo año, el compilador DECsystem-10 Simula 67 se había instalado en 28 sitios, 22 de ellos en América del Norte. El lenguaje de programación Simula orientado a objetos fue utilizado principalmente por investigadores involucrados con el modelado físico , como modelos para estudiar y mejorar el movimiento de los barcos y su contenido a través de los puertos de carga. ^[dieciséis]

En la década de 1970, la primera versión de la Smalltalk lenguaje de programación fue desarrollado en el Xerox PARC por Alan Kay , Dan Ingalls y Adele Goldberg . Smaltalk-72 incluyó un entorno de programación y se tipeó dinámicamente , y al principio se interpretó , no se compiló . Smalltalk se hizo conocido por su aplicación de la orientación a objetos a nivel de lenguaje y su entorno de desarrollo gráfico. Smalltalk pasó por varias versiones y creció el interés por el idioma. ^[18] Si bien Smalltalk fue influenciado por las ideas introducidas en Simula 67, fue diseñado para ser un sistema completamente dinámico en el que las clases pudieran crearse y modificarse dinámicamente. ^[19]

En la década de 1970, Smalltalk influyó en la comunidad Lisp para incorporar técnicas basadas en objetos que se presentaron a los desarrolladores a través de la máquina Lisp . La experimentación con varias extensiones de Lisp (como LOOPS y Flavours que introducen herencia múltiple y mixins ) finalmente condujo al Common Lisp Object System , que integra programación funcional y programación orientada a objetos y permite la extensión a través de un protocolo de metaobjetos . En la década de 1980, hubo algunos intentos de diseñar arquitecturas de procesador que incluían soporte de hardware para objetos en la memoria, pero no tuvieron éxito. Los ejemplos incluyen Intel iAPX 432 y Linn Smart Rekursiv .

En 1981, Goldberg editó la edición de agosto de Byte Magazine , presentando Smalltalk y la programación orientada a objetos a una audiencia más amplia. En 1986, la Asociación de Maquinaria de Computación organizó la primera Conferencia sobre Programación, Sistemas, Lenguajes y Aplicaciones Orientadas a Objetos (OOPSLA), a la que inesperadamente asistieron 1.000 personas. A mediados de la década de 1980, Brad Cox desarrolló Objective-C , que había utilizado Smalltalk en ITT Inc. , y Bjarne Stroustrup , que había utilizado Simula para su tesis doctoral, finalmente creó el C ++ orientado a objetos . ^[18] En 1985, Bertrand Meyer también produjo el primer diseño del lenguaje Eiffel . Centrado en la calidad del software, Eiffel es un lenguaje de programación puramente orientado a objetos y una notación que respalda todo el ciclo de vida del software. Meyer describió el método de desarrollo de software de Eiffel, basado en un pequeño número de ideas clave de la ingeniería de software y la informática, en Construcción de software orientada a objetos . Esencial para el enfoque de calidad de Eiffel es el mecanismo de confiabilidad de Meyer, Design by Contract , que es una parte integral tanto del método como del lenguaje.

El gráfico del índice de popularidad del lenguaje de programación TIOBE de 2002 a 2018. En la década de 2000, el Java orientado a objetos (azul) y el C de procedimiento (negro) compitieron por la primera posición.

A principios y mediados de la década de 1990, la programación orientada a objetos se desarrolló como el paradigma de programación dominante cuando los lenguajes de programación que soportaban las técnicas se volvieron ampliamente disponibles. Estos incluyeron Visual FoxPro 3.0, ^{[20] [21] [22]} C ++ , ^[23] y Delphi ^{[ cita requerida ]} . Su dominio se vio reforzado por la creciente popularidad de las interfaces gráficas de usuario , que dependen en gran medida de las técnicas de programación orientadas a objetos. Un ejemplo de una biblioteca GUI dinámica estrechamente relacionada y un lenguaje OOP se puede encontrar en los marcos Cocoa en Mac OS X , escrito en Objective-C , una extensión de mensajería dinámica orientada a objetos para C basada en Smalltalk. Los kits de herramientas de OOP también mejoraron la popularidad de la programación impulsada por eventos (aunque este concepto no se limita a OOP).

En ETH Zürich , Niklaus Wirth y sus colegas también habían estado investigando temas como la abstracción de datos y la programación modular (aunque esto había sido de uso común en la década de 1960 o antes). Modula-2 (1978) incluyó ambos, y su diseño posterior, Oberon , incluyó un enfoque distintivo para la orientación de objetos, clases y demás.

Se han agregado características orientadas a objetos a muchos lenguajes previamente existentes, incluidos Ada , BASIC , Fortran , Pascal y COBOL . Agregar estas características a lenguajes que no fueron diseñados inicialmente para ellos a menudo generaba problemas de compatibilidad y mantenibilidad del código.

Más recientemente, han surgido varios lenguajes que están principalmente orientados a objetos, pero que también son compatibles con la metodología procedimental. Dos de estos lenguajes son Python y Ruby . Probablemente, los lenguajes orientados a objetos recientes más importantes comercialmente son Java , desarrollado por Sun Microsystems , así como C # y Visual Basic.NET (VB.NET), ambos diseñados para la plataforma .NET de Microsoft . Cada uno de estos dos marcos muestra, a su manera, el beneficio de usar OOP al crear una abstracción de la implementación. VB.NET y C # admiten la herencia entre idiomas, lo que permite clases definidas en un idioma a clases de subclase definidas en el otro idioma.

Idiomas de programación orientada a objetos

Simula (1967) se acepta generalmente como el primer idioma con las características principales de un lenguaje orientado a objetos. Fue creado para la realización de programas de simulación , en los que lo que pasó a llamarse objetos era la representación de información más importante. Smalltalk (1972 a 1980) es otro ejemplo temprano, y con el que se desarrolló gran parte de la teoría de la POO. En cuanto al grado de orientación a objetos, se pueden hacer las siguientes distinciones:

• Lenguajes llamados lenguajes OO "puros", porque todo en ellos es tratado consistentemente como un objeto, desde primitivas como caracteres y puntuación, hasta clases completas, prototipos, bloques, módulos, etc. Fueron diseñados específicamente para facilitar, incluso hacer cumplir, métodos orientados a objetos. Ejemplos: Ruby , Scala , Smalltalk , Eiffel , Emerald , ^[24] JADE , Self , Raku .
• Lenguajes diseñados principalmente para programación OO, pero con algunos elementos procedimentales. Ejemplos: Java , Python , C ++ , C # , Delphi / Object Pascal , VB.NET .
• Idiomas que históricamente son lenguajes de procedimiento , pero que se han ampliado con algunas características de OO. Ejemplos: PHP , Perl , Visual Basic (derivado de BASIC), MATLAB , COBOL 2002 , Fortran 2003 , ABAP , Ada 95 , Pascal .
• Lenguajes con la mayoría de las características de los objetos (clases, métodos, herencia), pero en una forma claramente original. Ejemplos: Oberon (Oberon-1 o Oberon-2).
• Lenguajes con soporte de tipos de datos abstractos que pueden usarse para parecerse a la programación OO, pero sin todas las características de la orientación a objetos. Esto incluye a objetos basado y basados en prototipos idiomas. Ejemplos: JavaScript , Lua , Modula-2 , CLU .
• Lenguajes camaleónicos que admiten múltiples paradigmas, incluido OO. Tcl se destaca entre estos para TclOO, un sistema de objetos híbrido que admite tanto programación basada en prototipos como OO basada en clases.

POO en lenguajes dinámicos

En los últimos años, la programación orientada a objetos se ha vuelto especialmente popular en los lenguajes de programación dinámica . Python , PowerShell , Ruby y Groovy son lenguajes dinámicos basados ​​en principios de programación orientada a objetos, mientras que Perl y PHP han estado agregando características orientadas a objetos desde Perl 5 y PHP 4, y ColdFusion desde la versión 6.

El modelo de objetos de documento de documentos HTML , XHTML y XML en Internet tiene enlaces al popular lenguaje JavaScript / ECMAScript . JavaScript es quizás el lenguaje de programación basado en prototipos más conocido , que emplea la clonación de prototipos en lugar de heredar de una clase (a diferencia de la programación basada en clases ). Otro lenguaje de secuencias de comandos que adopta este enfoque es Lua .

POO en un protocolo de red

Los mensajes que fluyen entre computadoras para solicitar servicios en un entorno cliente-servidor pueden diseñarse como las linealizaciones de objetos definidos por objetos de clase conocidos tanto por el cliente como por el servidor. Por ejemplo, un objeto linealizado simple constaría de un campo de longitud, un punto de código que identifica la clase y un valor de datos. Un ejemplo más complejo sería un comando que consta de la longitud y el punto de código del comando y valores que consisten en objetos linealizados que representan los parámetros del comando. Cada uno de estos comandos debe ser dirigido por el servidor a un objeto cuya clase (o superclase) reconoce el comando y es capaz de proporcionar el servicio solicitado. Los clientes y servidores se modelan mejor como estructuras complejas orientadas a objetos. La Arquitectura de administración de datos distribuidos (DDM) adoptó este enfoque y utilizó objetos de clase para definir objetos en cuatro niveles de una jerarquía formal:

• Campos que definen los valores de datos que forman los mensajes, como su longitud, punto de código y valores de datos.
• Objetos y colecciones de objetos similares a los que se encontrarían en un programa Smalltalk para mensajes y parámetros.
• Administradores similares a IBM i Objects , como un directorio de archivos y archivos que constan de metadatos y registros. Los gerentes proporcionan conceptualmente recursos de memoria y procesamiento para sus objetos contenidos.
• Un cliente o servidor que consta de todos los administradores necesarios para implementar un entorno de procesamiento completo, apoyando aspectos como servicios de directorio, seguridad y control de concurrencia.

La versión inicial de DDM definió los servicios de archivos distribuidos. Más tarde se amplió para ser la base de la Arquitectura de bases de datos relacionales distribuidas (DRDA).

Patrones de diseño

Los desafíos del diseño orientado a objetos se abordan mediante varios enfoques. El más común se conoce como los patrones de diseño codificados por Gamma et al. . Más ampliamente, el término " patrones de diseño " puede usarse para referirse a cualquier patrón de solución general, repetible, para un problema que ocurre comúnmente en el diseño de software. Algunos de estos problemas que ocurren comúnmente tienen implicaciones y soluciones particulares para el desarrollo orientado a objetos.

Herencia y subtipificación conductual

Es intuitivo suponer que la herencia crea una relación semántica " es una " y, por lo tanto, inferir que los objetos instanciados de subclases siempre se pueden usar con seguridad en lugar de aquellos instanciados de la superclase. Desafortunadamente, esta intuición es falsa en la mayoría de los lenguajes de programación orientada a objetos, en particular en todos aquellos que permiten objetos mutables . El polimorfismo de subtipos aplicado por el verificador de tipos en los lenguajes de programación orientada a objetos (con objetos mutables) no puede garantizar el subtipo de comportamiento en ningún contexto. El subtipo de comportamiento es indecidible en general, por lo que no puede ser implementado por un programa (compilador). Las jerarquías de clases u objetos deben diseñarse cuidadosamente, considerando posibles usos incorrectos que no se pueden detectar sintácticamente. Este problema se conoce como el principio de sustitución de Liskov .

Patrones de diseño de cuadrilla de cuatro

Design Patterns: Elements of Reusable Object-Oriented Software es un influyente libro publicado en 1994 por Erich Gamma , Richard Helm , Ralph Johnson y John Vlissides , al que a menudo se hace referencia con humor como "La banda de los cuatro". Además de explorar las capacidades y las trampas de la programación orientada a objetos, describe 23 problemas de programación comunes y patrones para resolverlos. En abril de 2007, el libro estaba en su 36ª edición.

El libro describe los siguientes patrones:

• Patrones de creación (5): patrón de la fábrica método , Abstract Factory , patrón Singleton , Builder , patrón Prototype
• Patrones estructurales (7): adapter , patrón puente , patrón Composite , Decorator , patrón de la fachada , flyweight , patrón Proxy
• Los patrones de comportamiento (11): Cadena de la responsabilidad patrón , patrón de comando , patrón intérprete , iterador , patrón de mediador , patrón Memento , patrón Observer , patrón de Estado , patrón de estrategia , la plantilla patrón del método , el patrón del visitante

Orientación a objetos y bases de datos

Tanto la programación orientada a objetos como los sistemas de gestión de bases de datos relacionales (RDBMS) son extremadamente comunes en el software actual.^[actualizar]. Dado que las bases de datos relacionales no almacenan objetos directamente (aunque algunos RDBMS tienen características orientadas a objetos para aproximarse a esto), existe una necesidad general de unir los dos mundos. El problema de unir los accesos de programación orientados a objetos y los patrones de datos con las bases de datos relacionales se conoce como desajuste de impedancia relacional de objetos . Hay varios enfoques para hacer frente a este problema, pero no hay una solución general sin inconvenientes. ^[25] Uno de los enfoques más comunes es el mapeo relacional de objetos , como se encuentra en lenguajes IDE como Visual FoxPro y bibliotecas como Java Data Objects y ActiveRecord de Ruby on Rails .

También hay bases de datos de objetos que se pueden utilizar para reemplazar los RDBMS, pero no han tenido tanto éxito técnica y comercial como los RDBMS.

Modelado y relaciones del mundo real

La programación orientada a objetos se puede utilizar para asociar objetos y procesos del mundo real con contrapartes digitales. Sin embargo, no todo el mundo está de acuerdo en que la programación orientada a objetos facilita el mapeo directo del mundo real (ver la sección de Críticas ) o que el mapeo del mundo real es incluso un objetivo valioso; Bertrand Meyer sostiene en Construcción de software orientado a objetos ^[26] que un programa no es un modelo del mundo sino un modelo de alguna parte del mundo; "La realidad es un primo eliminado dos veces". Al mismo tiempo, se han observado algunas limitaciones principales de la programación orientada a objetos. ^[27] Por ejemplo, el problema de círculo-elipse es difícil de manejar usando el concepto de herencia de OOP .

Sin embargo, Niklaus Wirth (quien popularizó el adagio ahora conocido como ley de Wirth : "El software se está volviendo más lento más rápido que el hardware se vuelve más rápido") dijo de OOP en su artículo, "Buenas ideas a través del espejo", "Este paradigma refleja fielmente el estructura de los sistemas 'en el mundo real' y, por lo tanto, es muy adecuado para modelar sistemas complejos con comportamientos complejos " ^[28] (contrastar el principio KISS ).

Steve Yegge y otros notaron que los lenguajes naturales carecen del enfoque OOP de priorizar estrictamente las cosas (objetos / sustantivos ) antes que las acciones (métodos / verbos ). ^[29] Este problema puede hacer que la programación orientada a objetos sufra soluciones más complicadas que la programación procedimental. ^[30]

OOP y flujo de control

La programación orientada a objetos fue desarrollada para aumentar la capacidad de reutilización y mantenimiento del código fuente. ^{[31] La} representación transparente del flujo de control no tenía prioridad y estaba destinada a ser manejada por un compilador. Con la creciente relevancia del hardware paralelo y la codificación multiproceso , el desarrollo de un flujo de control transparente se vuelve más importante, algo difícil de lograr con OOP. ^{[32] [33] [34] [35]}

Responsabilidad versus diseño basado en datos

El diseño impulsado por la responsabilidad define las clases en términos de un contrato, es decir, una clase debe definirse en torno a una responsabilidad y la información que comparte. Wirfs-Brock y Wilkerson contrastan esto con el diseño basado en datos , donde las clases se definen en torno a las estructuras de datos que deben mantenerse. Los autores sostienen que es preferible el diseño impulsado por la responsabilidad.

Directrices SOLID y GRASP

SOLID es un mnemónico inventado por Michael Feathers que representa y aboga por cinco prácticas de programación:

• Principio de responsabilidad única
• Principio abierto / cerrado
• Principio de sustitución de Liskov
• Principio de segregación de interfaz
• Principio de inversión de dependencia

GRASP (Patrones de software de asignación de responsabilidad general) es otro conjunto de pautas defendidas por Craig Larman .

Crítica

El paradigma OOP ha sido criticado por una serie de razones, que incluyen no cumplir con sus objetivos declarados de reutilización y modularidad, ^{[36] [37]} y por enfatizar demasiado un aspecto del diseño y modelado de software (datos / objetos) a expensas de otros importantes aspectos (computación / algoritmos). ^{[38] [39]}

Luca Cardelli ha afirmado que el código de programación orientada a objetos es "intrínsecamente menos eficiente" que el código de procedimiento, que la programación orientada a objetos puede tardar más en compilarse y que los lenguajes de programación orientada a objetos tienen "propiedades de modularidad extremadamente pobres con respecto a la extensión y modificación de clases", y tienden a ser extremadamente complejos. . ^[36] Este último punto es reiterado por Joe Armstrong , el principal inventor de Erlang , quien se cita diciendo: ^[37]

El problema con los lenguajes orientados a objetos es que tienen todo este entorno implícito que llevan consigo. Querías un plátano, pero lo que obtuviste fue un gorila sosteniendo el plátano y toda la jungla.

Un estudio de Potok et al. no ha mostrado una diferencia significativa en la productividad entre los enfoques OOP y procedimentales. ^[40]

Christopher J. Date declaró que la comparación crítica de OOP con otras tecnologías, relacional en particular, es difícil debido a la falta de una definición rigurosa y consensuada de OOP; ^[41] sin embargo, Date y Darwen han propuesto una base teórica en OOP que usa OOP como una especie de sistema de tipos personalizable para soportar RDBMS . ^[42]

En un artículo, Lawrence Krubner afirmó que, en comparación con otros lenguajes (dialectos LISP, lenguajes funcionales, etc.), los lenguajes OOP no tienen puntos fuertes únicos e infligen una gran carga de complejidad innecesaria. ^[43]

Alexander Stepanov compara desfavorablemente la orientación a objetos con la programación genérica : ^[38]

Encuentro POO técnicamente poco sólido. Intenta descomponer el mundo en términos de interfaces que varían en un solo tipo. Para hacer frente a los problemas reales, necesita álgebras de varios tipos: familias de interfaces que abarcan varios tipos. Encuentro la POO filosóficamente errónea. Afirma que todo es un objeto. Incluso si es cierto, no es muy interesante: decir que todo es un objeto es no decir nada en absoluto.

Paul Graham ha sugerido que la popularidad de la programación orientada a objetos dentro de las grandes empresas se debe a "grupos grandes (y que cambian con frecuencia) de programadores mediocres". Según Graham, la disciplina impuesta por OOP evita que cualquier programador "haga demasiado daño". ^[44]

Leo Brodie ha sugerido una conexión entre la naturaleza autónoma de los objetos y la tendencia a duplicar el código ^[45] en violación del principio de no repetirse ^[46] del desarrollo de software.

Steve Yegge señaló que, a diferencia de la programación funcional : ^[47]

La programación orientada a objetos pone los sustantivos en primer lugar. ¿Por qué irías tan lejos para poner una parte del discurso en un pedestal? ¿Por qué un tipo de concepto debe tener prioridad sobre otro? No es como si la programación orientada a objetos de repente hubiera hecho que los verbos fueran menos importantes en nuestra forma de pensar. Es una perspectiva extrañamente sesgada.

Rich Hickey , creador de Clojure , describió los sistemas de objetos como modelos demasiado simplistas del mundo real. Hizo hincapié en la incapacidad de la programación orientada a objetos para modelar el tiempo correctamente, lo que se vuelve cada vez más problemático a medida que los sistemas de software se vuelven más concurrentes. ^[39]

Eric S. Raymond , un programador de Unix y defensor del software de código abierto , ha criticado las afirmaciones que presentan la programación orientada a objetos como la "única solución verdadera", y ha escrito que los lenguajes de programación orientados a objetos tienden a fomentar programas de capas gruesas que destruir la transparencia. ^[48] Raymond compara esta desfavorablemente con el enfoque adoptado con Unix y el lenguaje de programación C . ^[48]

Rob Pike , un programador involucrado en la creación de UTF-8 y Go , ha llamado a la programación orientada a objetos "los números romanos de la computación" ^[49] y ha dicho que los lenguajes OOP frecuentemente cambian el enfoque de las estructuras de datos y algoritmos a los tipos . ^[50] Además, cita un ejemplo de un profesor de Java cuya solución "idiomática" a un problema era crear seis clases nuevas, en lugar de simplemente usar una tabla de búsqueda . ^[51]

Semántica formal

Los objetos son las entidades en tiempo de ejecución en un sistema orientado a objetos. Pueden representar a una persona, un lugar, una cuenta bancaria, una tabla de datos o cualquier elemento que tenga que manejar el programa.

Ha habido varios intentos de formalizar los conceptos utilizados en la programación orientada a objetos. Los siguientes conceptos y construcciones se han utilizado como interpretaciones de los conceptos de POO:

• tipos de datos co algebraicos ^[52]
• Los tipos de datos abstractos (que tienen tipos existenciales ) permiten la definición de módulos, pero estos no admiten el envío dinámico.
• tipos recursivos
• estado encapsulado
• herencia
• Los registros son la base para comprender los objetos si las funciones literales se pueden almacenar en campos (como en los lenguajes de programación funcional), pero los cálculos reales deben ser considerablemente más complejos para incorporar características esenciales de la programación orientada a objetos. Se han estudiado varias extensiones de System F <: que tratan con objetos mutables; ^[53] éstos permiten tanto polimorfismo de subtipo y polimorfismo paramétrico (genéricos)

Los intentos de encontrar una definición de consenso o teoría detrás de los objetos no han tenido mucho éxito (sin embargo, ver Abadi & Cardelli, A Theory of Objects ^[53] para definiciones formales de muchos conceptos y construcciones de POO), y a menudo divergen ampliamente. Por ejemplo, algunas definiciones se centran en actividades mentales y otras en la estructuración de programas. Una de las definiciones más simples es que OOP es el acto de usar estructuras de datos de "mapa" o matrices que pueden contener funciones y punteros a otros mapas, todos con algo de azúcar sintáctico y de alcance en la parte superior. La herencia se puede realizar clonando los mapas (a veces denominada "creación de prototipos").

Ver también

• Comparación de lenguajes de programación (programación orientada a objetos)
• Comparación de paradigmas de programación
• Ingeniería de software basada en componentes
• Diseño por contrato
• Asociación de objetos
• Base de datos de objetos
• Lenguaje de modelado de objetos
• Análisis y diseño orientado a objetos
• Desajuste de impedancia relacional de objeto (y el tercer manifiesto )
• Mapeo relacional de objetos

Sistemas

• CADES
• Arquitectura de agente de solicitud de objeto común (CORBA)
• Modelo de objeto componente distribuido
• Arquitectura de gestión de datos distribuidos
• Jeroo

Lenguajes de modelado

• IDEF4
• Idioma de descripción de la interfaz
• Lepus3
• UML

Referencias

1. Kindler, E .; Krivy, I. (2011). "Simulación orientada a objetos de sistemas con control sofisticado". Revista internacional de sistemas generales: 313–343.
2. Lewis, John; Loftus, William (2008). Soluciones de software Java Fundamentos del diseño de programación 6ª ed . Pearson Education Inc. ISBN 978-0-321-53205-3., sección 1.6 "Programación orientada a objetos"
3. Deborah J. Armstrong. Los quarks del desarrollo orientado a objetos . Una encuesta de casi 40 años de literatura informática que identificó una serie de conceptos fundamentales que se encuentran en la gran mayoría de las definiciones de POO, en orden descendente de popularidad: herencia, objeto, clase, encapsulación, método, transmisión de mensajes, polimorfismo y abstracción.
4. John C. Mitchell , Conceptos en lenguajes de programación , Cambridge University Press, 2003, ISBN  0-521-78098-5 , p. 278. Listas: envío dinámico, abstracción, polimorfismo de subtipo y herencia.
5. Michael Lee Scott, pragmática del lenguaje de programación , edición 2, Morgan Kaufmann, 2006, ISBN  0-12-633951-1 , pág. 470. Enumera la encapsulación, la herencia y el envío dinámico.
6. Pierce, Benjamin (2002). Tipos y lenguajes de programación . Prensa del MIT. ISBN 978-0-262-16209-8., sección 18.1 "¿Qué es la programación orientada a objetos?" Listas: envío dinámico, encapsulación o métodos múltiples (envío múltiple), polimorfismo de subtipo, herencia o delegación, recursividad abierta ("este" / "yo")
7. Booch, Grady (1986). Ingeniería de software con Ada . Addison Wesley. pag. 220. ISBN 978-0-8053-0608-8. Quizás la mayor fortaleza de un enfoque de desarrollo orientado a objetos es que ofrece un mecanismo que captura un modelo del mundo real.
8. Ali, Junade (28 de septiembre de 2016). Dominar los patrones de diseño PHP | Libros PACKT (1 ed.). Birmingham, Inglaterra, Reino Unido: Packt Publishing Limited. pag. 11. ISBN 978-1-78588-713-0. Consultado el 11 de diciembre de 2017 .
9. Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Ingeniería de Software Orientada a Objetos . Addison-Wesley ACM Press. págs.  43–69 . ISBN 978-0-201-54435-0.
10. McCarthy, J .; Brayton, R .; Edwards, D .; Fox, P .; Hodes, L .; Luckham, D .; Maling, K .; Park, D .; Russell, S. (marzo de 1960). "Manual del programador LISP I" (PDF) . Boston , Massachusetts : Grupo de Inteligencia Artificial, Centro de Computación y Laboratorio de Investigación del MIT : 88f. Archivado desde el original (PDF) el 17 de julio de 2010. En el idioma local del MIT, las listas de asociación [de símbolos atómicos] también se denominan "listas de propiedades", y los símbolos atómicos a veces se denominan "objetos".
11. McCarthy, John ; Abrahams, Paul W .; Edwards, Daniel J .; Hart, swapnil d .; Levin, Michael I. (1962). Manual del programador LISP 1.5 . MIT Press . pag. 105 . ISBN 978-0-262-13011-0. Objeto: sinónimo de símbolo atómico
12. "Dr. Alan Kay sobre el significado de la" programación orientada a objetos " " . 2003 . Consultado el 11 de febrero de 2010 .
13. Sutherland, IE (30 de enero de 1963). "Bloc de dibujo: un sistema de comunicación gráfica hombre-máquina" . Informe técnico No. 296, Laboratorio Lincoln, Instituto de Tecnología de Massachusetts a través del Centro de Información Técnica de Defensa (stinet.dtic.mil) . Consultado el 17 de julio de 2019 .
14. El desarrollo de los lenguajes Simula, Kristen Nygaard , Ole-Johan Dahl , p.254 Uni-kl.ac.at
15. Ross, Doug. "El primer lenguaje de ingeniería de software" . Cronología del laboratorio LCS / AI . Laboratorio de Informática e Inteligencia Artificial del MIT . Consultado el 13 de mayo de 2010 .
16. Holmevik, Jan Rune (1994). "Compilación de Simula: un estudio histórico de la génesis tecnológica" (PDF) . IEEE Annals of the History of Computing . 16 (4): 25–37. doi : 10.1109 / 85.329756 . Archivado desde el original (PDF) el 30 de agosto de 2017 . Consultado el 3 de marzo de 2018 .
17. Dahl, Ole Johan (2004). "El nacimiento de la orientación a objetos: los lenguajes de Simula" (PDF) . De la orientación a objetos a los métodos formales . Apuntes de conferencias en Ciencias de la Computación. 2635 . págs. 15-25. CiteSeerX  10.1.1.133.6730 . doi : 10.1007 / 978-3-540-39993-3_3 . ISBN 978-3-540-21366-6. Consultado el 3 de marzo de 2018 .
18. Bertrand Meyer (2009). Toque de clase: aprender a programar bien con objetos y contratos . Springer Science & Business Media. pag. 329. bibcode : 2009tclp.book ..... M . ISBN 978-3-540-92144-8.
19. Kay, Alan. "La historia temprana de Smalltalk" . Archivado desde el original el 10 de julio de 2008 . Consultado el 13 de septiembre de 2007 .
20. 1995 (junio) Visual FoxPro 3.0, FoxPro evoluciona de un lenguaje procedimental a un lenguaje orientado a objetos. Visual FoxPro 3.0 presenta un contenedor de base de datos, capacidades integradas de cliente / servidor, compatibilidad con tecnologías ActiveX y automatización OLE y compatibilidad nula. Resumen de lanzamientos de Fox
21. Sitio web de FoxPro History: Foxprohistory.org
22. Guía de revisores de 1995 para Visual FoxPro 3.0: DFpug.de
23. Khurana, Rohit (1 de noviembre de 2009). Programación Orientada a Objetos con C ++, 1E . ISBN 978-81-259-2532-3.
24. "El lenguaje de programación Emerald" . 26 de febrero de 2011.
25. Neward, Ted (26 de junio de 2006). "El Vietnam de la informática" . La interoperabilidad ocurre. Archivado desde el original el 4 de julio de 2006 . Consultado el 2 de junio de 2010 .
26. Meyer, segunda edición, p. 230
27. M.Trofimov, OOOP - La tercera solución "O": Open OOP. Primera clase, Dios mío , 1993, vol. 3, número 3, p.14.
28. Wirth, Nicklaus (2006). "Buenas ideas, a través del espejo" (PDF) . Computadora . 39 (1): 28–39. doi : 10.1109 / mc.2006.20 . Archivado desde el original (PDF) el 12 de octubre de 2016 . Consultado el 2 de octubre de 2016 .
29. Yegge, Steve (30 de marzo de 2006). "Ejecución en el Reino de los Sustantivos" . steve-yegge.blogspot.com . Consultado el 3 de julio de 2010 .
30. Boronczyk, Timothy (11 de junio de 2009). "¿Qué hay de malo con la programación orientada a objetos" . zaemis.blogspot.com . Consultado el 3 de julio de 2010 .
31. Ambler, Scott (1 de enero de 1998). "Una mirada realista a la reutilización orientada a objetos" . drdobbs.com . Consultado el 4 de julio de 2010 .
32. Shelly, Asaf (22 de agosto de 2008). "Defectos del modelado orientado a objetos" . Red de software Intel . Consultado el 4 de julio de 2010 .
33. James, Justin (1 de octubre de 2007). "El multihilo es un verbo, no un sustantivo" . techrepublic.com. Archivado desde el original el 10 de octubre de 2007 . Consultado el 4 de julio de 2010 .
34. Shelly, Asaf (22 de agosto de 2008). "CÓMO: Programación multinúcleo (multiprocesamiento) Directrices de diseño de clases de Visual C ++, funciones de miembro" . support.microsoft.com . Consultado el 4 de julio de 2010 .
35. Robert Harper (17 de abril de 2011). "Algunas reflexiones sobre la enseñanza de FP" . Blog de tipo existencial . Consultado el 5 de diciembre de 2011 .
36. Cardelli, Luca (1996). "Malas propiedades de ingeniería de lenguajes orientados a objetos" . Computación ACM. Surv . 28 (4es): 150 – es. doi : 10.1145 / 242224.242415 . ISSN  0360-0300 . Consultado el 21 de abril de 2010 .
37. Armstrong, Joe. En Codificadores en el trabajo: reflexiones sobre el oficio de la programación. Peter Seibel, ed. Codersatwork.com Archivado el 5 de marzo de 2010 en Wayback Machine , consultado el 13 de noviembre de 2009.
38. Stepanov, Alexander . "STLport: una entrevista con A. Stepanov" . Consultado el 21 de abril de 2010 .
39. Rich Hickey, discurso de apertura de JVM Languages ​​Summit 2009, ¿Ya llegamos? Noviembre de 2009.
40. Potok, Thomas; Mladen Vouk; Andy Rindos (1999). "Análisis de productividad de software orientado a objetos desarrollado en un entorno comercial" (PDF) . Software: práctica y experiencia . 29 (10): 833–847. doi : 10.1002 / (SICI) 1097-024X (199908) 29:10 <833 :: AID-SPE258> 3.0.CO; 2-P . Consultado el 21 de abril de 2010 .
41. Fecha de CJ, Introducción a los sistemas de bases de datos, 6ª ed., Página 650
42. CJ Date, Hugh Darwen. Foundation for Future Database Systems: The Third Manifesto (2nd Edition)
43. Krubner, Lawrence. "La Programación Orientada a Objetos es un desastre costoso que debe terminar" . smashcompany.com. Archivado desde el original el 14 de octubre de 2014 . Consultado el 14 de octubre de 2014 .
44. Graham, Paul . "Por qué ARC no está especialmente orientado a objetos" . PaulGraham.com . Consultado el 13 de noviembre de 2009 .
45. Brodie, Leo (1984). Pensando en el futuro (PDF) . págs. 92–93 . Consultado el 4 de mayo de 2018 .
46. Caza, Andrew. "No se repita" . Programación de Categoría Extrema . Consultado el 4 de mayo de 2018 .
47. "Diatribas del blog de Stevey: ejecución en el reino de los sustantivos" . Consultado el 20 de mayo de 2020 .
48. Eric S. Raymond (2003). "El arte de la programación Unix: Unix y lenguajes orientados a objetos" . Consultado el 6 de agosto de 2014 .
49. Pike, Rob (2 de marzo de 2004). "[9fans] Re: Hilos: Coser insignias de honor en un Kernel" . comp.os.plan9 (lista de correo) . Consultado el 17 de noviembre de 2016 .
50. Pike, Rob (25 de junio de 2012). "Menos es exponencialmente más" . Consultado el 1 de octubre de 2016 .
51. Pike, Rob (14 de noviembre de 2012). "Hace unos años vi esta página" . Archivado desde el original el 14 de agosto de 2018 . Consultado el 1 de octubre de 2016 .
52. Encuesta, Erik. "Subtipado y herencia para tipos de datos categóricos" (PDF) . Consultado el 5 de junio de 2011 .
53. Abadi, Martin ; Cardelli, Luca (1996). Una teoría de los objetos . Springer-Verlag Nueva York, Inc. ISBN 978-0-387-94775-4. Consultado el 21 de abril de 2010 .

Otras lecturas

• Abadi, Martin ; Luca Cardelli (1998). Una teoría de los objetos . Springer Verlag . ISBN 978-0-387-94775-4.
• Abelson, Harold ; Gerald Jay Sussman (1997). Estructura e interpretación de programas informáticos . MIT Press . ISBN 978-0-262-01153-2.
• Armstrong, Deborah J. (febrero de 2006). "Los quarks del desarrollo orientado a objetos". Comunicaciones de la ACM . 49 (2): 123-128. doi : 10.1145 / 1113034.1113040 . ISSN  0001-0782 .
• Booch, Grady (1997). Análisis y diseño orientado a objetos con aplicaciones . Addison-Wesley . ISBN 978-0-8053-5340-2.
• Eeles, Peter; Oliver Sims (1998). Creación de objetos comerciales . John Wiley e hijos . ISBN 978-0-471-19176-6.
• Gamma, Erich ; Richard Helm ; Ralph Johnson ; John Vlissides (1995). Patrones de diseño: elementos de software orientado a objetos reutilizables . Addison-Wesley. Bibcode : 1995dper.book ..... G . ISBN 978-0-201-63361-0.
• Harmon, Paul ; William Morrissey (1996). El libro de casos de tecnología de objetos: lecciones de aplicaciones comerciales galardonadas . John Wiley e hijos. ISBN 978-0-471-14717-6.
• Jacobson, Ivar (1992). Ingeniería de software orientada a objetos: un enfoque basado en casos de uso . Addison-Wesley. Bibcode : 1992oose.book ..... J . ISBN 978-0-201-54435-0.
• Kay, Alan . La historia temprana de Smalltalk . Archivado desde el original el 4 de abril de 2005 . Consultado el 18 de abril de 2005 .
• Meyer, Bertrand (1997). Construcción de software orientado a objetos . Prentice Hall . ISBN 978-0-13-629155-8.
• Pecinovsky, Rudolf (2013). POO - Aprenda el pensamiento y la programación orientados a objetos . Publicación Bruckner. ISBN 978-80-904661-8-0.
• Rumbaugh, James ; Michael Blaha; William Premerlani; Frederick Eddy; William Lorensen (1991). Modelado y Diseño Orientado a Objetos . Prentice Hall. ISBN 978-0-13-629841-0.
• Schach, Stephen (2006). Ingeniería de software clásica y orientada a objetos, séptima edición . McGraw-Hill . ISBN 978-0-07-319126-3.
• Schreiner, Axel-Tobias (1993). Programación orientada a objetos con ANSI-C . Hanser. hdl : 1850/8544 . ISBN 978-3-446-17426-9.
• Taylor, David A. (1992). Sistemas de información orientados a objetos: planificación e implementación . John Wiley e hijos. ISBN 978-0-471-54364-0.
• Weisfeld, Matt (2009). El proceso de pensamiento orientado a objetos, tercera edición . Addison-Wesley . ISBN 978-0-672-33016-2.
• West, David (2004). Pensamiento de objetos (referencia para desarrolladores) . Microsoft Press . ISBN 978-0-7356-1965-4.

enlaces externos

• Programación orientada a objetos en Curlie
• Introducción a los conceptos de programación orientada a objetos (OOP) y más por LWC Nirosh
• Discusión sobre los defectos de OOD
• Conceptos de programación orientada a objetos (tutoriales de Java)
• Ciencia o aceite de serpiente: ingeniería de software empírica Reflexiones sobre la ingeniería de software y sistemas, por Ian Sommerville (2011-8-29)