Hispanopedia Wiki
Articulo de referencia

Programación orientada a objetos

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

Hispanopedia WikiContenido en espanolLectura gratuita

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

La programación orientada a objetos ( POO ) es un paradigma de programación basado en objetos [ 1 ] , entidades de software que encapsulan datos y funciones . Un programa informático POO consta de objetos que interactúan entre sí. [ 2 ] [ 3 ] Un lenguaje POO es aquel que proporciona características de programación orientada a objetos, pero como el conjunto de características que contribuyen a la POO es objeto de debate, clasificar un lenguaje como POO —y el grado en que la soporta— es discutible. Dado que los paradigmas no son mutuamente excluyentes, un lenguaje puede ser multiparadigma (es decir, categorizado como más que solo POO).

Entre los lenguajes notables con soporte para POO se incluyen Ada , ActionScript , C++ , Common Lisp , C# , Dart , Eiffel , Fortran 2003 , Haxe , Java , [ 4 ] JavaScript , Kotlin , Logo , MATLAB , Objective-C , Object Pascal , Perl , PHP , Python , R , Raku , Ruby , Scala , SIMSCRIPT , Simula , Smalltalk , Swift , Vala y Visual Basic (.NET) .

Historia

La idea de "objetos" en programación comenzó con el grupo de inteligencia artificial del Instituto Tecnológico de Massachusetts (MIT) a finales de la década de 1950 y principios de la de 1960. Allí, "objeto" se refería a átomos LISP con propiedades (atributos) identificadas. [ 5 ] [ 6 ] Otro ejemplo temprano fue Sketchpad, creado por Ivan Sutherland en el MIT entre 1960 y 1961. En el glosario de su informe técnico, Sutherland definió términos como "objeto" e "instancia" (con el concepto de clase cubierto por "maestro" o "definición"), aunque especializados para la interacción gráfica. [ 7 ] Más tarde, en 1968, AED-0, la versión del MIT del lenguaje de programación ALGOL , conectó estructuras de datos ("plexos") y procedimientos, prefigurando lo que más tarde se denominaría "mensajes", "métodos" y "funciones miembro". [ 8 ] [ 9 ] Temas como la abstracción de datos y la programación modular eran puntos comunes de discusión en ese momento.

Mientras tanto, en Noruega, Simula se desarrolló entre 1961 y 1967. [ 8 ] Simula introdujo ideas esenciales de la programación orientada a objetos, como clases , herencia y enlace dinámico . [ 10 ] Simula fue utilizada principalmente por investigadores dedicados al modelado físico , como el movimiento de barcos y su carga a través de puertos de carga. [ 10 ] Simula es generalmente aceptada como el primer lenguaje con las características y el marco principales de un lenguaje orientado a objetos. [ 11 ]

Pensaba en los objetos como células biológicas o computadoras individuales en una red, capaces únicamente de comunicarse mediante mensajes (por lo que la mensajería surgió desde el principio; llevó un tiempo descubrir cómo implementar la mensajería en un lenguaje de programación de manera lo suficientemente eficiente como para que resultara útil).

— Alan Kay, [ 1 ]

Influenciado tanto por el MIT como por Simula, Alan Kay comenzó a desarrollar sus propias ideas en noviembre de 1966. Posteriormente crearía Smalltalk , un influyente lenguaje de POO. Para 1967, Kay ya utilizaba el término "programación orientada a objetos" en sus conversaciones. [ 1 ] Aunque a veces se le llama el "padre" de la POO, [ 12 ] Kay ha dicho que sus ideas difieren de cómo se entiende comúnmente la POO, y ha insinuado que la comunidad científica no adoptó su concepto. [ 1 ] Un memorando del MIT de 1976, del que Barbara Liskov fue coautora, enumera Simula 67 , CLU y Alphard como lenguajes orientados a objetos, pero no menciona Smalltalk. [ 13 ]

En la década de 1970, Alan Kay , Dan Ingalls y Adele Goldberg desarrollaron la primera versión del lenguaje de programación Smalltalk en Xerox PARC . Smalltalk-72 se destacó por el uso de objetos a nivel de lenguaje y su entorno de desarrollo gráfico. [ 14 ] Smalltalk era un sistema totalmente dinámico, que permitía a los usuarios crear y modificar clases mientras trabajaban. [ 15 ] Gran parte de la teoría de la POO se desarrolló en el contexto de Smalltalk, por ejemplo, la herencia múltiple. [ 16 ]

A finales de los años 70 y 80, la POO alcanzó gran prominencia. El Lisp orientado a objetos Flavors se desarrolló a partir de 1979, introduciendo la herencia múltiple y los mixins . [ 17 ] En agosto de 1981, Byte Magazine destacó Smalltalk y la POO, presentando estas ideas a una amplia audiencia. [ 18 ] LOOPS, el sistema de objetos para Interlisp -D, fue influenciado por Smalltalk y Flavors, y se publicó un artículo al respecto en 1982. [ 19 ] En 1986, la primera Conferencia sobre Programación Orientada a Objetos, Sistemas, Lenguajes y Aplicaciones ( OOPSLA ) contó con la asistencia de 1000 personas. Esta conferencia marcó el inicio de los esfuerzos para consolidar los sistemas de objetos Lisp, lo que finalmente resultó en el Common Lisp Object System . En los años 80, hubo algunos intentos de diseñar arquitecturas de procesadores que incluyeran soporte de hardware para objetos en memoria , pero estos no tuvieron éxito. Los ejemplos incluyen el Intel iAPX 432 y el Linn Smart Rekursiv .

A mediados de la década de 1980, surgieron nuevos lenguajes orientados a objetos como Objective-C , C++ y el lenguaje Eiffel . Objective-C fue desarrollado por Brad Cox , quien había utilizado Smalltalk en ITT Inc. Bjarne Stroustrup creó C++ basándose en su experiencia con Simula para su tesis doctoral. [ 14 ] Bertrand Meyer produjo el primer diseño del lenguaje Eiffel en 1985, que se centraba en la calidad del software mediante un enfoque de diseño por contrato . [ 20 ]

