HES SO Arc...Design Patterns OOP & UML –Rappels Conception Objet Encapsulation Réécrire en 5 min...

Stéphane GOBRONHES‐SO – HE‐Arc – ISIC

2015

Design Patterns

Où en sommes‐nous?

Plan de cours

Ch.1 : OO‐Rappels

Ch.2 : Etude de cas => le bridge DP

Ch.3 : Conceptualisation, Singleton et CompositeDPs

Ch.4 : Decorator, State, Prototype, Proxy et Builder DPs

Ch. 5 : Abstract factory, Observer, Commande, Memento et IteratorDPs

Mots clés du cours

Conception OO et UML –rappels

Conception OO Encapsulation, héritage,

surcharge, redéfinition, polymorphisme, composition, principes OO

UML Définition, élément graphique,

flèches, diagrammes, remarques importantes, formalisme

Tête la première Design Patterns,

E. F

reem

an & E. F

reem

an, E

dition O

’REILY®

Design Patterns

OOP & UML – Rappels

Conception OO

OO: orientée objet

/!\ C++ OrientéObjet Java ou C#

programmation objet

Propriétés

Encapsulation Héritage Surcharge Redéfinition Polymorphisme Composition Principe Open‐close

Vous

Langages OO

Maîtrise d’un outil puissant

Maîtrise des design patterns

Design PatternsOOP & UML – Rappels

Conception Objet

Encapsulation Héritage Surcharge & redéfinition Polymorphisme Composition


Conception Objet

Encapsulation

Ne proposer que des méthodes de manipulation de objet

Protéger l'information contenu dans un objet

Propriétés associées aux informations d’un objet assurés/validés par les méthodes

De l'extérieur, l’objet est une boîte imperméable T

ête la première Design Patterns,

E. F

reem

an & E. F

reem

an, E

dition O

’REILY®


Conception Objet

Encapsulation

Réécrire en 5 min la classe Cfruit de telle façon à ce que ces informations soient encapsulées

Encapsulez les données d’une façon cohérente

Indice! La structure actuelle

de la classe est simple mais médiocre ; vous devez la changer.

#ifndef CFRUIT_H#define CFRUIT_H

class Cfruit{public:

Cfruit( void );~Cfruit( void );

bool banana;bool apple;bool ananas;bool orange;

};

#endif // CFRUIT_H

#ifndef CFRUITS_H#define CFRUITS_H

enum typeFruit{ banana, apple, ananas, orange };


Cfruit( typeFruit fruit );virtual ~Cfruit();typeFruit get( void );void set( typeFruit );

private:typeFruit typeOfFruit;

};

#endif // CFRUITS_H


Conception Objet

Héritage

Designer en 5 min le diagramme de classe UML décrivant les différentes personnes travaillant dans le monde académique avec le vocabulaire ci‐à‐droite

Indice! Vous devez avant tout

trouver la structure hiérarchique entre élément de vocabulaire

Personne

PersonnelEtudiant

Vacataire

Enseignant

Permanent (enseignant)

Administratif (personnel)


Conception Objet

Héritage

Relation : “est‐un” Concept Exploite les éléments

commun entre les objets

Réutilisation en OO: Super‐classe / sous‐

classe classe de base / classe

dérivée

E.g. de diagramme de classe UML du monde

académique

Personne________________

Etudiant_________________

Personnel_________________________

Administratif_________________________

Enseignant_________________________

Vacataire_________________________

Permanent_________________________


Conception Objet

Héritage

En 5 min ajouter au diagramme de classe les informations ci‐à‐droite qui définissent les informations et fonctionnalités de cette structure

Indice! Attention, information

et fonctionnalité ne sont pas de même nature

On part du principe que les enseignants permanent sont à 100% et sont tous payé au même tarif horaire

Adresse

Nombre d’heures travaillé ID d’un

étudiant

Nom

Calcul de salaire

salaire mensuel

Tarif horaire

Moyenne générale

Numéro de bureau

Casier de l’enseignant


Conception Objet

Héritage

Attributs de classe

Méthode

Notez au combien de fois la méthode calculSalaire est héritée

E.g. de diagramme de classe UML du monde

académique

Personne________________#nom : char*#adresse : char*

Etudiant_________________#moyenneG : ufloat#id : long

Personnel_________________________#bureau : uint+calculSalaire(mois) : double

Administratif_________________________#salaireMensuel : double+calculSalaire(mois) : double

Enseignant_________________________#casier : uint+calculSalaire(mois) : double

Vacataire_________________________#tarifHorraire : double#nbHeures : uint+calculSalaire(mois) : double

Permanent_________________________#salaireMensuel : double+calculSalaire(mois) : double


Conception Objet

Héritage

Développer en deux étapes et en 2 min la classe Cfruit d’une façon bien plus… hiérarchisée !

Etape 1: designer le schéma de classe UML

Etape 2: écrire le programme correspondant

Indice! Il est a parier que

l’héritage jouera son rôle…

#ifndef CFRUIT_H#define CFRUIT_H


Cfruit( void );~Cfruit( void );

bool banana;bool apple;bool ananas;bool orange;

}

#endif // CFRUIT_H

Fruit________________#nom : char*

Banana_________

Apple_________

…_________


Conception Objet

Héritage

Visibilité de la classe mère

Notons bien que C++ n’est pas un langage objet, mais orienté objet

class CAaa { ... };

// Héritage publicclass CBbb : public CAaa { ... };

// Héritage protégéclass CCcc : protected CAaa { ... };

// Héritage privéclass CDdd : private CAaa { ... };

int main(){

CBbb obj_b; CCcc obj_c; CDdd obj_d;CAaa* ptr;

ptr = &obj_b; // OKptr = &obj_c; // Erreur, mais ok dans CCcc et toutes ses dérivéesptr = &obj_d; // Erreur, mais ok que dans CDdd

}


