Le diagramme de classes est un outil puissant de la modélisation orientée objet. Il est à la POO ce que l'algorithme est à la programmation en générale. Il permet de réfléchir aux concepts d'un projet, aux différents éléments qui le composent et à la façon dont ces éléments interagissent les uns avec les autres.
De la même façon qu'un algorithme, un diagramme de classes est indépendant du langage de programmation qui sera utilisé ensuite pour l'implémenter.
On a pu voir deux exemples de diagrammes de classes très simples dans les exemples précédents. Reprenons-les.
Fig. 1 - Représentation UML des classes Maison et Terrain
Ces deux classes définissent des objets différents, des maisons pour l'une et des terrains pour l'autre. mais pour autant, on voit apparaitre des redondances dans les attributs et les méthodes de ces deux classes. Ce que l'on détecte là est un exemple de relation possible entre des classes : Une relation d'héritage. Vous devez avoir une idée de ce que représente ce concept suite à vos différentes recherches de vocabulaire. Pour mettre en place une relation d'héritage dans notre exemple, nous allons devoir définir une troisième classe plus générale dont Maison et Terrain pourraient hériter. Le diagramme de classes suivant en donne un exemple.
Fig. 2 - Représentation UML d'une relation d'héritage. Les classes filles Maison et Terrain héritent d'une classe mère Bien
Autonomie : La notion d'héritage en programmation
Cette nouvelle modélisation, symbolisée par une flèche allant de la classe fille vers la classe mère, nous permet de limiter les répétitions : On met en place une classe Mère qui regroupe les attributs et les méthodes communes et chaque classe Fille ne contient ainsi que les informations qui lui sont spécifique.
Voyons comment se traduit une relation d'héritage en programmation avec l'ajout d'un nouveau fichier correspondant à notre nouvelle classe Bien :
Bien.cs
Maison.cs
Terrain.cs
Program.cs
Fig. 3 - Résultat en console de l'exécution du projet ExemplePOO
TO DO : Prenez le temps de bien comprendre le rôle joué par chaque classe et l'intérêt ici d'utiliser une relation d'héritage au travers notamment de la construction d'un tableau unique CatalogueBiens. Cette variable de type Bien nous permet en effet de recenser tous les biens, que ce soit des maisons ou des terrains, et de les manipuler indifféremment. Observez les différences par rapport aux classes initiales et manipulez par vous même les relations d'héritage en ajoutant de nouvelles classes.
Avez-vous remarqué les modifications de la ligne 6 de déclaration de la classe Terrain et de la
classe Maison et de la ligne 11 de déclaration du constructeur de ces classes ? La ligne 6
permet de déclarer que la classe en question hérite d'une autre classe en spécifiant le nom de la classe mère après
les deux points. La ligne 11 permet d'utiliser le constructeur de la classe mère au moment de la construction d'une
instance de la classe fille via le mot clé base qui fait référence au constructeur de la classe mère.
En complétant une fois de plus notre exemple, on peut faire apparaître deux autres types de relations. Observez bien l'exemple suivant.
Fig. 4 - Représentation UML des différents types de relations existants
Deux nouvelles classes ont fait leur entrée. La classe Piece reliée à la classe Maison par une relation de composition. Cette relation se lit de la façon suivante : Une pièce appartient à une ou aucune maison. Une maison est composée d'au moins une pièce et ne peut pas en contenir plus que la valeur enregistrée dans son attribut NbPiece
La classe Proprietaire est, quant à elle, reliée à la classe Bien par une relation d'agrégation. Cette relation se comprend de la façon suivante : Un propriétaire peut avoir aucun ou plusieurs biens et un bien a forcément un proriétaire.
TO DO : Commencez par créer le code correspondant aux deux nouvelles classes (Pièce et Propriétaire). Nous verrons ensuite comment les connecter avec les classes déjà existantes pour faire apparaitre des relations de composition et d'agrégation.