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

14

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.

ihtkwot
la source
Cela a du sens, mais je suppose que j'étais plus intéressé par les circonstances externes qui se passaient pendant le développement. Il se pourrait très bien que les facteurs externes aient eu un effet limité.
Je vous garantis que même pour une question concernant les facteurs externes, programmers.stackexchange est un meilleur lieu. Il y a une tonne de gens qui travaillent activement dans l'industrie et beaucoup qui travaillent depuis le début de l'industrie. Vous serez beaucoup plus susceptible de trouver une personne qui a une excellente réponse à votre question qu'ici.
Opt
2
Smalltalk n'a pas commencé. Simula a créé les concepts de base de l'orientation des objets. Ce que Smalltalk a fait, c'est de prendre ces idées et de les transformer en un modèle très différent et de s'approprier le nom. Mais il convient de noter qu'aucun langage qui suit le modèle Smalltalk d'OO n'a jamais vraiment réussi à créer des programmes. (À l'exception d'Objective-C, qui est un cas spécial: Apple le met dans la gorge de tout le monde de son côté, mais personne en dehors de l'écosystème Apple ne l'utilise.) Tous les langages OO réussis: C ++, Delphi, Java, C #, etc, utilisez le modèle Simula.
Mason Wheeler
1
Les briques jouets Lego pourraient s'intégrer comme une influence externe ...
Jamie F
1
@Mason: je ne sais pas ce qui divise les modèles Simula et Smalltalk. Où mettriez-vous Ruby? LUA? Python? Javascript?
kevin cline

Réponses:

10

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.

Dipan Mehta
la source
Quelles étaient les caractéristiques du changement et où aller? Fin des années 70. Qu'est-ce qui a incité les développeurs à comprendre qu'il est temps de partir? Fatigué de la procédure, oui, mais il faut ben des cousins ​​d'alternatives?
Indépendant
@Jonas - ok - a modifié la réponse.
Dipan Mehta
En ce qui concerne le succès historique que nous évaluons, nous pouvons certainement affirmer que la familiarité joue un rôle. C (était le successeur de B), C ++ était un meilleur C même si OO était censé être un changement de paradigme. Même Java était un saut prêt à partir de C ++ (qui ressemblait plus à C ++ sans problèmes C ++, par exemple la mémoire et la portabilité). La plupart de ces langues traversé des gouffres en acquérant plus efficacement l'espace existant, même si elles avaient quelque chose de plus fondamental en elles. Plus encore, car chaque langage acquerra des programmeurs qui connaissent déjà d'autres langages de programmation. MAIS cela peut ne pas être toujours vrai!
Dipan Mehta
1
J'ajouterais également que les langages de programmation ont évolué simultanément en parallèle à de tels concepts fondamentaux (paradigme OO, Aspect, machines virtuelles). ! 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 80 - 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é.
Dipan Mehta
1
"Modeler le monde réel" semble concluant, mais dans la plupart des cas, cela ne se produit pas. La Customerclasse n'a pas de méthodes comme eatLunch, goToWorkou sleep, bien que ce soit ce que font les clients dans le monde réel . La Productclasse a plusieurs méthodes, bien que la plupart des produits n'aient aucun comportement dans le monde réel . Par conséquent, je dirais que le modèle OO ne correspond (plus ou moins) qu'en termes de propriétés, mais pas du tout en termes de comportement, au monde réel. Mais vous n'avez pas besoin d'OO pour avoir un modèle de données qui correspond à des objets du monde réel. Les types d'enregistrement suffisent.
user281377
6

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.

user281377
la source
4

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.)

Jamie F
la source
2

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.

linkerro
la source