Conception Objet

Surcharge & Redéfinition

Définir plus d'une fonction avec le même nom

/!\ signature différentes dans une même classe

Signature nom de la méthode nombre et type de

paramètre

/!\ l’ordre est important

class CPoint2D{public:

CPoint2D( const double x, const double y );~CPoint2D( void );void draw( void ) { DEF_1 ; }void draw( double size ) { DEF_2 ; }

protected:private:

double x;double y;

};

class CCircle: public CPoint2D{public:

CCircle( const double x, const double y, const double radius );~CCircle( void );void draw( void ) { DEF_3 ; }

private:double raduis;

};

Redéfinition

Surcharge

Préférer : virtual~CPoint2D( void)

Préférer : virtual~CCircle( void)


Conception Objet

Polymorphisme

Définition naturelle propriété de ce qui se

présente sous diverses formes

Permet aux objets de collaborer

entre eux sans savoir d’avance leurs types!

de traiter les objets du mêmes genres de la même manière

objets avec la même interface traités de la même manière objets de types différents traités de la même manière s’ils ont un héritage commun


Conception Objet

Composition

Objet qui référence un autre objet attribut

Un objet client avec un attribut compte

Un objet Forme Géométrique avec un attribut couleur

ClasseObjet

ClasseAttibutObjetAttributAutres attributs…Methodes…

ClasseAttibutObjetAttribut

Attributs…Methodes…


Principes orienté objet

«Open‐close» «Liskov substitution» «Single responsibility» «Interface segragation» «Dependency inversion»

Design PatternsConception Objet

Principes OO

«Open‐close»

« Tout code informatique – classes, modules, méthodes, etc. – doit être ouvert à l’extension mais fermé à la modification »

Pour une maintenance efficace

http://codingcraft.wordpress.com/tag

/oop/


Principes OO

«Liskov substitution»

Déf. officielle de Barbara Liskoy et Jeannette Wing : « Si q(x) est une propriété démontrable pour tout objet x de type T, alors q(y) est vraie pour tout objet y de type S tel que S est un sous‐type de T »

Autre définition moins formelle mais un peu moins juste : tout objet de super classe peut être remplacé par un objet de sa classe fille sans altérer les propriétés désirables du programme concerné


/oop/

http://philippe.developpez.com/articles/SOLIDdotNet/#LIV


Principes OO

«Single responsibility»

«Il ne peut pas y avoir plus d’une raison pour qu’une classe change»

Éviter la surcharge


/oop/


Principes OO

«Interface segragation»

«Les clients ne doivent être obligés de dépendre d’interface qu’ils n’utilisent pas»

Concept du «bisou»

KISSs : KEEP ITSIMPLE and «STUPID» to understand and as much as possible sHORT


/oop/


Principes OO

«Dependency inversion»

«Les modules de hauts niveaux ne doivent pas dépendre des modules de bas niveaux. Les deux doivent avoir leur abstraction»

«L’abstraction ne doit pas dépendre de détails mais les détails doivent dépendre d’abstraction»


/oop/


UML

Définition Eléments graphique Flèches Diagrammes Remarques importantes Formalisme –classes et objets Formalisme –Interaction et collaboration

Design Patterns

OOP & UML – Rappels

UML: Définition

Langage graphique décrivant les résultats du travail d’analyse et de conception orienté‐objets

Modèles fonctionnels, dynamiques ou statiques

Modèles du système visualisés par des schémas

UML: Unified Modeling Language


UML

Elément graphique

Six catégoriescentreX:IntcentreY:Int=0

Circle

draw() move(Int X, Int Y)

centreX:IntcentreY:Int=0

CircleA:Circle

draw() move(Int X, Int Y)

Classe Objet

<<interface>>TypeWriter

keyStroke()

Interface

Borrow

Cas d’utilisation Acteur

Shapes

Composant


UML

Flèches

Discussion avec le document distribué

Document distribué


UML

Diagrammes

2 familles Structuraux Comportementaux

Structuraux

Diagramme de classes “paquetages”

Diagramme d’objets

Diagramme de composants

Diagramme de déploiement

Comportementaux

Diagramme des casd’utilisation

Diagramme de séquence

Diagramme de collaboration

Diagramme états‐transitions

Diagramme d’activités

Utilisateur


UML

Diagrammes – résumé

Dans ce cours

Principalement diagrammes structuraux

ComponentDiagrams

DeploymentDiagrams

Use CaseDiagrams

ClassDiagrams

ObjectsDiagrams

ActivityDiagrams

StatechartDiagrams

CollaborationDiagrams

SequenceDiagrams

Implémentation

EnvironnementComportement

Structure


UML

Remarques importantes

UML est un langage de modélisation, mais ce n’est pas une garantie de bonne modélisation

Les diagrammes UML ne sont pas tous obligatoires

Chaque diagramme apporte une vision et une information complémentaire aux autres

Le processus est itératif

Chaque diagramme peut être utilisé à divers endroits et peut être raffiné progressivement


UML

Formalisme (1)

Classes et objets


UML

Formalisme (2)

Interaction et collaboration

Merci, question?

Chapitre suivant :

Etude de cas Spécification Objectifs Diagramme de classe Code C++ Nouvelle spécification Diagramme de classe II Diagramme de séquence Meilleure structure Explosion des classes Constat Composition Abstraction et implémentation Pattern « Bridge »

Design PatternsVous

HES SO Arc...Design Patterns OOP & UML –Rappels Conception Objet Encapsulation Réécrire en 5 min...

Documents

Transcript of HES SO Arc...Design Patterns OOP & UML –Rappels Conception Objet Encapsulation Réécrire en 5 min...