Webmaster Hub - Format normal - Les publications

Petite histoire de l’évolution des méthodes de programmation

On va vous la faire courte : au début, la programmation se résumait à du code machine entré en langage binaire (c’était l’époque des switches et des programmes sur cartes perforées). Puis on est passé à l’assembleur : c’est toujours du code machine, on remplace juste les 0 et les 1 par des jeux d’instructions plus intuitifs, et on compile le tout.

Puis vinrent les langages plus évolués, comme le COBOL, ou le FORTRAN, qui permettaient de coder des choses beaucoup plus complexes, mais qui avaient le défaut d’obliger les développeurs à continuer à réaliser des programmes avec des branchements conditionnels (GOTO). La création de programmes complexes était difficile, et la maintenance du code pouvait s’avérer très délicate.

Puis vinrent les L4G (comme le C, ou le Pascal) qui permettaient une programmation structurée, avec des boucles, des bibliothèque de fonction et des fonctions utilisateurs, et qui ont permis pour la première fois de faire de gros programmes "maintenables"...

Sauf que la taille des projets informatiques ne cesse de croître, et que les langages structurés ont vite révélé quelques manques pour répondre à certaines logiques de programmation.

La programmation objet, à quoi ça sert ?

Ce qu’on peut faire tout seul en un mois, on peut le faire à deux en deux mois.

Le problème qui se pose quand on a besoin d’élaborer des programmes complexes, c’est que l’on est très vite confronté aux problèmes suivants :
 comment comprendre et réutiliser les programmes faits par d’autres
 comment réutiliser les programmes que vous avez écrits il y’a six mois et dont vous avez oublié le fonctionnement
 comment "cloner" rapidement des programmes déja fait pour des applications légèrement différentes
 comment programmer simplement des actions simples sur des éléments variés et complexes
 comment ajouter des fonctions sans tout réécrire et tout retester

L’approche traditionnelle du développement, dite fonctionnelle [1], marche bien tant que le développeur sait où il va : le client a fourni un cahier des charges parfait et complet, ne changera pas d’avis, et une fois que le logiciel sera fini, on y touchera plus...

Dans ce cas, on peut décomposer les programmes en "fonctions" : un processus global, et des sous processus ou fonctions qui créent un arbre décomposant le problème en une série d’actions (c’est une décomposition "algorithmique")

Sauf que ces programmes idéaux n’existent pas : le client change d’avis, les logiciels vivent, et le développeur doit vraiment savoir où il va, surtout en cas de travail en équipe, car il ne s’agit pas de "découvrir" des choses en cours de route.

Or avec une approche fonctionnelle, tout changement de spécification à des conséquences catastrophiques... Il faut parfois tout refaire du sol au plafond...

Pour résoudre ces problèmes, il faut développer trois stratégies :
 modéliser différemment
 modulariser
 encapsuler

Le "modèle objet"

A quoi sert un modèle en programmation

L’intérêt du "modèle" en programmation, c’est de permettre de réaliser une "maquette" simplifiée du programme à réaliser. Un modèle est une "abstraction", une simplification de la réalité.

Un bon modèle doit réunir deux qualités :
 faciliter la compréhension du programme étudié, en réduisant la complexité
 permettre de simuler le comportement du programme

L’intérêt du "modèle objet

La force de la programmation objet, c’est qu’elle s’appuie sur un modèle calqué sur la réalité physique du monde. Les objets se comportent comme des entités indépendantes, auto-suffisantes qui collaborent par échange de message.

On peut aussi raisonner du particulier au général (généraliser) grace à la notion de classes d’objets, qui permet de partager entre les objets de la même classe des propriétés et des comportements...

Un objet, dans ce modèle, est défini comme un "truc" (une "entité") qui a des propriétés, et un comportement.

Les caractéristiques fondamentales d’un objet sont :
 une identité (ne pas confondre "voiture" et la voiture 2345 FGT 75)
 un comportement (freinage)
 un état (elle est rouge, le réservoir est plein)

On rentrera plus loin plus dans le détail de ce "modèle".

le triomphe de l’UML

Différentes méthodes de modélisation basées sur les objets ont été développées durant les années 80... Il y’en avait plus de 50, au début des années 90.

Mais ce qui s’est imposé récemment, c’est un langage de modélisation, baptisé UML (il ne s’agit pas d’une méthode).

UML standardise :
 les modèles
 les notations
 les diagrammes

Par contre, UML ne standardise pas les méthodes de développement.

Modulariser

Il est possible de découper un programme en modules autonomes grâce à une programmation de type "procédurale". On découpe le problème en éléments simples, on confie le développement de chacun des morceaux à des développeurs différents, avec obligation de respecter des "sous-spéfications" particulières.

Sauf que cela oblige les équipes de développement à créer leurs propres normes en matière de méthodes de développement, et l’expérience prouve qu’en l’absence d’une très grande rigueur, rien ne garantit que le produit fini fonctionnera de matière nominale.

La programmation objet apporte tous les outils pour avoir une approche "modulaire" de la programmation : l’objet est un "module" parfaitement opérationnel, et on peut construire des programmes complexes en jouant au Lego avec les objets :
 on peut réutiliser des bibliothèques de classes d’objets prêts à l’emploi
 on peut "personnaliser" des objets existants, sans toucher au code testé et revérifié du code de départ
 on peut faire agir des objets sur des objets, ou intéragir des objets entre eux, sans compromettre
 et modifier un objet (bien fait) n’oblige pas à modifier les autres objets...

La POO apporte aussi des "outils" simplifiant le travail du développeur, comme une notation particulière, et des "règles" qui produisent de la modularité "par construction".

L’encapsulation

La complexité dans les programmes est génératrice de bogues... Et la probabilité de l’existence de bogues inattendues croit de manière exponentielle avec le nombre de fonctions et de procédures qui intéragissent entre elles... Pour limiter ces phénomènes, il est donc impératif de pouvoir écrire des modules qui fonctionnent comme des boîtes noires hermétiques : ces boîtes attendent un certain type de données, de commandes, de message. Elles réagissent de manière prévisible, et renvoient un certain type de données, de messages.

Par contre : en dehors de ces "interactions" avec le monde extérieur, tout le reste est "encapsulé" dans la boîte, il est donc impossible que ce qui se passe dans la boîte influe sur une autre boîte, ou l’inverse...

L’encapsulation permet donc de "cloisonner" les données et les fonctions à l’intérieur de l’objet...

Bien sûr, là encore, on peut reproduire ce fonctionnement en "boîte noire" en procédural, mais cela oblige à réinventer un comportement qui existe en "natif" dans les objets...

L’intérêt de la POO par rapport au procédural et au fonctionnel

Le code est plus sûr

Les programmes sont plus clairs

La maintenance des applications est facilitée

Le code est facilement réutilisable

Il est facile de créer de nouveaux programmes légèrement différents par clonage d’un programme existant

Il est facile de faire évoluer des programmes

L’approche RAD est possible

La POO rend possible le développement de gros programmes

Les inconvénients

La POO oblige à réfléchir et à modéliser avant de programmer (est-ce réellement un inconvénient)

La notation POO n’est pas toujours intuitive

Quels sont les langages orientés objet ?

Beaucoup de langages implémentent la POO, parfois de manière optionnelle, comme le C ou le PHP.

Voici la liste des langages les plus courants (donc vraiment pas exhaustive) qui autorisent la POO

 C++
 C#
 PHP
 ASP
 JAVA
 J
 Pascal Objet
 Delphi
 Python

[1] Il existe en fait d’autres paradigmes de programmation : on distingue en général la programmation imprérative, fonctionnelle, objet et déclarative