En la década de 1990, la POO se convirtió en la principal forma de programación, especialmente a medida que más lenguajes la soportaban. Estos incluían Visual FoxPro 3.0, [ 21 ] [ 22 ] C++ , [ 23 ] y Delphi . La POO se hizo aún más popular con el auge de las interfaces gráficas de usuario , que utilizaban objetos para botones, menús y otros elementos. Un ejemplo bien conocido es el framework Cocoa de Apple , utilizado en macOS y escrito en Objective-C . Los kits de herramientas de POO también impulsaron la popularidad de la programación orientada a eventos .

En la ETH Zúrich , Niklaus Wirth y sus colegas crearon nuevos enfoques para la programación orientada a objetos (POO). Modula-2 (1978) y Oberon (1987) incluían un enfoque distintivo para la orientación a objetos, las clases y la verificación de tipos entre módulos. La herencia no es evidente en el diseño de Wirth, ya que su nomenclatura apunta en la dirección opuesta: se denomina extensión de tipos y el punto de vista va del padre al heredero.

Muchos lenguajes de programación que se desarrollaron inicialmente antes de que la programación orientada a objetos (POO) se popularizara, se han ampliado con características de programación orientada a objetos, incluidos Ada , BASIC , Fortran , Pascal y COBOL .

Características

Las características de la POO que ofrecen los lenguajes varían. A continuación se muestran algunas características comunes de los lenguajes de POO. [ 24 ] [ 25 ] [ 26 ] [ 27 ] Comparar la POO con otros estilos, como la programación relacional , es difícil porque no existe una definición clara y consensuada de la POO. [ 28 ]

Encapsulación y ocultación de información

La ocultación y la encapsulación de información pueden referirse a varios conceptos relacionados:

  • Cohesión : mantener juntos los campos y métodos relacionados . Un campo (también llamado atributo o propiedad) contiene información (también llamado estado) como una variable . Un método (también llamado función o acción) define el comportamiento mediante código lógico.
  • El desacoplamiento consiste en organizar el código de manera que solo ciertas partes de los datos sean utilizadas por funciones relacionadas. El desacoplamiento facilita el cambio del funcionamiento interno de un objeto sin afectar otras partes del código , como en la refactorización del código . [ 29 ] Los objetos actúan como un límite entre su funcionamiento interno y el código externo que lo consume.
  • Ocultación de datos : mantener los detalles internos de un objeto ocultos al código externo. El código que consume el objeto solo puede interactuar con él a través de sus miembros públicos, debido a que el lenguaje proporciona modificadores de acceso que controlan la visibilidad.

Algunos lenguajes de programación, como Java, proporcionan ocultación de información mediante palabras clave de visibilidad ( privatey public). [ 30 ] Algunos lenguajes, como Python, no proporcionan una función de visibilidad, pero los desarrolladores pueden seguir una convención como comenzar el nombre de un miembro privado con un guion bajo. También existen niveles intermedios de acceso, como protectedla palabra clave de Java, (que permite el acceso desde la misma clase y sus subclases, pero no desde objetos de una clase diferente), y la internalpalabra clave en C#, Swift y Kotlin, que restringe el acceso a archivos dentro del mismo módulo. [ 31 ]

Los defensores de la ocultación de información y la abstracción de datos afirman que facilita la reutilización del código y representa intuitivamente situaciones del mundo real. [ 32 ] [ 33 ] Sin embargo, otros argumentan que la POO no mejora la legibilidad ni la modularidad. [ 34 ] [ 35 ] Eric S. Raymond ha escrito que los lenguajes de POO tienden a fomentar programas con muchas capas que destruyen la transparencia. [ 36 ] Raymond compara esto desfavorablemente con el enfoque adoptado con Unix y el lenguaje C. [ 36 ]

SOLID incluye el principio abierto/cerrado , que establece que las clases y funciones deben estar "abiertas a la extensión, pero cerradas a la modificación". Luca Cardelli ha afirmado que los lenguajes de POO tienen "propiedades de modularidad extremadamente deficientes con respecto a la extensión y modificación de clases" y tienden a ser extremadamente complejos. [ 34 ] Este último punto es reiterado por Joe Armstrong , el principal inventor de Erlang , quien es citado diciendo: [ 35 ]

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

Leo Brodie dice que ocultar información puede llevar a código duplicado , [ 37 ] lo cual va en contra de la regla de no repetirse en el desarrollo de software. [ 38 ]

Herencia

La herencia puede ser admitida a través de la clase o el prototipo , que tienen diferencias pero usan términos similares como objeto e instancia .

Basado en clases

En la programación orientada a clases , el tipo más común de POO, un objeto es una instancia de una clase. La clase define los datos (variables) y los métodos (lógica). Un objeto se crea mediante el constructor . Cada instancia de la clase tiene el mismo conjunto de variables y métodos. Los elementos pueden incluir:

  • Variable de clase : pertenece a la propia clase; todos los objetos de la clase comparten una copia.
  • Variable de instancia : pertenece a un objeto; cada objeto tiene su propia versión de estas variables.
  • Variable miembro : se refiere tanto a las variables de clase como a las variables de instancia de una clase.
  • Método de clase: solo puede usar variables de clase.
  • Método de instancia: pertenece a un objeto; puede utilizar variables tanto de instancia como de clase.

Las clases pueden heredar de otras clases, creando una jerarquía de clases: un caso de una subclase que hereda de una superclase. Por ejemplo, una Employeeclase podría heredar de una Personclase que dota al objeto Employee con las variables de Person. La subclase puede agregar variables y métodos que no afectan a la superclase. La mayoría de los lenguajes también permiten que la subclase sobrescriba los métodos de la superclase. Algunos lenguajes admiten la herencia múltiple , donde una clase puede heredar de más de una clase, y otros lenguajes admiten de manera similar mixins o traits . Por ejemplo, un mixin llamado UnicodeConversionMixin podría agregar un método unicode_to_ascii() tanto a una clase FileReader como a una clase WebPageScraper.

