¿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?

Respuesta corta

Creo que fue la pérdida de proyectos de software antes de los días de OO. OO ayudó al agregar 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 era aún en los laboratorios más y la mayoría de los paradigmas aún estaban más cerca del caso de hardware .

Durante una década completa, el desarrollo de software para aplicaciones empresariales creció, otras aplicaciones comerciales crecieron y el desarrollo de software en general se recuperó a lo largo de toda la década de 1970. Los idiomas que aún sobreviven hoy en día de esa edad (antes de 1980) fueron C, Cobol, Fortran y otros similares. La mayoría de estos idiomas son de procedimiento. Lisp también existió desde ese día; sin embargo, no estoy seguro de si ese fue un lenguaje de uso general prominente para el desarrollo comercial. El famoso término Waterfall model también se acuñó a principios de la década de 1970.

En la mayoría de los entornos comerciales, el elemento más importante que surgió en el desarrollo de software fue la gestión de proyectos. Había 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 Manthths míticos en 1975.

Supongo que a finales de los años 70 la gente se quemó, ya que los lenguajes de procedimiento no cumplieron esas promesas. Y un nuevo paradigma orientado a objetos que existió desde ese momento lo hizo grande. Aunque la gente podría estar en desacuerdo, creo que el C ++ que ayuda a la familiaridad y la experiencia comprobada y de C, y la Promesa de Orientación al Objeto (originalmente con el nombre C con Clases) en 1983 fue una piedra angular para el éxito de la programación orientada a Objetos. / p>

Algunas referencias para obtener más perspectiva - enlace

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 se puede entender mejor se pueda manejar mejor. La metodología orientada a objetos con una promesa "... todo en la vida es un objeto" parecía más sentido común incluso antes de que se probara que era significativo. El éxito práctico de este factor fue la noción de modelar el mundo real y el problema actual antes de saltar el arma, lo cual creo que es algo completamente nuevo que OO ofreció y que ningún otro paradigma ofreció hasta esa fecha. . Y, definitivamente, dado que este paradigma lo forzó a pensar antes de codificar más que los lenguajes de procedimiento, mostró un éxito visible en los proyectos de software que se emplearon y ¡desde entonces se dieron cuenta!

EDIT
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 nuevo pensamiento surgieron solo cuando un nuevo lenguaje de programación lo dominó: mantenga la familiaridad pero cambie los fundamentos desde el núcleo ! Al mismo tiempo, este nuevo concepto y nuevos idiomas solo surgieron debido a nuevos problemas de negocios. Década de 1980: OO para software a gran escala, Java 1990 en la era de Internet, PHP / ASP y muchos otros para la web. La innovación en los lenguajes de programación también fue impulsada principalmente por la necesidad discontinua del mercado.

En resumen, a principios de los 80 'fue la época en que despegó el software comercial a gran escala. Mientras que los proyectos con lenguajes de procedimiento tuvieron sus problemas, OO mostró la mejor luz e hizo que los proyectos tuvieran más éxito.

Creo que la razón principal fue el éxito de las interfaces gráficas de usuario como X y Windows. Una GUI consiste en varios objetos que tienen un comportamiento por sí mismos, algo que OO puede representar de cerca.

Por otro lado, una interfaz de usuario basada en texto (que no trata de parecerse a una GUI) a menudo simplemente sigue un patrón de comando-respuesta, 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 OO para aplicaciones de negocios son más bien de procedimiento; con objetos estúpidos que contienen los datos y objetos sin estado que contienen las reglas de negocios; el primero podría ser registros en un lenguaje procedimental, el último podría ser, bueno, procedimientos.

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

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

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

En esta 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 la mano de obra del desarrollador para crear programas típicos): la sobrecarga de cómputo al usar clases de POO se convirtió en una preocupación menor que el ahorro de tiempo del desarrollador. (Este mismo compromiso entre el gasto de la CPU y el gasto del programador ha influido en muchos otros aspectos de la programación).

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

Entonces alguien ideó estructuras para la programación. El para, mientras, hacer y para cada uno sabemos hoy. Fue una gran innovación ya que ahora las aplicaciones con un flujo relativamente complejo se pueden escribir y entender fácilmente. Así nació la programación estructurada.

Luego vinieron otras personas que dijeron que necesitabas repetir muchos códigos aquí y allá, y era una pesadilla mantenerlos, por lo que se debería inventar una forma de reutilizar el código. A la gente se le ocurrieron procedimientos y funciones para delimitar fragmentos 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 coincidan con la forma lógica en que funcionaba la clasificación en la vida real. Así nació la tercera generación de lenguajes de programación y OOP.