Introduction aux concepts

orientés objets
Étienne G. Tajeuna
gael.tajeuna@estad.net

ESTAD
École Supérieure des Techniques Avancées pour le Développement
Sommaire
1. Définition et origine

2. Introduction à UML

3. Concepts de base

4. Les patrons de conception

5. Les patrons d'architecture

6. Concepts avancés
1. Définition et origine :
Définitions
• La programmation orientée objet (POO) est un modèle de
programmation informatique qui met en œuvre une conception
basée sur les objets.

• Un objet est toute chose tangible que l'on peut manipuler.

• En langage informatique par contre, un objet n'est tangible pas

tangible. Toutefois, il reste manipulable.
1. Définition et origine :
Définitions
• L'objet en informatique n'est manipulable du fait qu'on lui associe des
fonctions / propriétés dédiées : on parle d'objet orienté.

• La POO se différencie de la programmation procédurale, qui est basée

sur l’utilisation de procédures, et de la programmation fonctionnelle,
qui elle, repose entièrement sur le concept de fonction.
1. Définition et origine :
Définitions
1. Définition et origine :
Origine
• Les premiers concepts de la programmation orientée objet date des années 1970 avec
les langages Simula et Smalltalk.

• Plus tard dans les années 1980, on note une forte croissance des langages à
objets : Eiffel, C++, ou encore Objective C (une extension objet du C utilisé par le
système d'exploitation d’Apple).

• Cette croissance atteint son apogée dans les années 1990 avec la création du
langage Java par la société Sun Microsystems (racheté depuis par Oracle).

• Java étant libre (open source), Microsoft dans les années 2000 décide de sortir son
propre framework, le .NET et son propre langage full orienté objet, C#, pour éviter de
voir le marché des systèmes d'exploitation pour ordinateur l’échapper au profit de
l’écosystème open source, porté désormais par Java.
1. Définition et origine :
Origine
• De nos jours, les principes de la POO sont utilisés dans plusieurs autres langages :
PHP (à partir de la version 5), Python, etc…

• La Programmation orientée objet a entraînée un changement profond dans la

manière de concevoir l’architecture des applications informatiques.

• Au cours de la modélisation d’une application on réfléchit désormais en termes d’

objets : c’est la modélisation orientée objet (MOO), dont le principal
support est le langage de modélisation UML.
2. Introduction à l'UML
• UML (Unified Modeling Language), est un langage, non pas de programmation,
mais de modélisation graphique.

• Il consiste en un ensemble de diagrammes permettant de représenter

schématiquement l’architecture, les processus, les fonctionnalités, etc… d’une
application.

• Il est actuellement le plus adapté dans son domaine, concernant la majeure

partie des cas.

• Les diagrammes UML sont nombreux (diagramme de classe, diagramme de cas

d’utilisation, diagramme d’activité, …). Seul le diagramme de classe sera détaillé
ici.
2. Introduction à l'UML
• Concevoir une application en se basant uniquement sur le code n'est pas
toujours chose facile,

• Afin de bien définir et plutard bien élaborer son programme, il devient

donc important d'utiliser des diagrammes UML,

• Pour les clients, ces diagrammes sont généralement simples à comprendre.

Et même si un client ne connaît pas l’UML, il sera capable de comprendre
une grande partie de vos diagrammes,

• Enfin, dans un soucis de documentation, l’UML constitue une base solide.

2. Introduction à l'UML
Diagramme de classes
• Il s’agit du diagramme le plus utilisé, car il permet de représenter de
manière très concrète l’architecture de votre application,
les classes qui la composent, et les liens entre ces dernières.

• Comme son nom l’indique, un diagramme de classe se base sur les

classes, et donc sur la Programmation Orientée Objet.

• Ce diagramme permet de représenter schématiquement une classe,

ses attributs, ses méthodes, la visibilité de ceux-ci, et les différentes
relations entre les classes.
2. Introduction à l'UML
Diagramme de classes

• Les classes

Une classe est composée de trois parties :

o Son nom
o Ses attributs
o Ses méthodes
2. Introduction à l'UML
Diagramme de classes -- Nom d'une classe

• Le nom d'une classe est basé sur les mêmes standards de nommage
que la POO, il peut néanmoins être représenté de différentes
manières.

• S’il s’agit d’une classe abstraite, le nom sera écrit en italique.

• S’il s’agit d’une interface, on ajoute le mot clef <<interface>>, juste au

dessus du nom.
2. Introduction à l'UML
Diagramme de classes -- Nom d'une classe
2. Introduction à l'UML
Diagramme de classes -- Attribut(s) d'une classe
• Un attribut se définit en trois parties : un nom, un type, et une visibilité.
• Le nom de l’attribut doit respecter les conventions de nommage en
vigueur.
• Le type peut-être scalaire (int, float, char, etc…), ou bien objet (String,
DateTime, etc…).
• La visibilité définit le statut d'une classe vis-à-vis des autres. On a par
exemple le statut public, privé etc. … En UML on utilise des symboles pour
les reconnaître :
+ : public
- : private
# : protected
~ : package
2. Introduction à l'UML
Diagramme de classes -- Attribut(s) d'une classe
2. Introduction à l'UML
Diagramme de classes -- Méthode(s) d'une classe
• Une méthode se définit d’une manière semblable à un attribut.

• On écrira d’abord la visibilité de la méthode, suivi du nom de la méthode, puis des arguments en
paramètre, et enfin le type de retour de la méthode si celle-ci retourne quelque chose.

o Le nom de la méthode doit respecter les conventions de nommage en vigueur.

o Les arguments sont décrits entre les parenthèses, comme en programmation. Le nom des arguments doit
respecter les conventions de nommage en vigueur. Chaque argument est séparé par une virgule. Le nom d’un
argument est suivi de “:” puis de son type.

o Le type de retour est optionnel si la méthode ne retourne rien. Il peut-être scalaire (int, float, char, etc…), ou
bien objet (String, DateTime, etc…).

o La visibilité des attributs est utilisée pour les méthodes, à savoir les 4 symboles “+”, “–”, “#”, et “~”.
2. Introduction à l'UML
Diagramme de classes -- Méthode(s) d'une classe
 2. Introduction à l'UML
Diagramme de classes -- Les types de relation -- Héritage
L’héritage en UML est représenté par La représentation de l’héritage peut-être
une flèche, dont l’extrémité est représentée simplifiée visuellement si plusieurs classes
par un triangle pointant la classe “parent”. “enfant” étendent la même classe “parent”.
 2. Introduction à l'UML
Diagramme de classes -- Les types de relation -- Association

Une association est un lien entre deux Le lien ici pourrait-être nommé pour
classes. donner un sens à la relation des deux
Ce lien peut être non orienté classes.

Traite la demande de
 2. Introduction à l'UML
Diagramme de classes -- Les types de relation -- Association

Une association non-orientée est aussi vue comme une association bidirectionnelle.
Dans certain cas, cette association pourrait être unidirectionnelle.
2. Introduction à l'UML
Diagramme de classes -- Les types de relation -- Association

Une association pourrait également mettre en exergue le

nombre d'instances relationnelles entre les classes: on parle
de cardinalité.

Association OnetoOne Association OnetoMany Association ManytoMany

1 1 1 * * *
 2. Introduction à l'UML
Diagramme de classes -- Les types de relation -- Agrégation
• La relation de type agrégation est très similaire à la relation de type association.

• L'agrégation ajoute une logique plus forte sur l'association des classes.

• Cette relation a pour but de définir qu’un objet contient d’autres objets.

• Une agrégation est représentée en UML par un trait, dont une des extrémités est
un losange vide, pointant vers la classe qui possède l’autre.
 2. Introduction à l'UML
Diagramme de classes -- Les types de relation -- Composition
• Une composition est exactement la même chose qu’une agrégation, à une
exception près.
o Dans le cas d’une agrégation, la suppression de l’objet qui contient l’autre
n’entraîne pas automatiquement la suppression du second.
o Dans le cas d’une composition, la suppression du premier entraîne la
suppression du second. L’inverse n’est pas vrai.
• La représentation en UML d’une composition est la même que pour une
agrégation, sauf que le losange doit être plein.
 2. Introduction à l'UML
Diagramme de classes -- Les types de relation -- Dépendance
• Une dépendance permet de définir qu’une classe ne peut pas fonctionner sans une
autre.
• Illustration:
o Supposons une classe Calculatrice, permettant de faire des calculs complexes
(prendre une expression scientifique, et déterminer le résultat, peu importe le
nombre d’opérations qui la composent).
o Nous disposons aussi d’une classe Math permettant de faire des calculs basiques
(addition, soustraction, etc…).
o La classe Calculatrice aura besoin de la classe Math pour fonctionner.
o Si on supprime la classe Math, la classe Calculatrice ne pourra plus fonctionner.
o La classe Math est totalement indépendante, mais la classe Calculatrice,
elle, dépend de la classe Math pour fonctionner.
• Une dépendance est représentée par une flèche semblable à une association, mais avec
des pointillés.
2. Introduction à l'UML
Diagramme de classes -- Les types de relation -- Dépendance
 2. Introduction à l'UML
Diagramme de classes -- Les types de relation -- Package
• De manière générale, un diagramme de classe représente une partie spécifique d’une
application, rarement l’application dans son intégralité.
• Dans le cas où l'on aurait beaucoup trop de classes, on préfère généralement
faire plusieurs diagrammes de classe, représentant chacun une partie de l’application
nécessitant d’être détaillée.
• Les packages en programmation, peuvent être représentés sur un diagramme de classe.
 2. Introduction à l'UML
Diagramme de classes -- Les types de relation -- Package

• Chaque package peut bien sûr

contenir des classes, et les
classes qui y figurent peuvent
interagir avec les classes
d’autres packages.
2. Introduction à l'UML
En résumé
• UML, langage de modélisation graphique permettant de schématiser une a
rchitecture, un fonctionnement, etc…

• Faire un diagramme de classe nécessite un minimum de rigueur, mais

contribue à se faire comprendre rapidement, et de parler le même langage.

• Il existe de nombreux diagrammes, chacun permettant de détailler d’une

manière claire certains aspects de l’analyse.

• Classe : Composée d’un nom, d’attributs, et de méthodes.

2. Introduction à l'UML
En résumé
• Héritage : Une classe fille hérite des attributs/méthodes d’une classe mère.
• Association : Lien faible entre deux classes.
• Agrégation : Association avec notion de “composition”.
• Composition: Agrégation avec notion de suppression en cascade.
• Dépendance : Une classe peut dépendre d’une autre pour fonctionner.
• Multiplicité /Cardinalité : Permet de définir le nombre d’instance qui relie
deux classes.
• Navigabilité : Permet de définir si le lien va dans un sens (unidirectionnel),
ou dans les deux (bidirectionnel).
• Package : Permet de définir les différentes parties d’une application.
TD-1&2 (UML, diagramme de classes) – Durée 2 heures.
Prochaine séance (jeudi 16 février 2023)
• Cette séance sera entièrement dédiée à la construction des
diagrammes de classes.

• Nous allons reparcourir les concepts de diagramme de classes.

• Nous travaillerons avec le logiciel Drawio,

• Pour ce faire, vous devez l'installer d'avance : https://draw-

io.fr.softonic.com/
3. Concepts de base
Rappelons que la POO est une méthode de programmation don’t le but
est :
• d’améliorer la qualité du code produit,

• la maintenance,

• la réutilisabilité,

• mais aussi de simplifier d’éventuelles évolutions.

3. Concepts de base
Pour ce faire il est important de maîtriser certains concepts,
1. Concept de classe
2. Concept d'objet
3. Concept de Responsabilité Unique
4. Concept d'encapsulation
5. Concept de couplage
6. Concept d'immuabilité
7. Concept de réutilisabilté
8. Concept de polymorphisme
9. Concept KISS
3. Concepts de base
3.1. Concept de classe
• Une classe est une structure abstraite qui décrit des objets du monde réel
sous deux angles : ses propriétés (ses attibuts) et ses méthodes (les actions
qu’elle peut effectuer ou son comportement).

• La classe est une sorte de moule/modèle à partir duquel on peut générer

des exemples/instances.

• Les exemples/instances générés par une classe s’appellent des objets.

• Les objets sont construits à partir de la classe, par un processus

appelé instanciation. De ce fait, tout objet est une instance de classe.
3. Concepts de base
3.1. Concept de classe
3. Concepts de base
3.1. Concept de classe
L’instanciation d’une classe fait appel à 3 méthodes spéciales :
1. Le constructeur : on distingue trois types de constructeurs
• Le constructeur par défaut appelé par défaut lors de la création d’un objet
(offert par défaut lors de la compilation s’il n’y a pas de constructeur déclaré),

• Le constructeur par recopie (ou constructeur de copie) a un unique argument

du même type que l’objet à créer (généralement sous forme de référence
constante) et il recopie les attributs depuis l’objet passé en argument sur
l’objet à créer.

• Le constructeur paramétrique appelé si la signature correspond à celle du

constructeur.
3. Concepts de base
3.1. Concept de classe
L’instanciation d’une classe fait appel à 3 méthodes spéciales :
1. Le constructeur
2. Les accesseurs (get) et les mutateurs (set) :
• ces méthodes spéciales permettent d’appeler les propriétés et modifier les
propriétés d’une classe depuis l’extérieur.
• Grâce à elles on pourra faire des communications entre les classes.
• Les accesseurs permettent de récupérer la valeur des propriétés d’une instance
de classe depuis l’extérieur sans y accéder directement. Ce faisant, ils sécurisent
l’attribut en restreignant sa modification.
• Les mutateurs permettent de modifier la valeur des propriétés tout en vérifiant
que la valeur que l’on veut donner à l’attribut respecte les contraintes
sémantiques qui ont été imposées à la classe.
3. Concepts de base
3.1. Concept de classe
L’instanciation d’une classe fait appel à 3 méthodes spéciales :
1. Le constructeur
2. Les accesseurs (get) et les mutateurs (set)
3. Le destructeur
• Est une méthode qui met fin à la vie d’une instance de classe.

• Il peut être appelé à la suppression de l’objet, explicitement ou

implicitement.
3. Concepts de base Identité de l'objet

3.1. Concept d'objet

Un objet est une instance
de classe, un exemple
généré par une classe.
Un objet est caractérisé par
3 choses :

• (1) une identité : l’identité

doit permettre d’identifier
sans ambiguïté l’objet
(adresse/ référence ou
nom)
3. Concepts de base Identité de l'objet

3.1. Concept d'objet

Un objet est une instance de classe,
un exemple généré par
une classe. État
Un objet est caractérisé par 3 de
l'objet
choses :

• (2)des états : chaque objet a une

valeur par défaut (lorsqu’elle est
indiqué à l’instanciation) pour
chacune de ses propriétés. On
appelle ces valeurs, des états de
l’objet.
 3. Concepts de base Identité de l'objet

3.1. Concept d'objet

Un objet est une instance de classe,
un exemple généré par une classe.
Un objet est caractérisé par 3 choses : État
• (3) des méthodes : chaque objet de
est capable d’exécuter les actions ou l'objet
le comportement défini dans la
classe. Ces actions sont traduites en
POO concrètement sous forme Métho-
de méthodes. des
Les actions possibles sur un objet sont de
déclenchées par des appels de ces l'objet
méthodes ou par des messages
envoyées par d’autres objets.
3. Concepts de base
3.1. Concept d'objet
Les objets ne sont pas des éléments statiques et leur durée de vie ne
correspond pas forcément à la durée d’exécution du programme. La
durée de vie d’un objet passe par trois étapes :

1. la déclaration de l’objet et son instanciation

2. l’utilisation de l’objet en appelant ses méthodes

3. la suppression de l’objet, en appelant son destructeur ou en arrêtant la

machine virtuelle qui exécute le programme, ou en arrêtant simplement le
programme.
3. Concepts de base
3.3. Concept de Responsabilité Unique
• Le principe de responsabilité unique sous-entend qu'une classe ne doit
avoir qu'une seule et unique responsabilité.
• Ceci permet d'avoir une meilleur fluidité dans le
code, ainsi chaque classe créée n'aura qu'une seule responsabilité.

Ex: Nettoyage de la salle de cours.

Créer un ensemble de sous-tâches de tel sorte que chaque intervenant ait une
tâche précise à accomplir dans le but de nettoyer la salle de cours.
1- Balayer
2- Laver
3- Dépoussiérer
4- Déplacer
3. Concepts de base
3.3. Concept de Responsabilité Unique
• En respectant le principe de responsabilité unique, on rend notre
code ré-utilisable.

Ex. Lors d'une nouvelle séance de nettoyage de la salle de cours, on

aura plus besoin de créer une nouvelle approche pour le faire. Il sera
simplement question de d'affecter les intervenants à chacune des
responsabilités déjà définies.
3. Concepts de base
3.3. Concept de Responsabilité Unique
• En respectant le principe de responsabilité unique,
il devient plus facile de faire de la maintenance / mise à jour de son
code.

Ex: Dans le même exemple, si l'on voudrait améliorer la technique de

nettoyage de la salle de cours en améliorant la technique de lavage, il
suffit juste d'intervenir sur le principe de lavage sans toutefois
intervenir sur les autres principes (balayage, déplacement,
dépoussiérage, etc. ...).
3. Concepts de base
3.3. L'encapsulation
• les propriétés des objets ne peuvent être accédées que par ses
méthodes. Ainsi, la classe encapsule à la fois les attributs et les
méthodes qui permettent de manipuler les objets indépendamment
de leurs états.
• L’encapsulation permet de restreindre l’accès direct aux états et
empêche la modification de l’objet hors de ses méthodes.
• Par exemple, si vous avez une classe Voiture et que vous voulez
définir la valeur de sa propriété couleur à bleu, il vous faut passer par
une méthode par exemple definirCouleur, implémentée par le
développeur de la classe.
• Cette méthode peut restreindre les différentes valeurs de couleur.
3. Concepts de base
3.3. L'encapsulation
• L’encapsulation est donc un mécanisme qui empêche de modifier ou
d’accéder aux objets par un autre moyen que les méthodes
proposées, et de ce fait, permet de garantir l’intégrité des objets.
• L’utilisateur d’une classe n’a pas forcément à savoir de quelle façon
sont structurées les méthodes dans l’objet, ni le processus par lequel
l’objet obtient tel ou tel état.
• En interdisant l’utilisateur de modifier directement les attributs, et en
l’obligeant à utiliser les fonctions définies pour les modifier, on est
capable de s’assurer de l’intégrité des objets.
 3. Concepts de base
3.3. L'encapsulation
Dans le schéma, la boîte noire (caractérisant l'encapsulation),
• masque les détails d’implémentation des attributs et des
actions de la classe.

• Elle cache les attributs couleur, poids, prix.

• Le grand avantage de ce procédé est qu’en tant

qu’utilisateur, on n’a plus à se préoccuper de comment est
fait l’intérieur de l’objet de classe Voiture.

• On n’a plus besoin de se préoccuper sur le nombre

d’attributs dans la classe Voiture. On se contente de
connaître comment manipuler une voiture à l’aide des
services offerts par la classe.
3. Concepts de base
• L’encapsulation permet de définir des niveaux de visibilité des éléments de
la classe.
• Ces niveaux de visibilité définissent ce qu’on appelle la portée (ou encore le
périmètre) de la l’attribut/méthode.
• La portée est ainsi définie par méthode et par attribut et indique les droits
à leur accès. Il existe trois niveaux de visibilité :

1. Publique (+): les attributs publics sont accessibles à tous

2. Protégée (#): les attributs protégés sont accessibles seulement dans la classe elle-
même et aux classes dérivées.
3. Privée (-): les attributs privés sont accessibles seulement par la classe elle-même.