Una clase abstracta no puede instanciarse directamente como un objeto. Solo se utiliza como superclase.

Otras clases son clases de utilidad que contienen únicamente variables y métodos de clase y no están destinadas a ser instanciadas o subclases. [ 39 ]

Basado en prototipos

En lugar de proporcionar un concepto de clase, en la programación basada en prototipos , un objeto se vincula a otro objeto, llamado su prototipo o padre . En Self, un objeto puede tener varios padres o ninguno, [ 40 ] pero en el lenguaje basado en prototipos más popular, JavaScript , un objeto tiene exactamente un vínculo de prototipo, hasta el objeto base cuyo prototipo es nulo.

Un prototipo actúa como modelo para nuevos objetos. Por ejemplo, si tienes un objeto fruit, puedes crear dos objetos appley orangeque compartan características del fruitprototipo. Los lenguajes basados ​​en prototipos también permiten que los objetos tengan sus propias propiedades únicas, por lo que el appleobjeto podría tener un atributo sugar_content, mientras que los objetos orangeo fruitno lo tienen.

Sin herencia

En todos los lenguajes de POO, mediante la composición de objetos , un objeto puede contener otros objetos. Por ejemplo, un Employeeobjeto podría contener otro Addressobjeto, junto con otra información como namey position. La composición es una relación "tiene un", como "un empleado tiene una dirección". Algunos lenguajes, como Go , no admiten la herencia. [ 41 ] En cambio, fomentan la " composición sobre la herencia ", donde los objetos se construyen utilizando partes más pequeñas en lugar de relaciones padre-hijo. Por ejemplo, en lugar de heredar de la clase Persona, la clase Empleado podría simplemente contener un objeto Persona. Esto permite que la clase Empleado controle cuánto de Persona expone a otras partes del programa. La delegación es otra característica del lenguaje que puede usarse como alternativa a la herencia.

Los programadores tienen opiniones diversas sobre la herencia. Bjarne Stroustrup, autor de C++, afirmó que es posible programar en objetos sin herencia. [ 42 ] Rob Pike criticó la herencia por crear jerarquías complejas en lugar de soluciones más sencillas. [ 43 ]

Herencia y subtipificación del comportamiento

A menudo se piensa que si una clase hereda de otra, significa que la subclase es una versión más específica de la clase original. Esto presupone que la semántica del programa establece que los objetos de la subclase siempre pueden reemplazar a los objetos de la clase original sin problemas. Este concepto se conoce como subtipado conductual , más específicamente como el principio de sustitución de Liskov .

Sin embargo, esto a menudo no es cierto, especialmente en lenguajes de programación que permiten objetos mutables , es decir, objetos que cambian después de su creación. De hecho, el polimorfismo de subtipos, tal como lo aplica el verificador de tipos en los lenguajes de programación orientada a objetos (POO), no puede garantizar el subtipado de comportamiento en la mayoría de los contextos, si no en todos. Por ejemplo, el problema del círculo-elipse es notoriamente difícil de manejar utilizando el concepto de herencia de la POO. El subtipado de comportamiento es indecidible en general, por lo que no puede ser implementado fácilmente por un compilador. Debido a esto, los programadores deben diseñar cuidadosamente las jerarquías de clases para evitar errores que el propio lenguaje de programación no puede detectar.

Despacho dinámico

Un método puede invocarse mediante despacho dinámico, de modo que se selecciona en tiempo de ejecución en lugar de en tiempo de compilación. Si la elección del método depende de más de un tipo de objeto (como otros objetos pasados ​​como parámetros), se denomina despacho múltiple . En este contexto, una llamada a un método también se conoce como paso de mensajes , lo que significa que el nombre del método y sus entradas son como un mensaje enviado al objeto para que este actúe en consecuencia. [ 44 ]

El despacho dinámico funciona conjuntamente con la herencia: si un objeto no tiene el método solicitado, busca en su clase padre ( delegación ) y continúa ascendiendo en la cadena para encontrar un método que coincida.

Polimorfismo

El polimorfismo en la POO se refiere al subtipado o polimorfismo de subtipos, donde una función puede trabajar con una interfaz específica y, por lo tanto, manipular entidades de diferentes clases de manera uniforme. [ 45 ]

Por ejemplo, imagina que un programa tiene dos figuras: un círculo y un cuadrado. Ambas pertenecen a una clase común llamada "Shape". Cada figura se dibuja de forma independiente. Gracias al polimorfismo de subtipos, el programa no necesita conocer el tipo de cada figura y puede simplemente llamar al método "Draw" para cada una. El entorno de ejecución del lenguaje de programación se encargará de ejecutar la versión correcta del método "Draw" para cada figura. Dado que los detalles de cada figura se gestionan dentro de sus propias clases, el código resulta más sencillo y organizado, lo que permite una sólida separación de responsabilidades .

Recursión abierta

Los métodos de un objeto pueden acceder a sus datos. Muchos lenguajes de programación utilizan una palabra clave especial, como `<object>` thiso self`<object>`, para referirse al objeto actual. En lenguajes que admiten recursión abierta , un método de un objeto puede llamar a otros métodos del mismo objeto, incluido él mismo, utilizando esta palabra clave especial. Esto permite que un método de una clase llame a otro método definido posteriormente en una subclase, una característica conocida como enlace tardío .

Patrones de diseño

Los patrones de diseño son soluciones comunes a problemas en el diseño de software. Algunos patrones de diseño son especialmente útiles para la programación orientada a objetos (POO), y generalmente se introducen en un contexto de POO.

