Guide de survie à destination des débutants en orienté-objet [Picasoft]

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu’il s’agit d’une erreur.
====== Guide de survie à destination des débutants en orienté-objet ======
Ce guide a pour objectif de présenter succinctement les principaux concepts de la conception orientée-objet sans l'appliquer à un langage. L'idée est de comprendre globalement les concepts de classes (avec la notion d'attribut et de méthode), les associations entre classes (notamment l'agrégation et la composition) et enfin la notion d'héritage.

===== L'approche orientée-objet, une histoire de classes =====
L'approche orientée-objet est basée sur l'utilisation d'objets qui représentent (en ce sens, ce sont des abstractions) de concepts, d'idées ou de toute entité du monde réel : ces objets sont appelés des classes.\\
Dans le poly de LO21 (UV sur la conception et la programmation orientée objet à l'UTC), on peut lire :\\
//Une classe donne une description abstraite d'un ensemble d'objets qui partagent des caractéristiques communes. Une classe se décrit par un ensemble d'attributs et un ensemble de méthodes. Un attribut représente une propriété des objets de la classe. Une méthode est un regroupement d'instructions qui s'exécutent toujours sur un objet.// \\
Il est temps d'introduire un exemple, non ? Alors supposons que l'on cherche à modéliser, au sein d'une application, des personnes : chaque personne possède des caractéristiques qui lui sont propres (un nom, un prénom, une date de naissance,...) et chaque personne peut effectuer des actions (manger, boire, dormir,...) (//toute ressemblance avec un jeu vidéo de simulation de vie serait purement fortuite//).\\
Et bien, pour mener à bien cette modélisation, nous pouvons créer une classe Personne qui possèdent des attributs (les caractéristiques propres) et des méthodes (les actions).\\
Il est d'usage d'utiliser les diagrammes UML pour représenter les classes, en voici la méthode (la plus minimaliste) et l'application à notre classe Personne :\\ \\
{{ :txs:framadate-p18:archjustine:classe_guide.png?300 |}}

===== Les associations entre classes =====
Très bien, nous sommes maintenant en mesure de modéliser des classes, il serait intéressant maintenant de pouvoir les faire fonctionner ensemble : c'est possible grâce aux associations entre classes.\\
//L'association exprime la connexion entre classes correspondant à une famille de liens. Elle est le reflet d'une connexion qui existe dans le domaine de l'application.// \\
Comme souvent, un exemple vaut mieux que de longues phrases, observez l'UML suivant :
{{ :txs:framadate-p18:archjustine:asso_guide.png?300 |}}
Ici, nous avons donc les classes Cours, Professeur, Etudiant et Salle. Les traits entre les classes représentent les associations, les chiffres aux extrémités les arités. Ainsi, cet UML nous permet d'affirmer que :
  * un cours a lieu dans une et une seule salle
  * dans une salle peuvent avoir lieu aucun ou plusieurs cours
  * un cours est enseigné par un et un seul professeur
  * un professeur enseigne plusieurs cours (au moins un)
  * un cours est suivi par plusieurs étudiants (au moins un)
  * un étudiant suit plusieurs cours (au moins un)
==== L'agrégation ====
L'agrégation est une forme particulière d'association qui exprime un lien plus fort entre les classes : elle représente une relation composant (agrégé) - composé (agrégat).
==== La composition ====
La composition est une forme d'agrégation avec un lien encore plus important : ce couplage indique que les composants sont non partageables, la destruction de l'agrégat entraîne nécessairement la destruction des agrégés.
===== L’héritage =====
Revenons à notre premier exemple : la classe Personne. Supposons désormais que l'on souhaite gérer séparément les adultes des enfants car il existe des différences entre ces deux entités : un adulte travaille alors qu'un enfant va à l'école par exemple. Il est tout à fait possible de complètement notre modélisation pour répondre aux nouveaux besoins :\\ \\
{{ :txs:framadate-p18:archjustine:heritage_guide1.png?300 |}}\\ \\
Il est clair que ceci ne semble pas très optimisé : d'une part, si on modifie notre modélisation initiale, tout le code qu'on aurait déjà écrit portant sur la classe Personne devra être réécrit, et d'autre part, on a la répétition des attributs et des méthodes partagées par les deux classes. La COO propose une solution : il s'agit de l'héritage. L'idée est de créer une hiérarchie entre les classes : la classe dérivée hérite des potentialités (attributs et méthodes) de la classe de base tout en lui ajoutant de nouvelles fonctionnalités, sans qu'il soit nécessaire de modifier la classe de base (et donc tout le code qui se base dessus). \\ \\
Ainsi, dans notre exemple, la classe Adulte (resp. Enfant) va hériter de la classe Personne car un objet de la classe Adulte (resp. Enfant) est un objet de la classe Personne. En UML, on représente l'héritage par une flèche de la classe fille vers la classe mère (on peut la lire comme une association de type <est_un>).\\ \\
{{ :txs:framadate-p18:archjustine:heritage_guide2.png?250 |}}\\ \\