Processus de Développement Analyse & conception OOimad-hafidi.com/Cours/Genie/PD3.pdfConception OO Design Pattern 1 Hafidi Imad-ENSAK-Cours PD Processus de Développement Analyse

Conception OO Design Pattern

Hafidi Imad-ENSAK-Cours PD 1

Processus de Développement Analyse & conception OO

Pr Hafidi Imad [email protected]

Troisième partie


Conception Orienté Objet

But �  L'objectif de cette partie est :

�  de faire un rappel sur les connaissances acquises sur la modélisation objet.

�  d'introduire la notion de conception orientée objet par rapport à l'analyse orientée objet.

�  d'approfondir le concept d'interface. �  d'établir les deux grands principes de la conception orientée

objet �  Programmation générique plutôt que programmation spécifique �  Réutiliser par la composition plutôt que par l'héritage


Analyse et conception L'analyse consiste sur la base d'un cahier de charge de modéliser

les acteurs et le système en ne s'intéressant pas à l'implémentation. On parle d'approche Métier.

QUI (acteurs) fait QUOI (système)

La conception consiste sur la base de l'analyse à modéliser la réalisation informatique. On parle d'approche informatique :

COMMENT ?


Rappelles sur l’approche Objet �  Un objet réunit des données(attributs) et des

opérations(méthodes) qui opèrent sur ces données. �  Un objet réalise une opération lorsqu'il reçoit une

requête(ou message) de la part d'un client. �  Les requêtes sont les seuls moyens de faire exécuter une

opération. Les opérations sont les seuls moyens de modifier les données internes d'un objet.


Les grands principes de l’orienté objet �  L'encapsulation: la structure interne d'un objet n'est pas

connu de l'extérieur (intégrité garantie d'un bon développement).

�  L'héritage: une classe dite dérivée contient les attributs et opérations d'une classe existante (une façon de réutiliser).

�  Le polymorphisme est la possibilité d'envoyer une requête à un objet sans connaître de type de l'objet.


Généralité sur la conception orienté objet

La tâche essentielle et difficile de la conception orientée objet est la décomposition d'un système en

objets.


�  La difficulté tient à plusieurs facteurs conflictuels : �  Encapsulation : un objet n'est accessible de l'extérieur qu'à

travers son interface. �  Granularité :les objets sont plus ou moins fins �  Dépendance : les objets doivent communiquer entre eux �  Performance : l’exécution doit être la plus rapide possible �  Réutilisabilité : On doit pouvoir réutiliser des objets dans des

programmes différents


Des objets peuvent varier en taille. Un objet représentant une

application est plus gros qu'un objet qui représente un élément de bas niveau comme du matériel (souris, clavier) ou

un conteneur (liste, vecteur, arbre).

Comment déterminer la granularité d'un objet et par la même quelles sont ses responsabilités ?


�  Des objets peuvent représenter des entités du monde réel comme des étudiants mais d'autres n'existent pas dans la réalité comme des processus.