Modelado y relaciones del mundo real

A veces, los objetos representan cosas y procesos del mundo real en formato digital. [ 46 ] Por ejemplo, un programa de gráficos puede tener objetos como circle, square, y menu. Un sistema de compras en línea podría tener objetos como shopping cart, customer, y product. Niklaus Wirth dijo: «Este paradigma [POO] refleja fielmente la estructura de los sistemas del mundo real y, por lo tanto, es muy adecuado para modelar sistemas complejos con comportamiento complejo». [ 47 ]

Sin embargo, con mayor frecuencia, los objetos representan entidades abstractas, como un archivo abierto o un convertidor de unidades. No todos coinciden en que la POO facilite la copia exacta del mundo real, ni que hacerlo sea siquiera necesario. Bob Martin sugiere que, dado que las clases son software, sus relaciones no coinciden con las relaciones del mundo real que representan. [ 48 ] Bertrand Meyer argumenta que un programa no es un modelo del mundo, sino un modelo de alguna parte del mundo; "La realidad es un primo lejano". [ 49 ] Steve Yegge señaló que los lenguajes naturales carecen del enfoque de la POO de nombrar una cosa (objeto) antes de una acción (método), a diferencia de la programación funcional , que hace lo contrario. [ 50 ] Esto puede hacer que una solución de POO sea más compleja que una escrita mediante programación procedimental . [ 51 ]

Patrones de objetos

A continuación se presentan patrones de diseño de software notables para objetos de POO. [ 52 ]

Un antipatrón común es el objeto Dios , un objeto que sabe o hace demasiado.

Patrones de diseño del Grupo de los Cuatro

Patrones de diseño: Elementos de software orientado a objetos reutilizable es un libro famoso publicado en 1994 por cuatro autores: Erich Gamma , Richard Helm , Ralph Johnson y John Vlissides . A menudo se les conoce como el "Grupo de los Cuatro". El libro analiza las fortalezas y debilidades de la programación orientada a objetos (POO) y explica 23 maneras comunes de resolver problemas de programación.

Estas soluciones, denominadas "patrones de diseño", se agrupan en tres tipos:

Orientación a objetos y bases de datos

Tanto la programación orientada a objetos (POO) como los sistemas de gestión de bases de datos relacionales (SGBDR) se utilizan ampliamente en el software actual. Sin embargo, las bases de datos relacionales no almacenan objetos directamente, lo que supone un desafío al utilizarlas conjuntamente. Este problema se conoce como desajuste de impedancia objeto-relacional .

Para resolver este problema, los desarrolladores utilizan diferentes métodos, pero ninguno es perfecto. [ 53 ] Una de las soluciones más comunes es el mapeo objeto-relacional (ORM), que ayuda a conectar programas orientados a objetos con bases de datos relacionales. Algunos ejemplos de herramientas ORM son Visual FoxPro , Java Data Objects y Ruby on Rails ActiveRecord.

Algunas bases de datos, denominadas bases de datos orientadas a objetos , están diseñadas para funcionar con la programación orientada a objetos (POO). Sin embargo, no han alcanzado la popularidad ni el éxito de las bases de datos relacionales.

Date y Darwen han propuesto una base teórica que utiliza la POO como una especie de sistema de tipos personalizable para dar soporte a los SGBDR, pero prohíbe los objetos que contienen punteros a otros objetos. [ 54 ]

Diseño basado en la responsabilidad frente a diseño basado en datos

En el diseño orientado a la responsabilidad , las clases se construyen en función de lo que necesitan hacer y la información que comparten, en forma de contrato. Esto difiere del diseño orientado a los datos , donde las clases se construyen en función de los datos que necesitan almacenar. Según Wirfs-Brock y Wilkerson, los creadores del diseño orientado a la responsabilidad, este enfoque es el más adecuado. [ 55 ]

Directrices SOLID y GRASP

SOLID es un conjunto de cinco reglas para diseñar buen software, creadas por Michael Feathers:

GRASP (General Responsibility Assignment Software Patterns) es otro conjunto de reglas de diseño de software, creado por Craig Larman , que ayuda a los desarrolladores a asignar responsabilidades a diferentes partes de un programa: [ 56 ]

  • Principio del creador: permite que las clases creen objetos que utilizan de forma habitual.
  • Principio del experto en información: asigna tareas a las clases con la información necesaria.
  • Principio de bajo acoplamiento: reduce las dependencias entre clases para mejorar la flexibilidad y la mantenibilidad.
  • Principio de alta cohesión: diseñar clases con una única responsabilidad bien definida.
  • Principio de controlador: asigna las operaciones del sistema a clases separadas que gestionan el flujo y las interacciones.
  • Polimorfismo: permite utilizar diferentes clases a través de una interfaz común, lo que fomenta la flexibilidad y la reutilización.
  • Principio de fabricación pura: crear clases auxiliares para mejorar el diseño, aumentar la cohesión y reducir el acoplamiento.

semántica formal

Los investigadores han intentado definir formalmente la semántica de la POO. La herencia presenta dificultades, particularmente con las interacciones entre la recursión abierta y el estado encapsulado. Los investigadores han utilizado tipos recursivos y tipos de datos coalgebraicos para incorporar características esenciales de la POO. [ 57 ] Abadi y Cardelli definieron varias extensiones del Sistema F <: que manejan objetos mutables, permitiendo tanto el polimorfismo de subtipos como el polimorfismo paramétrico (genéricos), y pudieron modelar formalmente muchos conceptos y construcciones de la POO. [ 58 ] Aunque lejos de ser trivial, el análisis estático de lenguajes de programación orientados a objetos como Java es un campo maduro, [ 59 ] con varias herramientas comerciales. [ 60 ]

Popularidad y acogida

Gráfico del índice de popularidad de lenguajes de programación TIOBE desde 2002 hasta 2023. En la década de 2000, Java (naranja), orientado a objetos, y C (azul oscuro), procedimental , compitieron por el primer puesto.

