COO - Conception Orientée Objets Avancée

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
 Exemple :
La méthode
calculerStatistique( )
appelle
getTempératures ( )
8
 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
 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

COO - Conception Orientée Objets Avancée

Transféré par

Droits d'auteur :

Formats disponibles

COO - Conception Orientée Objets Avancée

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

COO - Conception Orientée Objets Avancée

Transféré par

Droits d'auteur :

Formats disponibles

Conception Orientée

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

 Chapitre 2 : Les principes de COO

 Chapitre 4 : Patrons de conception

 Chapitre 5 : Architectures logicielles

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

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

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

 Atteindre ces objectifs nécessite de:

Martin Fowler Barbara Liskov Robert C. Martin Bertrand Meyer

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

 Liskov Substitution Principle :Principe de substitution de Liskov

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

 Dependency Inversion Principle :Principe d'inversion des

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

 Nous devons pouvoir ajouter une nouvelle fonctionnalité en

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

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

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

Vous aimerez peut-être aussi