La programmation objet repose sur un certain nombre de "concepts", qui sont en fait des abstractions permettant de modéliser plus facilement le comportement d’un programme.

Nous allons nous attarder un peu plus longtemps sur ces notions, qu’il est important d’assimiler avant de commencer à programmer ou à modéliser dans le "paradigme objet".

Nous allons donc tour à tour étudier :
les objets
les messages
les classes
l’héritage
le polymorphisme

Puis les autres types de relation :
la délégation
l’association
l’agrégation

Avant d’introduire la modélisation et l’UML

Mais nous allons tout d’abord planter le décor, en s’appuyant sur un exemple concret.

L’exemple : le garage Moulins [1]

Le garage Moulins est un petit garage familial de Province, qui appartient à Guy Moulins. Guy répare à la fois les voitures, les véhicules agricoles, et les camions.

Guy est marié, son épouse s’appelle Monique. Ils ont deux enfants, Vincent, qui apprend lui aussi le métier de garagiste (il est en apprentissage chez un garagiste ami), et Ludivine, qui est au Collège.

Ils ont un chien, un cocker qu’ils ont appelé Joe. (oui je sais, bof...)

Guy travaille dans le garage avec un ouvrier, Michel, et une secrétaire, Ghislaine.

Le garage Moulins travaille beaucoup avec l’entreprise de transports Dugenoux, qui lui apporte tout son parc de véhicules à réparer.

Voila le tableau...

Les objets

L’objet est une entité "atomique" (mais éventuellement composite), caractérisée par :
un état
un comportement
une identité

Objet=Etat+Comportement+Identité

les messages

Par rapport aux messages on distingue trois catégories d’objets :
les acteurs (qui envoient des messages)
les serveurs (qui attendent des messages)
les agents (qui savent envoyer et recevoir des messages)

Il y’a 5 types de messages :
les constructeurs : qui spécifient comment créer un objet
les destructeurs : qui spécifient ce qui se passe quand un objet disparait
les selecteurs : qui renvoient tout ou partie de l’état d’un objet
les modificateurs : qui changent l’état de l’objet
les itérateurs : qui appliquent un traitement sur une liste d’attributs

On distingue aussi les messages asynchrones, synchrones, retardés et minutés

IMPORTANT : on distingue deux types de comportement d’objet en réponse à un message =>
statique (si le traitement du message ne dépend pas d’autres paramètres
dynamique (si le traitement du message dépend de paramètres externes ou internes à l’objet

La plupart des objets ont un comportement mixte : statiques pour certains messages, dynamiques pour d’autres.

Dans la pratique, la situation la plus courante correspond à un objet qui peut prendre plusieurs états, les messages traités par les méthodes faisant passer l’objet d’un état à l’autre : c’est que l’on appelle le cycle de vie d’un objet.

les classes

Les classes sont une "abstraction". Les objets peuvent correspondre à des objets du monde réel (la Peugeot bleue de Michel et la SAAB noire de Charles-Henri), les classes correspondent à une entité abstraite de niveau supérieur (en l’occurrence le concept de "voiture").

En POO, les classes rassemblent les attributs (définissant l’état) et les méthodes (définissant les comportements) communs à une catégorie d’objets.

l’héritage

L’héritage est une "propriété" essentielle des objets en POO. Les objets instanciés héritent des attributs et des méthodes de leur classe, qui elle même hérite ses attributs et méthodes d’une classe de niveau supérieur.

Tout cela définit un arbre d’héritage, appelé "hiérarchie de classes".

le polymorphisme

Voilà un joli néologisme pour appeler un comportement facile à décrire. Il est très utilisé dans les outils de dessin. Le polymorphisme permet :
de définir une méthode dans une classe de niveau supérieur, sans se soucier de ce qu’elle fait dans le détail
et de définir un code spécifique dans les classes de niveau inférieur

Exemple : un logiciel de dessin, dans lequel on définit une classe d’objets géométriques. On définit une méthode générique dessiner(), sans se soucier de coder tous les cas. Mais on définit le code de dessiner() pour la sous-classe "carré", et la sous-classe "cercle".

Ce qui permet de passer facilement du "général" au "particulier", ce qui en programmation procédurale est un véritable casse-tête...

les autres types de relation

la délégation

La délégation décrit un comportement particulier entre objets. Il s’agit d’une délégation au "sens commun" du terme. Un objet, qui a la responsabilité d’accomplir une tâche, et qui se voit demander d’accomplir une tâche, peut disposer d’une méthode qui lui permet de déléguer cette tâche à un autre objet, qui l’effectuera a sa place.

l’association

La relation hierarchique entre classes correspond aux différents niveaux de généralisation/spécialisation pour les classes. Mais on peut définir d’autres types de liens entre objets.

La relation d’association est classiquement établie entre des "pairs", c’est à dire des classes qui sont au même niveau hiérarchique, ou qui ne sont pas reliées hiérarchiquement. On définit généralement une association entre deux classes, mais l’association peut comporter plus de deux classes ou objets.

Ex : Une classe Ouvrier et une classe Entreprise. On peut associer les deux par une relation (une association donc) appelée "travaille pour". Dans une association, chaque classe à un rôle particulier, que l’on peut "nommer" : dans cette association exemple, Ouvriers est "employé" et Entreprise "employeur".

l’agrégation

ATTENTION FAUX AMI A NE PAS MELANGER AVEC HERITAGE...

EXEMPLE 1 : héritage Soit les classes voiture et véhicule à moteur. Une voiture est une sorte de véhicule à moteur. Les deux classes sont reliées par une relation de type "généralisation/spécialisation" La classe voiture "hérite" des attributs et méthodes de "véhicule à moteur".

EXEMPLE 2 : agrégation Soit les classes voiture, moteur et roue L’agrégation consiste à observer que la "moteur" est une partie de "voiture", que roue est aussi est une partie de "voiture", et qu’une voiture est composée de "moteur" et de quatres "roues"

Le piège, c’est que si "voiture" hérite bien ses propriétés de "vehicule à moteur", c’est différent pour "roue" partie de "voiture"

INTRODUCTION A L’UML

Ce que c’est :
une notation, pas une méthode
un langage de modélisation
une "norme" devenue très répandue

Les composants

Les relations

Les diagrammes

Résumé : structure du langage UML

Les caractéristiques de la modélisation en UML

un processus en "plusieurs passes" (itératif)
une démarche centrée sur les besoins de l’utilisateur
le souci de l’architecture logicielle

Les cinq vues

cas d’utilisation (à la croisée des chemins)
logique ou conception (abstraction, encapsulation)
implémentation
déploiement

[1] L’exemple "automobile" est un grand classique dans les docs sur la programmation objet, donc on ne va pas déroger à la règle

> Langages du Net