Muchos lenguajes de programación populares, como C++, Java y Python, utilizan la POO. En el pasado, la POO era ampliamente aceptada, [ 61 ] pero recientemente, algunos programadores la han criticado y prefieren la programación funcional. [ 62 ] Un estudio de Potok et al. no encontró diferencias importantes en la productividad entre la POO y la programación procedimental. [ 63 ]

Algunos creen que la POO se centra demasiado en el uso de objetos en lugar de en algoritmos y estructuras de datos . [ 64 ] [ 65 ] Por ejemplo, el programador Rob Pike señaló que la POO puede hacer que los programadores piensen más en la jerarquía de tipos que en la composición. [ 66 ] La ha llamado "los números romanos de la computación". [ 67 ] Rich Hickey , creador de Clojure , describió la POO como demasiado simplista, especialmente cuando se trata de representar cosas del mundo real que cambian con el tiempo. [ 65 ] Alexander Stepanov dijo que la POO intenta encajar todo en un solo tipo, lo cual puede ser limitante. Argumentó que a veces necesitamos álgebras multisortadas: familias de interfaces que abarcan múltiples tipos, como en la programación genérica . Stepanov también dijo que llamar a todo "objeto" no añade mucha comprensión. [ 64 ]

La POO se creó para facilitar la reutilización y el mantenimiento del código . [ 68 ] Sin embargo, no se diseñó para mostrar claramente el flujo de las instrucciones de un programa. Esa tarea se dejó al compilador. A medida que las computadoras comenzaron a utilizar más procesamiento paralelo y múltiples hilos , se volvió más importante comprender y controlar cómo fluyen las instrucciones. Esto es difícil de lograr con la POO. [ 69 ] [ 70 ] [ 71 ] [ 72 ]

Paul Graham cree que a las grandes empresas les gusta la POO porque ayuda a gestionar grandes equipos de programadores promedio. Argumenta que la POO añade estructura, dificultando que una persona cometa errores graves, pero al mismo tiempo limita a los programadores más brillantes. [ 73 ] Eric S. Raymond , programador de Unix y defensor del software de código abierto , sostiene que la POO no es la mejor manera de escribir programas. [ 36 ]

Richard Feldman afirma que, si bien las características de la POO ayudaron a algunos lenguajes a mantenerse organizados, su popularidad se debe a otras razones. [ 74 ] Lawrence Krubner argumenta que la POO no ofrece ventajas especiales en comparación con otros estilos, como la programación funcional, y puede complicar la codificación. [ 75 ] Luca Cardelli afirma que la POO es más lenta y tarda más en compilarse que la programación procedimental. [ 34 ]

Véase también

