Quali erano le condizioni storiche che hanno portato alla programmazione orientata agli oggetti diventando un importante paradigma di programmazione?

Risposta breve

Penso che sia stata la zangata dei progetti software prima dei giorni OO. OO ha aiutato aggiungendo il concetto fondamentalmente critico - Modella il mondo reale .

Il primo linguaggio di programmazione orientato agli oggetti era Simula nel lontano 1967. Tuttavia, a quel tempo lo sviluppo del software in generale era ancora nei laboratori più e la maggior parte dei paradigmi era ancora più vicino al caso di hardware .

Nel corso di un altro decennio di sviluppo di software per applicazioni aziendali, altre applicazioni commerciali sono cresciute e lo sviluppo del software in generale è cresciuto negli anni '70. Le lingue che sopravvivono ancora oggi di quegli anni (prima del 1980) erano C, Cobol, Fortran e simili. La maggior parte di queste lingue è procedurale. Il Lisp esiste anche da quel giorno - tuttavia, non sono sicuro che si trattasse di un linguaggio generico di primo piano per lo sviluppo commerciale. Il famoso termine Modello di cascata è stato coniato anche nei primi anni '70.

Nella maggior parte degli ambienti commerciali, l'elemento più importante che emerge nello sviluppo del software è stata la gestione dei progetti. C'era un disperato bisogno di budget ristretti e almeno prevedibili e la gestione dei requisiti da congelare per garantire che il progetto raggiungesse il traguardo in modo rispettabile. Durante questo periodo è stato anche uno dei Mythical Manmonths nel 1975.

Immagino che alla fine degli anni '70 la gente fosse bruciata, poiché i linguaggi procedurali non mantenevano le promesse. E un nuovo paradigma Object oriented che esisteva da quel momento ha reso grande. Anche se le persone potrebbero non essere d'accordo, penso che il C ++ che aiuta familiarità e comprovata esperienza e di C, e l'orientamento Promise of Object (originariamente con il nome C with Classes) nel 1983 era una pietra angolare per il successo della programmazione orientata agli oggetti. / p>

Alcuni riferimenti per più prospettiva - link

Allora perché OO?

Penso che quei giorni (se guardi al punto di vista del successo del progetto) - aveva senso che ciò che puoi capire meglio sia gestibile meglio. La metodologia orientata agli oggetti con una promessa "... tutto nella vita è un oggetto" sembrava più come un buon senso anche prima che si dimostrasse significativo. Il successo pratico di questo fattore è stata la nozione stessa di model sufficientemente il mondo reale e il problema a portata di mano prima di saltare la pistola - che penso qualcosa di fondamentalmente nuovo che OO ha offerto che nessun altro paradigma ha offerto fino a quella data . E sicuramente visto che questo paradigma ti ha costretto a pensare un po ' prima di codificare più di linguaggi procedurali, ha mostrato un successo visibile sui progetti software che hanno impiegato e da allora hanno preso piede!

Modifica
Vorrei anche aggiungere che i linguaggi di programmazione si sono evoluti simultaneamente in parallelo a concetti fondamentali (paradigma OO, Aspetto, macchine virtuali). Ogni nuovo concetto e nuovo modo di pensare è emerso solo quando un nuovo linguaggio di programmazione lo ha padroneggiato - conserva solo familiarità ma cambia i fondamentali dal nucleo ! Allo stesso tempo, questi nuovi concetti e nuovi linguaggi sono emersi solo a causa di nuovi problemi di business. Anni '80 - OO per software su larga scala, 1990 Java in età Internet, PHP / ASP e molti altri per il web. Anche l'innovazione nei linguaggi di programmazione è stata guidata principalmente da esigenze di mercato discontinue.

In sintesi, i primi anni '80 erano l'epoca in cui decollava il software commerciale su larga scala, mentre i progetti con linguaggi procedurali avevano i loro problemi, OO mostrava la luce migliore e rendeva i progetti più efficaci.

Penso che la ragione principale sia stata il successo delle interfacce utente grafiche come X e Windows. Una GUI è composta da diversi oggetti che hanno un comportamento autonomo, qualcosa che OO è in grado di rappresentare da vicino.

D'altra parte, un'interfaccia utente basata su testo (che non tenta di assomigliare a una GUI) spesso segue semplicemente uno schema di comando-risposta, che può essere facilmente implementato in un linguaggio procedurale. Le regole aziendali e cose simili sono state implementate con linguaggi procedurali per decenni, senza troppi problemi, e ancora oggi molti programmi OO per applicazioni aziendali sono piuttosto procedurali; con oggetti stupidi che contengono i dati e gli oggetti stateless che contengono le regole aziendali; il primo potrebbe essere un record in un linguaggio procedurale, più tardi potrebbero essere, beh, le procedure.

Vedo OOP come un passo evolutivo naturale dal codice procedurale:

1. Codice procedurale: dì alla macchina di fare A, poi digli di fare B.
2. OOP: impacchetta le istruzioni procedurali in blocchi molto riutilizzabili, definendo interfacce / input / output. (Attenzione: semplificazione.)

Sono sicuro che qualcuno con una visione più ampia interverrà, ma sembra che questa sia stata una progressione naturale semplicemente consentendo ai programmatori di produrre codice più velocemente: cioè consentire un maggiore riutilizzo del codice.

In questa prospettiva, il fattore esterno più grande è stato il costo ridotto della potenza del processore (rispetto al costo del lavoro degli sviluppatori per creare programmi tipici): il sovraccarico nell'utilizzo delle classi OOP è diventato meno preoccupante dei risparmi di tempo degli sviluppatori. (Questo stesso compromesso tra spesa della CPU e spesa del programmatore ha influenzato molti altri aspetti della programmazione.)

All'inizio esisteva una programmazione imperativa (se si potesse chiamarla così). Istruzioni semplici che dicevano al mainframe cosa e come dovrebbe essere calcolato. Quei linguaggi di programmazione usavano salti incondizionati e altre istruzioni "non strutturate", molte delle quali esotiche per gli standard odierni.

Poi qualcuno ha inventato strutture per la programmazione. Il for, while, do while e foreach lo conosciamo oggi. È stata una grande innovazione poiché ora applicazioni con flussi relativamente complessi potrebbero essere scritte e comprese facilmente. Così è nata la programmazione strutturata.

Poi sono arrivate altre persone che dicevano che era necessario ripetere un sacco di codice qua e là ed era un incubo mantenere così un modo di riutilizzare il codice da inventare. Le persone hanno escogitato procedure e funzioni per delimitare bit di codice riutilizzabili. Ciò ha dato origine anche ai principi di incapsulamento e responsabilità individuale.

Poi alcuni studiosi hanno affermato che la funzionalità dovrebbe essere strettamente collegata ai dati su cui sta lavorando. Poi hanno aggiunto i concetti di ereditarietà per il riutilizzo del codice e il polimorfismo per adeguarsi al modo logico in cui la classificazione ha funzionato nella vita reale. Così sono nati i linguaggi di programmazione di terza generazione e OOP.