Conception Orientée

Objets Avancée
A.U. 2017-2018
Faculté des sciences économiques et de gestion de Sfax

1
Plan

 Chapitre 1 : Rappel (diagrammes de UC, d’activité, de classes,

d’interactions, de paquetages et d’états )

 Chapitre 2 : Les principes de COO

 Chapitre 4 : Patrons de conception

 Chapitre 5 : Architectures logicielles

2
Chapitre 2 : les principes
de conception SOLID

3
 Quand les besoins (fonctionnels ou techniques) des utilisateurs
changent ou évoluent , on sera amené à modifier la conception de
l’application

 La conception devient de moins en moins maintenable et évolutive

 Elle devient submergée par des "horreurs"

 Les dégradations de la conception sont liées aux changements des

exigences envers l’application,

 Elle sont dues aux dépendances et à l’architecture des dépendances :

rigidité, fragilité et non réutilisabilité

4
Objectifs de la COO
 Objectifs d’une bonne conception OO :
 Produire des conceptions évolutives, maintenables
 Eviter d’obtenir un code rigide, fragile et/ou non réutilisable

 Atteindre ces objectifs nécessite de:

 suivre les principes de conception OO,
 Réutiliser l’expérience des autres (frameworks, patrons, …)
 Avoir de l’expérience

5
Couplage fort/Couplage faible
 Couplage fort
 Quand une classe A est liée à une classe B, on dit que la classe A est
fortement couplée à la classe B.
 La classe A ne peut fonctionner qu’en présence de la classe B.
 Si une nouvelle version de la classe B (soit B2), est créée, on est obligé de
modifier dans la classe A.

6
 …Couplage fort/Couplage faible
 Pour modifier une classe :
 Il faut disposer du code source.
 Il faut recompiler, déployer et distribuer la nouvelle application aux clients.
 On risque d’avoir des problèmes au niveau de la maintenance de
l’application

7
 …Couplage fort/Couplage faible
 Exemple :

La méthode
calculerStatistique( )
appelle
getTempératures ( )

8
 …Couplage fort/Couplage faible
 Couplage faible :
 Pour utiliser le couplage faible, nous devons utiliser les interfaces.
 Considérons une classe A et une classe B qui implémente une interface IB.
Si A est liée à l’interface IB par une association, on dit que A et B sont liées
par un couplage faible.

9
 …Couplage fort/Couplage faible
 Exemple :

10
Principes de la COO
 Références :

Martin Fowler Barbara Liskov Robert C. Martin Bertrand Meyer

(Uncle Bob)

11
…Principes de la conception OO

12
 …Principes de la conception OO
 Single Responsibility Principle : Principe de responsabilité unique

 Open-Closed Principle : Principe d'ouverture / fermeture

 Liskov Substitution Principle :Principe de substitution de Liskov

 Interface Segregation Principle :Principe de ségrégation des

interfaces

 Dependency Inversion Principle :Principe d'inversion des

dépendances

13
 Principe de responsabilité unique
 Un module (classe, méthode, paquetage, etc.) devrait n’avoir
qu’une responsabilité unique.

 Un module ne devrait jamais avoir plus d'une raison de changer.

14
15
 Une classe qui respecte le SRP est
 fortement cohésive. La cohésion (la cohésion fonctionnelle) est une mesure
de l’étroitesse des liens et de la spécialisation des responsabilités d’une
classe (ou d’élément).
 facile à comprendre
 facile à réutiliser
 facile à maintenir
 robuste (contrairement aux classes fragiles, constamment affectées par le
changement)

16
Principe d’ouverture-fermeture
 Un code doit être ouvert à l’extension mais fermée à la
modification

 Nous devons pouvoir ajouter une nouvelle fonctionnalité en

ajoutant du nouveau code et non en modifiant le code existant.

17
…Principe d’ouverture-fermeture

18
19
Principe de substitution de Liskov
 Les instances d’une classe doivent être remplaçables par des
instances de leurs sous-classes sans altérer l’application.

20
21
Principe de ségrégation des interfaces
 Les clients d’une interface ne doivent pas être obligés de dépendre
de méthodes (de cette interface) qu’ils n’utilisent pas.

 Un client doit avoir des interfaces avec uniquement ce dont il a

besoin
 Incite à avoir des interfaces petites pour ne pas forcer des classes à
implémenter les méthodes qu’elles ne veulent pas.
 Peut amener à une multiplication excessive du nombre d'interfaces!
 Incite à ne pas faire "extract interface" sans réfléchir

22
 …Principe de ségrégation des interfaces
 Exemple :

23
24
25
Principe d’inversion des dépendances
 Réduire les dépendances sur les classes concrètes

 Les classes de haut niveau ne doivent pas dépendre de classes de

bas niveau. Les deux ne doivent dépendre que d’abstractions.

 Les abstractions ne doivent pas dépendre de details. Les details

doivent dépendre d’abstractions.

26
 …Principe d’inversion des dépendances
 Exemple :

27