Referencias

  1. 1 2 3 4 Kay, Dr. Alan (23 de julio de 2003). "El Dr. Alan Kay sobre el significado de la "programación orientada a objetos"" . Archivado del original el 4 de marzo de 2025 . Consultado el 11 de febrero de 2010 .
  2. ↑ Kindler, E.; Krivy, I. (2011). "Simulación orientada a objetos de sistemas con control sofisticado". International Journal of General Systems . 40 (3): 313– 343. doi : 10.1080/03081079.2010.539975 .
  3. ↑ Lewis, John; Loftus, William (2008). "1.6: Programación orientada a objetos". Java Software Solutions . Fundamentos del diseño de programación (6.ª ed.). Pearson Education Inc. ISBN  978-0-321-53205-3.
  4. ↑ Bloch 2018 , págs. xi–xii, Prólogo.
  5. ↑ McCarthy, J. ; Brayton, R.; Edwards, D.; Fox, P. ; Hodes, L. ; Luckham, D. ; Maling, K.; Park, D. ; Russell, S. (marzo de 1969). "Manual del programador de LISP I" (PDF) . Centro de Computación y Laboratorio de Investigación de Electrónica . Boston , Massachusetts : Grupo de Inteligencia Artificial, Centro de Computación y Laboratorio de Investigación del MIT: 88f. Archivado del original (PDF) el 17 de julio de 2010. En la jerga 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".
  6. ↑ McCarthy, John ; Abrahams , Paul W.; Edwards, Daniel J.; Hart, Swapnil D.; Levin, Michael I. (1962). LISP 1.5 Programmer's Manual . MIT Press . pág. 105. ISBN  978-0-262-13011-0. Objeto – sinónimo de símbolo atómico{{cite book}}: Incompatibilidad de ISBN/Fecha ( ayuda )
  7. ↑ Ivan E. Sutherland (mayo de 1963). Sketchpad: un sistema de comunicación gráfica hombre-máquina . AFIPS '63 (primavera): Actas de la Conferencia Conjunta de Informática de Primavera del 21 al 23 de mayo de 1963. AFIPS Press. págs. 329–346 . doi : 10.1145/1461551.1461591 . 
  8. 1 2 Nygaard, Kristen ; Dahl, Ole-Johan (1 de agosto de 1978). "El desarrollo de los lenguajes SIMULA" . ACM SIGPLAN Notices . 13 (8): 245– 272. doi : 10.1145/960118.808391 .
  9. ↑ Ross, Doug. "El primer lenguaje de ingeniería de software" . Cronología del Laboratorio LCS/AI . Laboratorio de Ciencias de la Computación e Inteligencia Artificial del MIT. Archivado del original el 12 de abril de 2011. Recuperado el 13 de mayo de 2010 .
  10. 1 2 Holmevik, Jan Rune (Invierno de 1994). "Compilando 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 . S2CID 18148999. Archivado del original (PDF) el 30 de agosto de 2017. Recuperado el 3 de marzo de 2018 . 
  11. ↑ Madsen, Ole Lehrman. "Kristen Nygaard" . Galardonado con el Premio Turing AM . Archivado del original el 1 de febrero de 2025. Consultado el 4 de febrero de 2025 .
  12. ↑ Butcher, Paul (30 de junio de 2014). Siete modelos de concurrencia en siete semanas: Cuando los hilos se desenredan . Pragmatic Bookshelf. pág. 204. ISBN  978-1-68050-466-8.
  13. ↑ Jones, Anita K.; Liskov, Barbara H. (abril de 1976). Un sistema de control de acceso para lenguajes de programación (PDF) (Informe técnico). MIT. CSG Memo 137. Archivado del original (PDF) el 26 de febrero de 2026.
  14. 1 2 Meyer, Bertrand (2009). Touch of Class: Learning to Program Well with Objects and Contracts . Springer Science & Business Media. p. 329. Bibcode : 2009tclp.book.....M . ISBN  978-3-540-92144-8.
  15. ↑ Kay, Alan (marzo de 1993). "La historia temprana de Smalltalk" . ACM SIGPLAN Notices . 28 (3): 69– 95. doi : 10.1145/155360.155364 .
  16. ↑ Borning, Alan Hamilton (1979). Thinglab: un laboratorio de simulación orientado a restricciones (PDF) (Informe). Universidad de Stanford.
  17. ↑ Moon, David A. (junio de 1986). «Programación orientada a objetos con variantes» (PDF) . Actas de la conferencia sobre sistemas, lenguajes y aplicaciones de programación orientada a objetos . OOPSLA '86. págs. 1–8 . doi : 10.1145/28697.28698 . ISBN  978-0-89791-204-4. S2CID 17150741 . Consultado el 17 de marzo de 2022 . 
  18. ↑ Hsu, Hansen (17 de diciembre de 2020). "Presentando el Smalltalk Zoo" . CHM . Recuperado el 27 de mayo de 2021 .{{cite news}}: CS1 mantenimiento: estado de la URL ( enlace )
  19. ↑ Bobrow, DG; Stefik, M. J (1982). LOOPS: programación orientada a datos y objetos para Interlisp (PDF) . Conferencia Europea de IA.
  20. ↑ Meyer 1997 .
  21. ↑ 1995 (junio) Visual FoxPro 3.0: FoxPro evoluciona de un lenguaje procedimental a un lenguaje orientado a objetos. Visual FoxPro 3.0 introduce un contenedor de base de datos, capacidades cliente/servidor sin interrupciones, compatibilidad con tecnologías ActiveX, automatización OLE y compatibilidad con valores nulos. Resumen de versiones de Fox
  22. ↑ Guía de revisión de Visual FoxPro 3.0 de 1995: DFpug.de
  23. ↑ Khurana, Rohit (1 de noviembre de 2009). Programación orientada a objetos con C++, 1.ª ed . Vikas Publishing House Pvt Limited. ISBN 978-81-259-2532-3.
  24. ↑ Deborah J. Armstrong. Los quarks del desarrollo orientado a objetos . Un estudio de casi 40 años de literatura informática identificó varios conceptos fundamentales presentes en la gran mayoría de las definiciones de POO, en orden descendente de popularidad: Herencia, Objeto, Clase, Encapsulación, Método, Paso de mensajes, Polimorfismo y Abstracción.
  25. ↑ John C. Mitchell , Conceptos en lenguajes de programación , Cambridge University Press, 2003, ISBN 0-521-78098-5, pág. 278. Listas: Despacho dinámico, abstracción, polimorfismo de subtipos y herencia.
  26. ↑ Michael Lee Scott, Pragmática del lenguaje de programación , 2.ª edición, Morgan Kaufmann, 2006, ISBN 0-12-633951-1, pág. 470. Listas: encapsulación, herencia y despacho dinámico.
  27. ↑ Pierce, Benjamin (2002). Tipos y lenguajes de programación . MIT Press. ISBN 978-0-262-16209-8.Sección 18.1 "¿Qué es la programación orientada a objetos?" Enumera: Despacho dinámico, encapsulación o multimétodos (despacho múltiple), polimorfismo de subtipos, herencia o delegación, recursión abierta ("this"/"self").
  28. ↑ CJ Date, Introducción a los sistemas de bases de datos, 6.ª ed., página 650
  29. ↑ McDonough, James E. (2017). «Encapsulación». Diseño orientado a objetos con ABAP: un enfoque práctico . Apress . doi : 10.1007/978-1-4842-2838-8 . ISBN 978-1-4842-2837-1– vía O'Reilly .
  30. ↑ Bloch 2018 , págs. 73–77, Capítulo §4 Punto 15 Minimizar la accesibilidad de las clases y los miembros.
  31. ↑ "¿Qué es la programación orientada a objetos (POO) en palabras sencillas? – Software Geek Bytes" . 5 de enero de 2023. Archivado del original el 17 de enero de 2023. Consultado el 17 de enero de 2023 .
  32. ↑ Cardelli, Luca; Wegner, Peter (10 de diciembre de 1985). "Sobre la comprensión de los tipos, la abstracción de datos y el polimorfismo" . ACM Computing Surveys . 17 (4): 471– 523. doi : 10.1145/6041.6042 . ISSN 0360-0300 . 
  33. ^ Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Ingeniería de Software Orientada a Objetos . Prensa Addison-Wesley ACM. págs. 43–69 . ISBN  978-0-201-54435-0.
  34. 1 2 3 Cardelli, Luca (1996). "Malas propiedades de ingeniería de los lenguajes orientados a objetos" . ACM Comput. Surv . 28 (4es): 150–es. doi : 10.1145/242224.242415 . ISSN 0360-0300 . S2CID 12105785. Archivado del original el 10 de mayo de 2010. Recuperado el 21 de abril de 2010 .  
  35. 1 2 Armstrong, Joe . Seibel, Peter (ed.). Coders at Work: Reflections on the Craft of Programming . Codersatwork.com. Archivado del original el 5 de marzo de 2010 . Recuperado el 13 de noviembre de 2009 .
  36. 1 2 3 Raymond, Eric S. (2003). "El arte de la programación Unix: Unix y los lenguajes orientados a objetos" . Archivado del original el 15 de septiembre de 2014. Recuperado el 6 de agosto de 2014 .
  37. ↑ Brodie, Leo (1984). Pensando hacia adelante (PDF) . págs. 92–93 . Recuperado el 4 de mayo de 2018 . 
  38. ↑ Hunt, Andrew. "No te repitas" . Categoría: Programación extrema . Archivado del original el 5 de mayo de 2018. Consultado el 4 de mayo de 2018 .
  39. ↑ Bloch 2018 , pág. 19, Capítulo §2 Punto 4 Imponer la no instanciabilidad con un constructor privado.
  40. ↑ Dony, C; Malenfant, J; Bardon, D (1999). "Clasificación de lenguajes de programación basados ​​en prototipos" (PDF) . Programación basada en prototipos: conceptos, lenguajes y aplicaciones . Singapur Berlín Heidelberg: Springer. ISBN 9789814021258.
  41. ↑ "¿Es Go un lenguaje orientado a objetos?" . Archivado del original el 13 de abril de 2019 . Recuperado el 13 de abril de 2019 . Aunque Go tiene tipos y métodos y permite un estilo de programación orientado a objetos, no existe una jerarquía de tipos.
  42. ↑ Stroustrup, Bjarne (2015). Programación orientada a objetos sin herencia (Charla invitada) . 29.ª Conferencia Europea sobre Programación Orientada a Objetos (ECOOP 2015). 1:34. doi : 10.4230/LIPIcs.ECOOP.2015.1 .
  43. ↑ Pike, Rob (14 de noviembre de 2012). "Hace unos años vi esta página" . Archivado del original el 14 de agosto de 2018. Recuperado el 1 de octubre de 2016 .
  44. ↑ Naik, Mayur; Kumar, Rajeev (marzo de 2000). "Envío eficiente de mensajes en sistemas orientados a objetos". ACM SIGPLAN Notices . 35 (3): 49– 58. doi : 10.1145/351159.351174 .
  45. ↑ Stroustrup, Bjarne (19 de febrero de 2007). "Glosario de C++ de Bjarne Stroustrup" . www.stroustrup.com . Archivado del original el 20 de julio de 2012. Recuperado el 9 de junio de 2011. Polimorfismo: proporcionar una única interfaz a entidades de diferentes tipos.
  46. ↑ Booch, Grady (1986). Ingeniería de software con Ada . Addison Wesley. pág. 220. ISBN  978-0-8053-0608-8Quizás la mayor fortaleza de un enfoque de desarrollo orientado a objetos radica en que ofrece un mecanismo que captura un modelo del mundo real.
  47. ↑ Wirth, Niklaus (23 de enero de 2006). "Buenas ideas, a través del espejo" (PDF) . IEEE Computer . Artículo de portada. 39 (1): 28–39 . Bibcode : 2006Compr..39a..28W . doi : 10.1109/MC.2006.20 . S2CID 6582369. Archivado del original (PDF) el 12 de octubre de 2016. 
  48. ↑ "Principios sólidos del tío Bob" . YouTube . 2 de agosto de 2018.
  49. ↑ Meyer 1997 , pág. 230.
  50. ↑ 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 .
  51. ↑ Boronczyk, Timothy (11 de junio de 2009). "¿Qué tiene de malo la POO?" . zaemis.blogspot.com . Consultado el 3 de julio de 2010 .
  52. ↑ Martin, Robert C. "Principios de diseño y patrones de diseño" (PDF) . Archivado del original (PDF) el 6 de septiembre de 2015. Recuperado el 28 de abril de 2017 .
  53. ↑ Neward, Ted (26 de junio de 2006). "El Vietnam de la informática" . Interoperability Happens. Archivado del original el 4 de julio de 2006. Recuperado el 2 de junio de 2010 .
  54. ↑ CJ Date, Hugh Darwen. Fundación para los sistemas de bases de datos del futuro: El tercer manifiesto (2.ª edición)
  55. ↑ Wirfs-Brock, Rebecca; Wilkerson, Brian (1989). "Diseño orientado a objetos: un enfoque basado en la responsabilidad" . ACM SIGPLAN Notices . 24 (10): 74. doi : 10.1145/74878.74885 .
  56. ↑ Karsh, Patrick (19 de julio de 2023). "Principios GRASP: Patrones de diseño orientados a objetos" . Medium . Consultado el 30 de marzo de 2025 .
  57. ↑ Poll, Erik. "Subtipado y herencia para tipos de datos categóricos" (PDF) . Consultado el 5 de junio de 2011 .
  58. ^ Abadi, Martín ; Cardelli, Luca (1996). Una teoría de los objetos . Springer-Verlag Nueva York, Inc. ISBN 978-0-387-94775-4Consultado el 21 de abril de 2010 .
  59. ↑ Tan, Tian; Li, Yue (12 de julio de 2023). Tai-e: Un marco de análisis estático amigable para desarrolladores para Java que aprovecha los buenos diseños de los clásicos . ISSTA 2023. págs. 1093–1105 . doi : 10.1145/3597926.3598120 . 
  60. ↑ Bhutani, Vikram; Toosi, Farshad Ghassemi; Buckley, Jim (1 de junio de 2024). "Analizando a los analizadores: una investigación de las herramientas de análisis de código fuente". Applied Computer Systems . 29 (1): 98–111 . doi : 10.2478/acss-2024-0013 .
  61. ↑ Brucker, Achim D.; Wolff, Burkhart (2008). «Universos extensibles para modelos de datos orientados a objetos». ECOOP 2008 – Programación orientada a objetos . Lecture Notes in Computer Science. Vol. 5142. pp. 438–462 . doi : 10.1007/978-3-540-70592-5_19 . ISBN   978-3-540-70591-8La programación orientada a objetos es un paradigma de programación ampliamente aceptado .
  62. ↑ Cassel, David (21 de agosto de 2019). "¿Por qué tantos desarrolladores odian la programación orientada a objetos?" . The New Stack .
  63. ↑ Potok, Thomas; Vouk, Mladen; Rindos, Andy (1999). "Análisis de productividad del software orientado a objetos desarrollado en un entorno comercial" (PDF) . Software: Practice and Experience . 29 (10): 833– 847. doi : 10.1002/(SICI)1097-024X(199908)29:10 < 833::AID-SPE258 > 3.0.CO ; 2-P . S2CID 57865731. Recuperado el 21 de abril de 2010 . 
  64. 1 2 Stepanov, Alexander (2001–2008). "STLport: Una entrevista con A. Stepanov" . Recuperado el 21 de abril de 2010 .
  65. 1 2 Hickey, Rich (noviembre de 2009). ¿ Ya llegamos? (conferencia magistral) . Cumbre de lenguajes JVM.
  66. ↑ Pike, Rob (25 de junio de 2012). "Menos es exponencialmente más" . Recuperado el 1 de octubre de 2016 .
  67. ↑ Pike, Rob (2 de marzo de 2004). " [ 9fans ] Re: Hilos: Coser insignias de honor en un núcleo" . comp.os.plan9 (Lista de correo) . Recuperado el 17 de noviembre de 2016 .
  68. ↑ Ambler, Scott (1 de enero de 1998). "Una mirada realista a la reutilización orientada a objetos" . drdobbs.com . Consultado el 5 de agosto de 2025 .
  69. ↑ Shelly, Asaf (22 de agosto de 2008). "Defectos del modelado orientado a objetos" . Intel Software Network . Recuperado el 4 de julio de 2010 .
  70. ↑ James, Justin (1 de octubre de 2007). "Multithreading es un verbo, no un sustantivo" . techrepublic.com. Archivado del original el 10 de octubre de 2007. Recuperado el 4 de julio de 2010 .
  71. ↑ Shelly, Asaf (22 de agosto de 2008). "CÓMO: Programación multinúcleo (multiprocesamiento) Directrices de diseño de clases de Visual C++, funciones miembro" . support.microsoft.com . Consultado el 4 de julio de 2010 .
  72. ↑ Harper, Robert (17 de abril de 2011). "Algunas reflexiones sobre la enseñanza de FP" . Blog Existential Type. Archivado del original el 6 de noviembre de 2011. Recuperado el 5 de diciembre de 2011 .
  73. ↑ Graham, Paul . "Por qué ARC no es especialmente orientado a objetos" . PaulGraham.com. Archivado del original el 24 de noviembre de 2009. Consultado el 13 de noviembre de 2009 .
  74. ↑ Feldman, Richard (30 de septiembre de 2019). "¿Por qué la programación funcional no es la norma?" . YouTube . Archivado del original el 22 de agosto de 2022.
  75. ↑ Krubner, Lawrence. "La programación orientada a objetos es un desastre costoso que debe terminar" . smashcompany.com. Archivado del original el 14 de octubre de 2014. Recuperado el 14 de octubre de 2014 .

