¿Cuáles fueron las condiciones históricas que llevaron a que la programación orientada a objetos se convirtiera en un paradigma de programación importante?


14

¿Cuáles fueron algunos de los factores económicos (y otros factores históricos) que llevaron a que los lenguajes de programación orientados a objetos se volvieran influyentes? Sé que Simula comenzó las cosas, pero ¿fue la adopción de lenguajes OOP debido a las necesidades cada vez mayores de las empresas? ¿O la adopción se debió más a las nuevas cosas que se podían hacer con los lenguajes OOP?

Editar Estoy realmente interesado en saber si hubo algunos factores externos a los propios idiomas que les permitieron establecerse.


Eso tiene sentido, pero creo que estaba más interesado en las circunstancias externas que ocurrían durante el desarrollo. Bien podría ser que los factores externos tuvieran un efecto limitado.

Le garantizo que incluso para preguntas relacionadas con factores externos, programmers.stackexchange es un mejor lugar. Tiene un montón de personas que trabajan activamente en la industria y muchas que han estado trabajando desde que la industria despegó. Es mucho más probable que encuentre una persona allí que tenga una excelente respuesta a su pregunta que aquí.
Optar el

2
Smalltalk no comenzó. Simula creó los conceptos básicos de orientación a objetos. Lo que hizo Smalltalk fue tomar esas ideas y convertirlas en un modelo muy diferente y apropiarse del nombre. Pero vale la pena señalar que ningún lenguaje que sigue el modelo Smalltalk de OO ha tenido realmente mucho éxito en la creación de programas. (Con la excepción de Objective-C, que es un caso especial: Apple lo empuja por el cuello de todos, pero nadie fuera del ecosistema de Apple lo usa). Todos los lenguajes OO exitosos: C ++, Delphi, Java, C #, etc, use el modelo Simula.
Mason Wheeler

1
Los ladrillos de juguete Lego podrían encajar como una influencia externa ...
Jamie F

1
@Mason: no estoy seguro de qué divide los modelos Simula y Smalltalk. ¿Dónde pondrías a Ruby? LUA? ¿Pitón? Javascript?
Kevin Cline

Respuestas:


10

Respuesta corta

Creo que fue la rotación de proyectos de software antes de los días de OO. OO ayudó agregando el concepto fundamentalmente crítico: modelar el mundo real .


El primer lenguaje de programación orientado a objetos fue Simula en 1967. Sin embargo, en ese momento el desarrollo de software en general todavía estaba en los laboratorios y la mayoría de los paradigmas aún estaban más cerca del caso del hardware .

Durante una década más, el desarrollo de software para aplicaciones empresariales creció en otras aplicaciones comerciales y el desarrollo de software en general se recuperó durante toda la década de 1970. Las lenguas que aún sobreviven hoy en día (antes de 1980) fueron C, Cobol, Fortran y otras similares. La mayoría de estos idiomas son de procedimiento. Lisp también existió desde ese día, sin embargo, no estoy seguro si ese fue un lenguaje prominente de propósito general para el desarrollo comercial. El famoso término Modelo de cascada también fue acuñado a principios de la década de 1970.

En la mayoría del entorno comercial, el elemento más importante que surgió en el desarrollo de software fue la gestión de proyectos. Hubo una gran necesidad de presupuestos ajustados y al menos predecibles y requisitos de gestión para congelar para garantizar que el proyecto llegue a la meta de manera respetable. Durante este período también fue uno de los Manmonios Míticos en 1975.

Supongo que a finales de los años 70 la gente estaba agotada, ya que los lenguajes de procedimiento no cumplían con esas promesas. Y un nuevo paradigma orientado a objetos que existió desde entonces lo hizo grande. Aunque la gente puede estar en desacuerdo, creo que el C ++ que ayuda a la familiaridad y la experiencia comprobada y de C, y la orientación Promesa de Objeto (originalmente con el nombre C con Clases) en 1983 fue una piedra angular para el éxito de la programación orientada a objetos.

Alguna referencia para más perspectiva: http://journal.thedacs.com/issue/43/88

Entonces, ¿por qué OO?

Creo que esos días (si nos fijamos en el punto de vista del éxito del proyecto), tenía sentido que lo que puede entender mejor sea mejor manejable. La metodología orientada a objetos con una promesa "... todo en la vida es un objeto" parecía más un sentido común incluso antes de que se demostrara que era significativo. El éxito práctico de este factor fue la noción misma de modelar suficientemente el mundo real y el problema en cuestión antes de saltar el arma, lo que creo que es algo fundamentalmente nuevo que OO ofreció y que ningún otro paradigma ofreció hasta esa fecha. Y definitivamente dado que este paradigma te obligó a pensar un poco antes de codificar más que los lenguajes de procedimiento, ¡mostró un éxito visible en los proyectos de software que emplearon y desde entonces se dieron cuenta!

EDITAR
También agregaría que los lenguajes de programación evolucionaron simultáneamente en paralelo a tales conceptos fundamentales (paradigma OO, Aspecto, Máquinas virtuales,) Cada nuevo concepto y pensamiento nuevo surgieron solo cuando un nuevo lenguaje de programación nuevo lo dominó: mantén solo la familiaridad pero cambia los fundamentos de ¡núcleo! Al mismo tiempo, estos nuevos conceptos y nuevos lenguajes solo surgieron debido a nuevos problemas comerciales. 1980 - OO para software a gran escala, 1990 Java en la era de Internet, PHP / ASP y muchos otros para la web. La innovación en los lenguajes de programación también se debió principalmente a la necesidad discontinua del mercado.

