Approche procédurale et décomposition fonctionnelle

Avant d’énoncer les bases de la programmation orientée objet, nous allons revoir l’approche procédurale à l’aide d’un exemple concret d’organisation de code.

Dans cet ouvrage reviennent souvent les termes "code", "coder", "codage" ; il ne s’agit ni d’alarmes ni de fonctions de cryptage de mot de passe. Le code ou code source est en fait le nom donné au contenu que le développeur entre à longueur de journée dans son éditeur de texte favori pour être ensuite converti (ou encore compilé) en flux d’instructions exécutables par l’ordinateur.

La programmation procédurale est un paradigme de programmation considérant les différents acteurs d’un système comme des objets pratiquement passifs qu’une procédure centrale utilisera pour une fonction donnée.

Prenons l’exemple de la distribution d’eau courante dans nos habitations et essayons d’en modéliser le principe dans une application très simple. L’analyse procédurale (tout comme l’analyse objet d’ailleurs) met en évidence une liste d’objets qui sont :

le robinet de l’évier ;
le réservoir du château d’eau ;
un capteur de niveau d’eau avec...

La transition vers l’approche objet

La programmation orientée objet est un paradigme de programmation considérant les différents acteurs d’un système comme des objets actifs et en relation. L’approche objet est souvent très voisine de la réalité.

Dans notre exemple :

L’utilisateur ouvre le robinet.
Le robinet relâche la pression et l’eau s’écoule du réservoir du château d’eau à l’évier.
Comme notre utilisateur n’est pas tout seul à consommer, le capteur/flotteur du réservoir arrive à un niveau qui déclenche la pompe de puisage dans la rivière.
L’utilisateur referme le robinet.
Alimenté par la pompe, le réservoir du château d’eau continue à se remplir jusqu’à ce que le capteur/flotteur atteigne le niveau suffisant qui arrêtera la pompe.
Arrêt de la pompe.

Dans cette approche, vous constatez que les objets "interagissent" ; il n’existe pas de traitement central définissant dynamiquement le fonctionnement des objets. Il y a eu, en amont, une analyse fonctionnelle qui a conduit à la création des différents objets, à leur réalisation et à leur mise en relation.

Le code du programme "objet" va suivre cette réalité en proposant autant d’objets...

Les caractéristiques de la POO

1. L’objet, la classe et la référence

a. L’objet

L’objet est l’élément de base de la POO. L’objet est la réunion :

d’une liste de variables d’états ;
d’une liste de comportements ;
d’une identification.

Les variables d’états changent durant la vie de l’objet. Prenons le cas d’un lecteur de musiques numériques. À l’achat de l’appareil, les états de cet objet pourraient être :

mémoire libre = 100% ;
taux de charge de la batterie = correct ;
aspect extérieur = neuf.

Au fur et à mesure de son utilisation, ses états vont être modifiés. Rapidement la mémoire libre va chuter, le taux de charge de la batterie variera et l’aspect extérieur va changer en fonction du soin apporté par l’utilisateur.

Les comportements de l’objet définissent ce que peut faire cet objet :

Jouer de la musique
Aller à la piste suivante
Aller à la piste précédente
Monter le son
etc.

Une partie des comportements de l’objet est accessible depuis l’extérieur de cet objet : Bouton Play, Bouton Stop... et une autre partie est uniquement interne : lecture de la carte mémoire, décodage de la musique à partir du fichier. On parle "d’encapsulation" pour définir la limite entre les comportements accessibles de l’extérieur et les comportements internes.

L’identification d’un objet est une information, détachée de la liste des états, permettant de différencier cet objet particulier de ses congénères (c’est-à-dire d’autres objets qui ont le même type que lui). L’identification peut être un numéro de référence ou une chaîne de caractères unique construite à la création de l’objet ; elle peut également être l’adresse mémoire où l’objet est stocké. En réalité, sa forme dépend totalement de la problématique associée.

L’objet programmé peut être attaché à une entité bien réelle, comme pour notre lecteur numérique, mais...

Le développement objet

1. Cahier des charges du logiciel

La première étape d’un développement logiciel consiste à rédiger un document décrivant, dans un langage compréhensible par le client demandeur et par les développeurs, les fonctionnalités du produit à réaliser. Ce document est très important car il va définir les limites du programme en formalisant les besoins, les exigences et les contraintes. Il définira les différents types d’utilisateurs et leurs interactions possibles en fonction de leurs droits sous forme de cas d’utilisations. Lors de la rédaction de ce document, il est absolument nécessaire de s’imprégner de la culture de l’entreprise et de dialoguer avec tous les intervenants. Le cahier des charges est l’élément de base de la modélisation. C’est grâce au soin particulier qui sera porté à sa réalisation que toutes sortes de différends pourront être évités par la suite...

2. Présentation du cycle en V

Un développement logiciel est composé de plusieurs phases à mener méticuleusement pour bien cerner un besoin et ne pas se tromper sur l’architecture qui va y répondre. Il existe plusieurs modèles de développement et le cycle en V présenté ici nous vient du domaine industriel. Ce concept n’est pas spécifique à la programmation objet et est très utilisé. Son application "à la lettre" conduira à un bon résultat, mais elle peut toutefois s’avérer lourde à mettre en place.

Dans le cycle en V, on va partir des besoins du client (branche gauche position haute du V) pour descendre en trois étapes jusqu’à la rédaction du programme (base du V) :

À partir des besoins client, spécifier les fonctions.
À partir des fonctions, spécifier l’architecture globale.
À partir de l’architecture globale, spécifier les modules détaillés.

La base du V est consacrée au codage du programme.

Ensuite, la remontée de la branche droite va se faire par trois autres étapes qui confirmeront les objectifs de la branche gauche, à savoir :

Valider...

Exercices

1. Hiérarchie de classes

Énoncé

Dessinez le diagramme de classes UML synthétisant les liaisons entre les objets suivants :

Hélicoptère
Sous-Marin
Moto
Transport terrestre
Camion
Voiture
Transport
Avion
Scooter
Paquebot
Transport aérien
Camion-citerne
À deux roues
Voiture décapotable
Transport maritime
Avion de chasse
Moto de cross
Vélo
VTT
À quatre roues

Corrigé

Dans cette hiérarchie de classes se dégage une classe générale de base qui est Transport. Cette classe de base va ensuite se spécialiser au fur et à mesure des niveaux. Gardez à l’esprit la liaison "est une sorte de…" qui aide à bien appréhender les notions d’héritage et de polymorphisme. Le VTT spécialise son parent Vélo en ajoutant des fonctions de parcours tout terrain mais en gardant ses attributs de base : c’est l’héritage. Le VTT est "une sorte de" vélo qui est lui-même "une sorte de" transport terrestre à deux roues qui est finalement "une sorte de" transport. Par conséquent, quand un objet Transport est demandé, alors un VTT peut être utilisé : c’est le polymorphisme.

2. Relations entre objets