Lecturas adicionales

  • Abadi, Martín ; 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-2Archivado del original el 26 de diciembre de 2017. Consultado el 22 de enero de 2006 .
  • Armstrong, Deborah J. (febrero de 2006). "Los quarks del desarrollo orientado a objetos". Communications of the ACM . 49 (2): 123– 128. doi : 10.1145/1113034.1113040 . ISSN 0001-0782 . S2CID 11485502 .  
  • Bloch, Joshua (2018). «Java eficaz: Guía del lenguaje de programación» (tercera  ed.). Addison-Wesley. ISBN 978-0134685991.
  • 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). Building Business Objects . John Wiley & Sons . 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 reutilizable . Addison-Wesley. Bibcode : 1995dper.book.....G . ISBN 978-0-201-63361-0.
  • Harmon, Paul ; William Morrissey (1996). The Object Technology Casebook – Lessons from Award-Winning Business Applications . John Wiley & Sons. 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 del Smalltalk . Archivado del original el 4 de abril de 2005. Recuperado 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). OOP – Aprende pensamiento y programación orientados a objetos . Bruckner Publishing. ISBN 978-80-904661-8-0.
  • Rumbaugh, James ; Blaha, Michael; Premerlani, William; Eddy, Frederick; Lorensen, William (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 & Sons. 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). Object Thinking (Referencia para desarrolladores) . Microsoft Press . ISBN 978-0-7356-1965-4.
  • Introducción a los conceptos de programación orientada a objetos (POO) y más, por LWC Nirosh
  • Discusión sobre las desventajas de la programación orientada a objetos.
  • Conceptos de POO (Tutoriales de Java)
Lecturas relacionadas
6 articulos
Lenguaje de modelado unificadoLenguaje de modelado unificadoEl lenguaje de modelado unificado ( UML ) es un lenguaje de modelado visual de propósito general que tiene como objetivo proporcionar una forma est...Variable (informática)Variable (informática)En programación informática , una variable es una ubicación de almacenamiento abstracta emparejada con un nombre simbólico asociado , que contiene ...Método (programación informática)Método (programación informática)Un método en programación orientada a objetos (POO) es un procedimiento asociado a un objeto y, generalmente, también a un mensaje . Un objeto cons...Paradigma de programaciónParadigma de programaciónUn paradigma de programación es una forma relativamente de alto nivel de conceptualizar y estructurar la implementación de un programa informático ...Objeto (informática)Objeto (informática)En informática , un objeto es una entidad con un comportamiento bien definido. [1] : 38SoftwareSoftwareEl software consiste en programas informáticos que dan instrucciones sobre la ejecución de una computadora . [1] El software puede definirse de man...