Rappels sur la Programmation objet Conception objet avancée
Cours M3105 : Conception et programmation
objet avancées
Introduction
Références: cours de D. Bouthinon, livre Design patterns — Tête la
première,
E. & E. Freeman, ed. O’Reilly
IUT Villetaneuse
2020-2021
Cours M3105 : Conception et programmation objet avancées Introduction IUT Villetaneuse
Rappels sur la Programmation objet Conception objet avancée
Plan
Rappels sur la Programmation objet
Conception objet avancée
1/14
Rappels sur la Programmation objet Conception objet avancée
Les concepts objets de base
I Classes/objets Les classes sont des modèles pour créer des objets
qui communiquent entre eux par messages (appels de méthodes)
I Encapsulation On cache (private) la structure d’un objet et on ne
révèle (public) que les fonctions (méthodes) nécessaires
I Héritage Une classe peut hériter des données et des méthodes
d’autres classes
I Polymorphisme (d’héritage) Une méthode de même signature
peut avoir des comportements (instructions) différents selon la
classe où elle est (re)définie.
2/14
Rappels sur la Programmation objet Conception objet avancée
Intérêts des concepts objets de base
I Sécurité L’encapsulation permet de protéger un objet contre des
modifications inappropriées
I Souplesse Le polymorphisme permet d’utiliser un même code sur
des objets de différentes classes
I Factorisation L’héritage permet de factoriser des données et
instructions
I Réutilisation Les notions de classe et d’héritage permettent de
réutiliser de données et du code dans différents contextes.
3/14
Rappels sur la Programmation objet Conception objet avancée
Limites des concepts objets de base
Ils ne permettent pas de garantir la conception de programmes :
I maintenables
I extensibles
I fiables
4/14
Rappels sur la Programmation objet Conception objet avancée
Objectifs
Concevoir des logiciels :
I (facilement) maintenables
I (facilement) extensibles
I fiables
I réutilisables
5/14
Rappels sur la Programmation objet Conception objet avancée
SOLID
I Responsabilité unique (Single responsibility principle) Une classe =
une et une seule responsabilité
I Ouvert/fermé (Open/Closed principle) une classe doit être ouverte à
l’extension, mais fermée à la modification
I Substitution de Liskov (Liskov substitution principle) une instance de
type A doit pouvoir être remplacée par une instance de type B, tel
que B sous-classe de A, sans que cela ne modifie la cohérence du
programme.
I Ségrégation des interfaces (Interface segregation principle) préférer
plusieurs interfaces spécifiques adaptées au besoin.
I Inversion des dépendances (Dependency inversion principle) il faut
dépendre des abstractions, pas des implémentations
6/14
Rappels sur la Programmation objet Conception objet avancée
Ouverture/fermeture (Open/Closed)
Une classe doit être ouverte aux extensions (ajouts) MAIS fermée aux
modifications (du code existant)
I Ouverture aux extensions :
I le comportement d’un module doit pouvoir être étendu
I exemple : ajout de nouvelles méthodes
I Fermeture aux modifications :
I le comportement d’un module doit pouvoir être étendu mais sans
modification de son code source.
I exemple : mise en place d’une interface
I En d’autres termes, l’ajout de fonctionnalités doit se faire en
ajoutant du code et non en éditant du code existant.
Exemple :
Une méthode privée d’une classe est fermée à la modification (aucun
autre code ne peut la détraquer) ; mais on peut ajouter des méthodes
publiques qui invoquent cette méthode privée pour étendre le
comportement des méthodes privées sans les modifier.
7/14
Rappels sur la Programmation objet Conception objet avancée
Ouverture/fermeture (Open/closed)
Principe ”open-closed” : on doit pouvoir facilement ajouter des formes à
l’application sans modifier les classes existantes –> principe respecté ?
8/14
Rappels sur la Programmation objet Conception objet avancée
Ouverture/fermeture (Open/closed)
Principe ”open-closed” : on doit pouvoir facilement ajouter des formes à
l’application sans modifier les classes existantes –> principe respecté ?
NON : éditeur non fermé aux modifications si on ajoute une forme
8/14
Rappels sur la Programmation objet Conception objet avancée
Ouverture/fermeture (Open/closed)
9/14
Rappels sur la Programmation objet Conception objet avancée
Ouverture/fermeture (Open/closed)
On peut étendre le comportement sans modifier le code : Editeur est
fermée aux modifications car la méthode dessiner() ne change pas si l’on
ajoute une nouvelle Forme. Editeur est ouverte aux extensions : toutes les
sous-classes de Forme peuvent changer le comportement de dessiner().
9/14
Rappels sur la Programmation objet Conception objet avancée
Substitution de Liskov
Un instance d’une classe doit pouvoir être substituée sans
modification par une instance d’une sous-classe (et sans que le
programme ne soit altéré dans son comportement)
Autrement dit : Si une classe B hérite d’une classe A, tout programme
écrit pour traiter des instances de A doit pouvoir traiter des instances de
B sans même savoir que ce ne sont pas des instances directes de A.
Conséquence : Ne pas introduire de modifications dans le fonctionnement
de B qui rend inutilisable tout objet de type B utilisé comme un objet de
type A.
10/14
Rappels sur la Programmation objet Conception objet avancée
Un exemple
11/14
Rappels sur la Programmation objet Conception objet avancée
Un exemple
Principe de Liskov non respecté : la méthode Test qui utilise des
instances de la classe Duck doit pouvoir utiliser des instances de la classe
dérivée ElectricDuck sans que le programme ne soit altéré dans son
comportement.
11/14
Rappels sur la Programmation objet Conception objet avancée
Que penser de cette solution ?
12/14
Rappels sur la Programmation objet Conception objet avancée
Que penser de cette solution ?
Liskov respecté mais la méthode Test a besoin de connaître le type réel
des objets pour pouvoir les traiter correctement : module non-fermée aux
modifications
12/14
Rappels sur la Programmation objet Conception objet avancée
Que penser de cette solution ?
Liskov respecté mais la méthode Test a besoin de connaître le type réel
des objets pour pouvoir les traiter correctement : module non-fermée aux
modifications –> principe open closed non respecté.... solution bientôt
12/14
Rappels sur la Programmation objet Conception objet avancée
Design patterns
I Les design patterns (patrons de conception) décrivent des procédés
généraux et réutilisables pour concevoir des logiciels
I Les design patterns mettent en œuvre les principes SOLID
I Un design pattern décrit une bonne pratique et une solution
standard en réponse à un problème de conception d’un logiciel
13/14
Rappels sur la Programmation objet Conception objet avancée
Classification des design patterns
I Création (créer des objets)
I Fabrique, Fabrique abstraite, Prototype, Singleton, Monteur
I Structure (organiser les classes)
I Décorateur, Adapteur, Façade, Pont, Objet composite,
Poids-mouche, Proxy
I Comportement (organiser la collaboration entre objets)
I Observateur, Stratégie, Commande, Médiateur, Chaîne de
responsabilité, Iterateur, Interpréteur, Etat, Patron de méthode,
Visiteur, Fonction de rappel
14/14