Quelles ont été les conditions historiques qui ont conduit la programmation orientée objet à devenir un paradigme de programmation majeur?

Quels étaient certains des facteurs économiques (et autres facteurs historiques) qui ont conduit les langages de programmation orientés objet à devenir influents? Je sais que Simula a commencé les choses, mais est-ce que l'adoption des langages POO est due aux besoins toujours croissants des entreprises? Ou bien, l'adoption était-elle due davantage aux nouvelles choses qui pouvaient être faites avec les langages POO?

Modifier Je suis vraiment très intéressé à savoir s'il y avait des facteurs externes aux langues elles-mêmes qui leur permettaient de s'implanter.

Réponse courte

Je pense que c'était le roulement des projets logiciels avant les jours OO. OO a aidé en ajoutant le concept fondamentalement critique - Modéliser le monde réel .

Le premier langage de programmation orienté objet était Simula depuis 1967. Cependant, à cette époque, le développement de logiciels en général était encore plus dans les laboratoires et la plupart des paradigmes étaient encore plus proches du boîtier matériel .

Au cours d'une autre décennie, le développement de logiciels pour les applications d'entreprise s'est développé et d'autres applications commerciales se sont développées et le développement de logiciels dans son ensemble s'est accéléré au cours des années 1970. Les langues qui survivent encore aujourd'hui de cet âge (avant 1980) étaient le C, le Cobol, le Fortran et d'autres similaires. La plupart de ces langues sont procédurales. Lisp a également existé depuis ce jour - cependant, je ne sais pas si c'était un langage à usage général prédominant pour le développement commercial. Le célèbre modèle Waterfall terme a également été inventé au début des années 1970.

Dans la plupart des environnements commerciaux, l'élément le plus important qui se dégage du développement logiciel est la gestion de projet. Il y avait un besoin urgent de budgets serrés et au moins prévisibles et de gérer les exigences de gel pour garantir que le projet atteigne la ligne d'arrivée de manière respectable. Au cours de cette période a également été l'un des Manmonths mythiques en 1975.

Je suppose qu'à la fin des années 70, les gens étaient épuisés - car les langages procéduraux ne respectaient pas ces promesses. Et un nouveau paradigme orienté objet qui existait depuis cette époque l'a rendu grand. Bien que les gens puissent être en désaccord, je pense que le C ++ qui aide à la familiarité et à l'expérience prouvée et du C, et la promesse de l'orientation d'objet (à l'origine avec le nom C avec classes) en 1983 était une pierre angulaire du succès de la programmation orientée objet.

Quelques références pour plus de perspective - http://journal.thedacs.com/issue/43/88

Alors pourquoi OO?

Je pense que ces jours-ci (si vous regardez le point de vue de la réussite du projet) - il était logique que ce que vous pouvez mieux comprendre soit mieux gérable. La méthodologie orientée objet avec une promesse «..tout dans la vie est un objet» ressemblait plus à du bon sens avant même qu'il ne se révèle significatif. Le succès pratique de ce facteur était l'idée même de modéliser suffisamment le monde réel et le problème à résoudre avant de sauter le pistolet - ce que je pense quelque chose de fondamentalement nouveau qu'OO a offert qu'aucun autre paradigme n'a offert jusqu'à cette date. Et certainement étant donné que ce paradigme vous a forcé à réfléchir un peu avant de coder plus que les langages procéduraux, il a montré un succès visible sur les projets logiciels qui ont employé et depuis lors, ils ont pris de l'ampleur!

EDIT
J'ajouterais également que les langages de programmation ont évolué simultanément en parallèle à de tels concepts fondamentaux (paradigme OO, Aspect, machines virtuelles). coeur! Dans le même temps, ce nouveau concept et ces nouveaux langages n'ont émergé qu'en raison de nouveaux problèmes commerciaux. Années 1980 - OO pour les logiciels à grande échelle, 1990 Java à l'ère d'Internet, PHP / ASP et bien d'autres pour le Web. L'innovation dans les langages de programmation est également due principalement aux besoins discontinus du marché.

En résumé, le début des années 80 a été l'époque où les logiciels commerciaux à plus grande échelle ont décollé - alors que les projets avec des langages procéduraux avaient leurs problèmes, OO a montré la meilleure lumière et a rendu les projets plus réussis.

Je pense que la principale raison était le succès des interfaces utilisateur graphiques comme X et Windows. Une interface graphique se compose de plusieurs objets qui ont un comportement par eux-mêmes, quelque chose que OO est capable de représenter de près.

D'un autre côté, une interface utilisateur basée sur du texte (qui n'essaie pas de ressembler à une interface graphique) suit souvent simplement un modèle de commande-réponse, qui peut être facilement implémenté dans un langage procédural. Les règles métier et autres éléments similaires ont été mis en œuvre avec des langages procéduraux pendant des décennies, sans trop de problèmes, et encore aujourd'hui de nombreux programmes OO pour les applications commerciales sont plutôt procéduraux; avec des objets stupides qui contiennent les données et des objets sans état qui contiennent les règles métier; le premier pourrait être des enregistrements dans une langue de procédure, le second pourrait être, eh bien, des procédures.

Je vois la POO comme une étape évolutive naturelle du code procédural:

1. Code de procédure: dites à la machine de faire A, puis dites-lui de faire B.
2. POO: empaqueter les instructions procédurales en morceaux très réutilisables, en définissant des interfaces / entrées / sorties. (Attention: simplification.)

Je suis sûr que quelqu'un avec une vue plus large se fera entendre, mais il semble que ce fut une progression naturelle en permettant simplement aux programmeurs de produire du code plus rapidement: c'est-à-dire permettre une plus grande réutilisation du code.

De ce point de vue, le facteur externe le plus important était la réduction du coût de la puissance du processeur (par rapport au coût de main-d'œuvre du développeur pour créer des programmes typiques): les frais généraux de calcul lors de l'utilisation des classes OOP sont devenus moins préoccupants que les gains de temps du développeur. (Ce même compromis entre dépenses CPU et dépenses programmeur a influencé de nombreux autres aspects de la programmation.)

Au début, il y avait une programmation impérative (si vous pouviez l'appeler ainsi). Des instructions simples qui indiquent à l'ordinateur central quoi et comment il doit être calculé. Ces langages de programmation utilisaient des sauts inconditionnels et d'autres instructions "non structurées", la plupart exotiques selon les normes actuelles.

Ensuite, quelqu'un a proposé des structures de programmation. Le pour, tandis que, faites pendant et pour chaque que nous connaissons aujourd'hui. C'était une grande innovation puisque maintenant des applications avec un flux relativement complexe pouvaient être écrites et comprises facilement. C'est ainsi qu'est née la programmation structurée.

Puis sont venus d'autres personnes qui ont dit que vous deviez répéter beaucoup de code ici et là et que c'était un cauchemar à maintenir, donc un moyen de réutiliser le code devrait être inventé. Les gens ont proposé des procédures et des fonctions pour délimiter les bits de code réutilisables. Cela a également donné naissance aux principes d'encapsulation et de responsabilité unique.

Ensuite, certains universitaires ont déclaré que la fonctionnalité devrait être étroitement associée aux données sur lesquelles elle travaille. Ensuite, ils ont ajouté les concepts d'héritage pour la réutilisation de code et le polymorphisme pour correspondre à la manière logique dont la classification fonctionnait dans la vie réelle. Ainsi sont nés les langages de programmation de troisième génération et OOP.