En resumen, a principios de los años 80, la era en la que despegaba el software comercial a gran escala, mientras que los proyectos con lenguajes de procedimiento tenían sus problemas, OO mostró la mejor luz e hizo que los proyectos fueran más exitosos.


¿Cuáles fueron las características del turno y hacia dónde ir? Finales de los 70. ¿Qué desarrolladores entienden que es hora de irse? ¿Cansado de procedimientos, sí, pero debe haber un montón de alternativas?
Independiente

@Jonas - ok - modificó la respuesta.
Dipan Mehta

En cuanto al éxito histórico que estamos evaluando, definitivamente podemos decir que la familiaridad juega algún papel. C (fue el sucesor de B), C ++ fue una mejor C a pesar de que OO supuestamente fue un cambio de paradigma. Incluso Java estaba listo para saltar de C ++ (que era más como C ++ sin problemas de C ++, por ejemplo, memoria y portabilidad). La mayoría de estos lenguajes cruzaron los abismos al adquirir el espacio existente de manera más efectiva a pesar de que tenían algo más fundamental en ellos. Más aún, porque cada lenguaje adquirirá algunos programadores que ya conocen otros lenguajes de programación. ¡PERO esto puede no ser siempre cierto!
Dipan Mehta

1
También agregaría que los lenguajes de programación evolucionaron simultáneamente en paralelo a tales conceptos fundamentales (paradigma OO, Aspecto, Máquinas virtuales,) Cada nuevo concepto y pensamiento nuevo surgieron solo cuando un nuevo lenguaje de programación nuevo lo dominó: mantener solo la familiaridad pero cambiar los fundamentos del núcleo ! Al mismo tiempo, estos nuevos conceptos y nuevos lenguajes solo surgieron debido a nuevos problemas comerciales. 1980's - OO para software a gran escala, 1990 Java en la era de internet, PHP / ASP y muchos otros para la web. La innovación en los lenguajes de programación también se debió principalmente a la necesidad discontinua del mercado.
Dipan Mehta

1
"Modelar el mundo real" parece concluyente, pero en la mayoría de los casos, no sucede. La Customerclase no tiene métodos como eatLunch, goToWorko sleep, aunque esto es lo que hacen los clientes en el mundo real . La Productclase tiene varios métodos, aunque la mayoría de los productos no tienen exactamente ningún comportamiento en el mundo real . Por lo tanto, diría que el modelo OO solo corresponde (más o menos) en términos de propiedades, pero no en términos de comportamiento, con el mundo real. Pero no necesita OO para tener un modelo de datos que corresponda a objetos del mundo real. Grabar tipos es todo lo que se necesita.
user281377

6

Creo que la razón más importante fue el éxito de las interfaces gráficas de usuario como X y Windows. Una GUI consta de varios objetos que tienen un comportamiento propio, algo que OO puede representar de cerca.

Por otro lado, una interfaz de usuario basada en texto (que no intenta parecerse a una GUI) a menudo simplemente sigue un patrón de respuesta de comando, que puede implementarse fácilmente en un lenguaje de procedimiento. Las reglas de negocios y cosas similares se han implementado con lenguajes de procedimiento durante décadas, sin demasiados problemas, y aún hoy en día muchos programas de OO para aplicaciones de negocios son bastante procesales; con objetos estúpidos que contienen los datos y objetos sin estado que contienen las reglas de negocio; el primero podría ser registros en un lenguaje de procedimiento, el segundo podría ser, bueno, procedimientos.


4

Veo OOP como un paso evolutivo natural del código de procedimiento:

  1. Código de procedimiento: dígale a la máquina que haga A, luego dígale que haga B.
  2. OOP: Empaquete las instrucciones de procedimiento en fragmentos muy reutilizables, definiendo interfaces / entradas / salidas. (Advertencia: simplificación).

Estoy seguro de que alguien con una visión más amplia intervendrá, pero parece que esta fue una progresión natural al permitir que los programadores produzcan código más rápido: es decir, permitir una mayor reutilización del código.

Desde este punto de vista, el factor externo más importante fue la reducción del costo de la potencia del procesador (en comparación con el costo de mano de obra del desarrollador para crear programas típicos): la sobrecarga informática en el uso de las clases OOP se convirtió en una preocupación menor que el ahorro de tiempo del desarrollador. (Esta misma compensación de gasto de CPU versus gasto de programador ha influido en muchos otros aspectos de la programación).


2

Al principio había una programación imperativa (si pudieras llamarlo así). Instrucciones simples que le dijeron al mainframe qué y cómo debería estar calculando. Esos lenguajes de programación usaban saltos incondicionales y otras instrucciones "no estructuradas", la mayoría de ellas exóticas para los estándares actuales.

Entonces a alguien se le ocurrieron estructuras para la programación. El for, while, do while y foreach que conocemos hoy. Fue una gran innovación ya que ahora las aplicaciones con un flujo relativamente complejo podían escribirse y entenderse fácilmente. Así nació la programación estructurada.

Luego vinieron otras personas que dijeron que necesitabas repetir un montón de código aquí y allá y que era una pesadilla mantenerlo, por lo que debería inventarse una forma de reutilizar el código. A la gente se le ocurrieron procedimientos y funciones para delimitar bits de código reutilizables. Esto también dio origen a los principios de encapsulación y responsabilidad única.

Luego, algunos académicos dijeron que la funcionalidad debería estar estrechamente relacionada con los datos en los que está trabajando. Luego agregaron los conceptos de herencia para la reutilización de código y el polimorfismo para que coincida con la forma lógica en que funcionó la clasificación en la vida real. Así nació la tercera generación de lenguajes de programación y OOP.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.