�  La modélisation orientée objet permet à travers une même approche (celle de l'objet) de tout représenter. L'abstraction est donc obligatoire.


Opération et interface d’un objet �  La déclaration d'une opération d'un objet est constituée

�  du nom de l'opération �  ses paramètres reçus �  du retour

�  Cet ensemble est la signature de l'opération. �  L'ensemble des signatures des opérations publiques d'un objet

est appelée interface de l'objet.


Interfaces et interface d’un objet �  Une requête d'un client à un objet x conforme à une

signature de l'interface de x peut être envoyée à x. �  Rappel : Une interface est un ensemble de déclarations

d'opérations publiques. C'est un ensemble de services. �  Rappel : Un classe réalise une interface I quand elle

implémente toutes les opérations déclarées dans I.


�  Si un objet réalise une interface I alors I est contenu dans l'interface de l'objet.

�  Un objet O peut contenir plusieurs interfaces. Deux clients peuvent utiliser différemment l'objet O. �  Le client simulateur de course de voitures a besoin de connaître

les services de fonctionnement d'une voiture. �  Le client réparateur de voiture a besoins de connaître les

services de diagnostics de pannes et d'accès aux pièces de la voiture.


�  Des objets de types différents peuvent avoir une ou plusieurs interfaces en commun. � Un simulateur de vol d'avions peut faire voler des F18 ou des

canards Colvert du moment que ces objets fournissent les services demandés par les simulateur.

�  L'ensemble des déclarations de ces services sera une interface commune entre un F18 et un canard Colvert.

�  Les objets de type F18 et de type CanardColvert réalisent cette interface.


Implémentation du polymorphisme �  Quand un client envoie une requête à un objet x, il a

simplement besoin de savoir que cet objet peut recevoir cette requête.

�  Les langages orientés objets comme le C++, Java et d'autres possèdent un mécanisme dit de liaison dynamique :

�  L'opération à exécuter suite à une requête envoyée à un objet n'est connue qu'à l'exécution.


�  Si le client utilise les services d'un objet O et que ces services sont définis dans l'interface I alors l'objet O peut être déclaré de type I.

�  Les conséquences sont : �  l'interface de O contient I. �  La classe de O doit réaliser l'interface I �  Le client ne connaît pas le vrai type de O.


1 principe de la conception orienté objet

�  En résumé : Le client peut ignorer les classes d'objets qu'il utilise pour peu que les objets contiennent les interfaces utilisées par le client. Cela nous amène au premier principe de la conception orientée objet.

Programmer pour une interface, non pour un

développement particulier


Classe abstraite �  Une classe abstraite A est une classe dont certaines

opérations sont déclarées et non définies (comme pour les interfaces)

�  On ne peut pas instancier des classes abstraites �  Les classes concrètes qui dérivent de la classe A doivent

définir les méthodes abstraites déclarées dans A.


Classe abstraite et polymorphisme �  Dans certains cas, une requête peut connaître un objet à

travers une référence d'une classe abstraite A. �  Il faut que la classe de l'objet dérive de la classe abstraite et

que l'opération soit contenue dans l'interface de la classe A.


Concevoir pour mieux réutiliser �  Deux techniques : �  L'héritage: réutilisation boîte blanche. On parle de boîte

blanche, car le contenu des classes parentes est visible aux sous classes

�  La composition: réutilisation boîte noire . On parle de boîte noire, car la nouvelle classes n'a pas accès à la représentation interne de l'objet réutilisé.


L’héritage �  L'héritage et ses principes

�  Il est défini de façon statique à la compilation �  L'utilisation dans la sous classe est immédiate �  La sous classe peut surcharger quelques opérations tout en

gardant l'accès à la version de la classe Parent. �  La sous classe dépend des changements de la classe Parent.

L'héritage rompt l'encapsulation. �  Impossibilité de modifier à l'exécution le code hérité des

parents


La composition �  La composition et ses principes

� Notation : le nouvel objet sera appelé objet composé. �  La composition est définie dynamiquement à l'exécution �  L'accès des objets (composants) entrant dans la composition se

fait par l'intermédiaire d'une de leurs interfaces. �  L'encapsulation des composants est totalement respectée � A l'exécution, chaque composant peut être remplacé par un

autre composant pourvu que le nouveau composant contienne l'interface utilisée.

�  Il faut que les composants contiennent les interfaces utilisées dans l'objet composé.


2 principe de la conception orienté objet

Pour la réutilisabilité, savoir différencier

l'héritage sémantique de l'héritage fonctionnel

S'il s'agit uniquement d'un héritage fonctionnel , il faut impérativement

utiliser la composition.



Designs Pattern

Objectifs


�  Modularité �  Facilité de gestion (technologie objet)

�  Cohésion � Degré avec lequel les tâches réalisées par un seul module sont

fonctionnellement reliées � Une forte cohésion est une bonne qualité

�  Couplage � Degré d’interaction entre les modules dans le système � Un couplage ’’ lâche’’ est une bonne qualité

�  Réutilisabilité �  Bibliothèques, frameworks (cadres)

Cohésion : Mauvais exemple


Cohésion : bon exemple


Couplage : exemple


Exemple : Tri Etudiants


Solution 1


Solution 2


Définition : Pattern


Un patron décrit à la fois un problème qui se produit très fréquemment dans l’environnement et l’architecture de la solution à ce problème de telle façon que l’on puisse utiliser cette solution des milliers de fois sans jamais l’adapter deux fois de la même manière.

Décrire avec succès des types de solutions récurrentes à des problèmes communs dans des types de situations


�  Documentation d’une expérience éprouvée de conception �  Identification et spécification d ’abstractions qui sont au

dessus du niveau des simples classes, instances �  Vocabulaire commun et aide à la compréhension de principes

de conception �  Moyen de documentation de logiciels �  Aide à la construction de logiciels répondant à des propriétés

précises, de logiciels complexes et hétérogènes �  Traductions : patrons de conception, schémas de conception

Catégories de Pattern


�  Architectural Patterns �  schémas d’organisation structurelle de logiciels (pipes, filters, brokers,

blackboard, MVC, …) �  Design Patterns

�  caractéristiques clés d’une structure de conception commune à plusieurs applications,

�  Portée plus limitée que les « architectural patterns » �  Idioms ou coding patterns

�  solution liée à un langage particulier �  Anti-patterns

�  mauvaise solution ou comment sortir d ’une mauvaise solution �  Organizational patterns

�  Schémas d’organisation de tout ce qui entoure le développement d’un logiciel (humains)

Catégories de Design Pattern


�  Création �  Description de la manière dont un objet ou un ensemble d’objets

peuvent être créés, initialisés, et configurés �  Isolation du code relatif à la création, à l’initialisation afin de rendre

l’application indépendante de ces aspects �  Structure

�  Description de la manière dont doivent être connectés des objets de l’application afin de rendre ces connections indépendantes des évolutions futures de l’application

�  Découplage de l’interface et de l’implémentation de classes et d’objets

�  Comportement �  Description de comportements d’interaction entre objets �  Gestion des interactions dynamiques entre des classes et des objets

Présentation d’un Design Pattern


�  Nom du pattern �  utilisé pour décrire le pattern, ses solutions et les conséquences en

un mot ou deux �  Problème

�  description des conditions d ’applications. Explication du problème et de son contexte

�  Solution �  description des éléments (objets, relations, responsabilités,

collaboration) permettant de concevoir la solution au problème ; utilisation de diagrammes de classes, de séquences, …

�  vision statique ET dynamique de la solution �  Conséquences

�  description des résultats (effets induits) de l ’application du pattern sur le système (effets positifs ET négatifs)


Designs Pattern de création

Design Pattern de création


�  Rendre le système indépendant de la manière dont les objets sont créés, composés et représentés �  Encapsulation de la connaissance des classes concrètes à utiliser � Cacher la manière dont les instances sont créées et combinées

�  Permettre dynamiquement ou statiquement de préciser QUOI (l’objet), QUI (l’acteur), COMMENT (la manière) et QUAND (le moment) de la création

�  Deux types de motifs �  1. Motifs de création de classe (utilisation de l’héritage) :

Factory �  2. Motifs de création d’objets (délégation de la construction à

un autre objet) : AbstractFactory, Builder, Prototype

Singleton �  Problème

�  avoir une seule instance d’une classe et pouvoir l’accéder et la manipuler facilement

�  Solution �  une seule classe est nécessaire pour écrire ce motif

�  Conséquences �  l’unicité de l’instance est complètement contrôlée par la classe

elle même. Ce motif peut facilement être étendu pour permettre la création d’un nombre donné d’instances

39 Hafidi Imad-ENSAK-Cours PD


Exemple : Labyrinthe



Factory Méthode �  Problème

�  ce motif est à utiliser dans les situations où existe le besoin de standardiser le modèle architectural pour un ensemble d’applications, tout en permettant à des applications individuelles de définir elles-mêmes leurs propres objets à créer

�  Conséquences � + Elimination du besoin de code spécifique à l’application dans

le code du framework (uniquement l’interface du Product) �  – Multiplication du nombre de classes


Solution



Abstract Factory


�  Problème �  ce motif est à utiliser dans les situations où existe le besoin de travailler avec

des familles de produits tout en étant indépendant du type de ces produits doit être configuré par une ou plusieurs familles de produits

�  Conséquences �  +Séparation des classes concrètes, des classes clients

�  les noms des classes produits n’apparaissent pas dans le code client �  Facilite l’échange de familles de produits �  Favorise la cohérence entre les produits

�  + Le processus de création est clairement isolé dans une classe �  – la mise en place de nouveaux produits dans l’Abstract Factory n’est pas

aisée

�  • Exemple �  java.awt.Toolkit



Builder


�  Problème �  ce motif est intéressant à utiliser lorsque l’algorithme de création

d’un objet complexe doit être indépendant des constituants de l’objet et de leurs relations, ou lorsque différentes représentations de l’objet construit doivent être possibles

�  • Conséquences �  + Variation possible de la représentation interne d’un produit

�  l’implémentation des produits et de leurs composants est cachée au Director �  Ainsi la construction d’un autre objet revient à définir un nouveau Builder

�  + Isolation du code de construction et du code de représentation du reste de l’application

�  + Meilleur contrôle du processus de construction




Prototype


�  Problème �  Le système doit être indépendant de la manière dont ses

produits sont créés, composés et représentés : les classes à instancier sont spécifiées au moment de l’exécution

�  La présence de hiérarchies de Factory similaires aux hiérarchies de produits doivent être évitées. Les combinaisons d’instances sont en nombre limité

�  Conséquences � mêmes conséquences que Factory et Builder

�  • Exemple �  java.lang.Cloneable


Bilan ; Labyrinthe


�  Abstract Factory : CreateMaze a un objet en paramètre utilisé pour créer les composants du labyrinthe, on peut changer les composants de la structure du labyrinthe en passant un autre paramètre

�  Builder : CreateMaze a un objet paramètre capable de créer lui même un labyrinthe dans sa totalité, il est possible de changer la structure du labyrinthe en dérivant un nouvel objet

�  Factory: CreateMaze appelle des fonctions virtuelles au lieu de constructeurs pour créer les composants du labyrinthe, il est alors possible de modifier la création en dérivant une nouvelle classe et en redéfinissant ces fonctions virtuelles

�  Prototype : CreateMaze est paramétré par des composants prototypiques qu’il copie et ajoute au labyrinthe, il est possible de changer la structure du labyrinthe en fournissant d’autres composants

Résumé


�  Le Factory Pattern est utilisé pour choisir et retourner une instance d ’une classe parmi un nombre de classes similaires selon une donnée fournie à la factory

�  Le Abstract Factory Pattern est utilisé pour retourner un groupe de classes

�  Le Builder Pattern assemble un nombre d’objets pour construire un nouvel objet, à partir des données qui lui sont présentées. Fréquemment le choix des objets à assembler est réalisé par le biais d’une Factory

�  Le Prototype Pattern copie ou clone une classe existante plutôt que de créer une nouvelle instance lorsque cette opération est coûteuse

�  Le Singleton Pattern est un pattern qui assure qu’il n’y a qu’une et une seule instance d’un objet et qu’il est possible d’avoir un accès global cette instance


Designs Pattern de structure

Design Pattern de structure


�  Abstraction de la manière dont les classes et les objets sont composés pour former des structures plus importantes.

�  Deux types de motifs : � Motifs de structure de classes

�  Utilisation de l’héritage pour composer des interfaces et/ou des implémentations (ex : Adapter).

� Motifs de structure d’objets �  composition d’objets pour réaliser de nouvelles fonctionnalités :

�  ajouter d’un niveau d’indirection pour accéder à un objet ex : Adapter d’objet, Bridge, Facade, Proxy,

�  composition récursive pour organiser un nombre quelconque d’objets ex : CompositeDesign

Adapter


�  Problème �  Utilisation d’une classe existante dont l’interface ne nous convient

pas (convertir l’interface d’une classe en une autre) �  Utilisation de plusieurs sous-classes dont l’adaptation des interfaces

est impossible par dérivation (Object Adapter) �  Conséquences

�  – Adapter de classe �  + il n’introduit qu’une nouvelle classe, une indirection vers la classe adaptée

n’est pas nécessaire �  MAIS il ne fonctionnera pas dans le cas où la classe adaptée est racine d’une

dérivation �  – Adapter d’objet

�  + il peut fonctionner avec plusieurs classes adaptées �  MAIS il peut difficilement redéfinir des comportements de la classe adaptée



Bridge


�  Problème �  ce motif est à utiliser lorsque l’on veut découpler

l’implémentation de l’abstraction de telle sorte que les deux puissent varier indépendamment

�  • Conséquences � + interfaces et implémentations peuvent être couplées/

découplées lors de l’exécution


Composite


�  Problème �  établir des structures arborescentes entre des objets et les traiter

uniformément �  • Conséquences

�  + hiérarchies de classes dans lesquelles l’ajout de nouveaux composants est simple

�  + simplification du client qui n’a pas à se préoccuper de l’objet accédé

�  – MAIS il est difficile de restreindre et de vérifier le type des composants

�  • Exemple �  java.awt.Component �  java.awt.Container


Exercice : composite


�  Chacun des membres de la compagnie reçoit un salaire. � A tout moment, il doit être possible de demander le coût d’un

employé. �  Le coût d’un employé est calculé par :

�  Le coût d’un individu est son salaire. �  Le coût d’un responsable est son salaire plus celui de ses subordonnés.

Façade


�  Problème �  ce motif est à utiliser pour faciliter l’accès à un grand nombre

de modules en fournissant une couche interface

�  Conséquences � + facilite l’utilisation de sous-systèmes � + favorise un couplage faible entre des classes et l’application �  – MAIS des fonctionnalités des classes interfacées peuvent être

perdues selon la manière dont est réalisée la Façade


Proxy



�  Problème �  ce motif est à utiliser pour agir par procuration pour un objet

afin de contrôler les opérations qui lui sont appliquées � Masquer des problèmes d’accès (ex : fichier) � Différer l’exécution d’opérations coûteuses �  Contrôler les droits d’accès

�  Conséquences � + ajout d’un niveau d’indirection lors de l’accès d’un objet

permettant de cacher le fait que l’objet est dans un autre espace d’adressage, n’est pas créé, …



Designs Pattern de comportement

Design Pattern de comportement


�  Description de structures d’objets ou de classes avec leurs interactions

�  Deux types de motifs �  Motifs de comportement de classes :

�  utilisation de l’héritage pour répartir les comportements entre des classes (ex : Interpreter)

�  Motifs de comportement d’objets avec l’utilisation de l’association entre objets : �  pour décrire comment des groupes d’objets coopèrent (ex : Mediator) �  pour définir et maintenir des dépendances entre objets (ex : Observer) �  pour encapsuler un comportement dans un objet et déléguer les requêtes à

d’autres objets (ex : Strategy, State, Command) �  pour parcourir des structures en appliquant des comportements (ex : Visitor,

Iterator)

Command


�  Problème �  on veut effectuer des requêtes sur des objets sans avoir à

connaître leur structure

�  Conséquences � + découplage entre l’objet qui appelle et celui qui exécute � + l’ajout de nouvelles commandes est aisée dans la mesure où la

modification de classes existantes n’est pas nécessaire



Iterator


�  Problème �  ce motif est à utiliser pour parcourir une collection d’éléments

sans accéder à sa structure interne

�  Conséquences � + des variations dans le parcours d’une collection sont

possibles, � + simplification de l’interface de la collection � + plusieurs parcours simultanés de la collection sont possibles


Momento


�  Problème �  on veut sauvegarder l’état ou une partie de l’état d’un objet

sans violer le principe d’encapsulation

�  Conséquences � + garder les limites de l’encapsulation �  – peut-être coûteux en mémoire et en exécution




Observer


�  Problème �  on veut assurer la cohérence entre des classes coopérant entre

elles tout en maintenant leur indépendance �  Conséquences

� + couplage abstrait entre un sujet et un observeur, support pour la communication par diffusion,

�  – MAIS des mises à jour inattendues peuvent survenir, avec des coûts importants.

�  • Exemple �  java.util.Observable �  java.util.Observer



State


�  Problème �  ce motif est à utiliser lorsque l’on veut qu’un objet change de

comportement lorsque son état interne change

�  • Conséquences �  possibilité d’ajouter ou de retirer des états et des transitions de

manière simple �  suppression de traitements conditionnels �  les transitions entre états sont rendues explicites


Strategy


�  Problème �  on veut :

�  définir une famille d’algorithmes, �  encapsuler chacun et les rendre interchangeables tout en assurant que

chaque algorithme peut évoluer indépendamment des clients qui l’utilisent

�  • Conséquences �  + Expression hiérarchique de familles d’algorithmes, élimination de

tests pour sélectionner le bon algorithme, laisse un choix d’implémentation et une sélection dynamique de l’algorithme

�  – Les clients doivent faire attention à la stratégie, surcoût lié à la communication entre Strategy et Context, augmentation du nombre d’objets


Visitor


�  Problème �  Des opérations doivent être réalisées dans une structure

d’objets comportant des objets avec des interfaces différentes �  Plusieurs opérations distinctes doivent être réalisées sur des

objets d’une structure �  La classe définissant la structure change rarement mais de

nouvelles opérations doivent pouvoir être définies souvent sur cette structure

�  • Conséquences � + l’ajout de nouvelles opérations est aisé � + union de différentes opérations et séparations d’autres �  – MAIS l’ajout de nouvelles classes concrètes est freinée



Documents

Processus de Développement Analyse & conception OOimad-hafidi.com/Cours/Genie/PD3.pdfConception OO Design Pattern 1 Hafidi Imad-ENSAK-Cours PD Processus de Développement Analyse