Langage C++/Objet
Programmation orientée objet
[modifier | modifier le wikicode]Historique
[modifier | modifier le wikicode]Préhistoire : la programmation monolithique séquentielle
[modifier | modifier le wikicode]Au temps des prémices de l'informatique, à l'époque des dinosaures électromécaniques qui faisaient le volume d'un bâtiment de quatre étages, où les bandes magnétiques n'existaient pas encore, où la programmation se faisait en connectant des câbles et des trous ou, pour les plus sophistiqués, par cartes perforées, où le moindre calcul scientifique prenait plus de six mois à la main (et à la règle à calcul) et seulement une semaine une fois informatisé, la programmation était monolithique. C'est-à-dire que les développeurs de l'époque faisaient des programmes (la plupart du temps en binaire) de manière séquentielle et s'adressaient directement au système physique de traitement qui sera nommé plus tard et après miniaturisation : processeur. De fait le programme en question était le seul programme que la machine connaissait. Il n'y avait donc pas de traitements parallèles ni de problèmes d'accès concurrentiel aux ressources. Le programme était purement séquentiel et on recréait un nouveau programme pour chaque nouvelle application (qui à l'époque n'étaient que des calculs). Les programmes étaient courts (de quelques centaines à quelques milliers d'ordres machines simples). Le terme de "BUG" (insecte en anglais) est introduit à cause des cafards qui venaient se réchauffer un peu trop près de l'ancêtre des transistors, des lampes à tubes électrostatiques, et finissaient par griller entre les pâtes du composant, ce qui entrainait des pannes longues et coûteuses à réparer.
Antiquité : la programmation procédurale
[modifier | modifier le wikicode]À cette époque le transistor en silicium a déjà été intégré aux ordinateurs qui n'occupent plus qu'une salle de réunion entière. Les bandes magnétiques sont devenues monnaie courante et les programmeurs développent maintenant sur un clavier et un écran. Les premiers compilateurs pour langages extensibles lui permettent grâce au concept de procédures et de fonctions d'enrichir le langage de base dont il dispose en composant des suites d'instructions qu’il peut réutiliser. On développe alors les programmes de manière fonctionnelle afin de pouvoir décomposer un traitement en sous-traitements de plus en plus simples.
Moyen Âge : La programmation orientée donnée
[modifier | modifier le wikicode]À ce moment le processeur vient de voir le jour. Les ordinateurs occupent le volume d'une armoire. Les premiers systèmes d'exploitations mono-tâches voient le jour. Le programmeur définit toutes les variables dont il aura besoin et les regroupe par fonctionnalités dans des fichiers distincts avec les procédures et fonctions qui les traitent.
Renaissance : La multiprogrammation
[modifier | modifier le wikicode]À ce stade les processeurs/micro-contrôleurs sont courants. Les ordinateurs ont la taille de valises. Les premiers systèmes d'exploitation en ligne de commandes permettent une utilisation facilitée de l'ordinateur qui intègre désormais un disque dur et un lecteur de disquettes. Les programmeurs de l'époque commencent à utiliser le PIC (Programmable Interrupt Controller) au maximum de ses ressources. Les programmes résidents voient le jour. Le programme ne travaille plus seul, il doit cohabiter avec les autres programmes résidents dans la machine. Les concepts de processus et de threads voient le jour et les problèmes de concurrences d'accès aux ressources aussi. Les premiers réseaux d'entreprises voient le jour.
Temps Modernes : La programmation orienté objet
[modifier | modifier le wikicode]À l'époque, les industries du logiciel se heurtent de plus en plus à la difficulté de développer des projet de taille toujours croissante. Pire : plus il y a de monde sur le projet, moins le projet devient gérable avec les outils de l'époque, et ce, même pour des projets simples. La programmation orienté objet est un concept récupéré de l'ingénierie du bâtiment qui permet de décrire les différents aspects du logiciel de manière formelle et ainsi maitriser les couts, les délais, les risques et assurer la qualité du logiciel développé.
Pourquoi la programmation orienté objet
[modifier | modifier le wikicode]En 1995, le Standish Group édita un rapport édifiant intitulé "CHAOS" sur l'état des échecs de projets informatiques dans plus de 360 sociétés américaines. Ce rapport fait référence et fait état que les entreprises américaines et organismes gouvernementaux perdent des centaines de milliards de dollars par ans, de ne pas appliquer les mêmes règles de conception et de gestion du risque que dans les domaines de génie civil. En effet, ce rapport dénonce une renonciation des cadres techniques à appliquer les mêmes méthodes que leurs homologues du bâtiment, pour la plupart du temps pour des raisons politiques de rond de jambes et, pour les autre rares cas, d'incompétences de capture des besoins ou d'omission de diagnostic techniques.
- 16% de projets conformes aux prévisions initiales en temps et couts (mais souvent diminués en fonctionnalités),
- 53% de projets dépassements en coûts et délais d'un facteur 2 à 3,
- 31% de projets abandonnés.
Depuis, le Standish Group édite des mises à jours annuelle de ces chiffres, et malheureusement les chiffres restent très alarmants et surtout très réels.
En effet le logiciel étant un produit qui n'a de consistance qu'au travers de l'ordinateur qui l'exécute, les ingénieurs de l'époque n'arrivent pas à concevoir qu’il est aussi difficile d'abattre un mur porteur dans un immeuble que de redévelopper un ensemble de méthodes imbriquées les unes aux autres dans du code métier.
Qu'est-ce que la programmation orienté objet
[modifier | modifier le wikicode]Le paradigme de la programmation orientée-objet repose entièrement sur la "classe" à laquelle on délègue la gestion des données qui lui sont encapsulées et sont accessibles via l'interface représenté par ses méthodes appelées aussi accesseurs/mutateurs/propriétés. Les concepts d'abstraction, de généralisation, d'héritage, et de polymorphisme sont aussi cruciaux.
De nos jours : La programmation évènementielle
[modifier | modifier le wikicode]Grâce aux avancées technologiques en graphisme, l'entreprise Xerox développe une interface graphique pour ses imprimantes qui sera ensuite reprise par Steeve Jobs pour le compte du nouvel ordinateur d'Apple le Maccintosh. Bill Gates, voyant une menace en ce concurrent pour son MS DOS, débauche des ingénieurs d'Apple et crée son Windows 3.1x. La technologie basée sur les Interruptions du PIC permet de recevoir, de propager et de traiter en temps réel les évènements utilisateur. Les jeux informatiques voient le jour, les interfaces graphiques facilitent grandement l'accès à l'ordinateur qui se démocratise. Un enfant est capable d’utiliser un ordinateur. Internet voit le jour et se répand. Les "Design patterns" du GoF et du GRASP rendent possibles des réutilisations de développements en exposant des problèmes récurrents de programmation et leurs solutions-types.
Demain : La programmation orienté agent
[modifier | modifier le wikicode]La programmation orienté agent est une évolution de la programmation orienté objet. Au lieux d’utiliser des objets classiques uniquement réactifs, on utilise des objets composites comme les automates et/ou les réseaux neuronaux afin de rendre les objets, du moins en partie, pro-actifs en fonction de leurs états internes, de l'état de leur environnement et des taches qu’ils ont à réaliser. Le but du jeu est de rendre les agents autonomes et indépendants de l'interface de leurs voisins. Ainsi cela permet une plus grande souplesse de dialogue entre les agents. Cela pose toutefois l'éternel problème de la construction des moteurs de tels agents. En effet, plus un comportement logiciel est sophistiqué, plus le développement est difficile, couteux et instable. De nombreux frameworks voient le jour et comme tous les frameworks standards actuels ils sont incompatibles entre eux, un comble pour une architecture qui aspire à une compatibilité massive. Peut-être qu'un jour les interfaces s'uniformiseront mais, en attendant, vu la complexité de la mise en œuvre de ces agents, il me semble (et cela n'engage que moi) prématuré de les utiliser dans des solutions industrielles de grande envergure hormis éventuellement pour le domaine de la robotique et des domaines associés qui font encore partie de la recherche et qui ne sont pas encore entrés dans le grand public.
L'Objet
[modifier | modifier le wikicode]Dans le domaine de l'informatique, un objet est quelque-chose de concret au sens mathématique du terme que l’on peut manipuler ou dont on peut récupérer des informations.
- Un cercle de rayon 8 cm,
- Un triangle équilatéral de 3 cm de côté ou encore
- Un cube de 5 cm d'arêtes.
Les moules ou modèles qui ont permis d'obtenir ces figures (respectivement)
- (pi*(R*R)),
- (a*a)=(b*b)+(c*c)-(2*B*C*Cos(A)) où A=B=C=60°, et
- a*a*a
correspondent en C++ à ce que l’on appelle des Classes.
En développement on parle plus souvent d'instance de classe pour désigner la représentation informatisée d'un objet.
Pour faire une analogie avec le moulage, on pourrait dire que l'instance correspond à la figurine de plâtre peinte et vernie, et que la classe correspond au moule en caoutchouc qui lui a donné forme.
