Stéphane GOBRON HES SO HE Arc ISIC 2015 Où en sommes nous? Plan de cours Ch.1 : OO Rappels Ch.2 : Etude de cas => le bridge DP Ch.3 : Conceptualisation, Singleton et Composite DPs Ch.4 : Decorator, State, Prototype, Proxy et Builder DPs Ch. 5 : Abstract factory, Observer, Commande, Memento et Iterator DPs 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, E. Freeman & E. Freeman, Edition O REILY 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 Maîtrise d un outil puissant Maîtrise des design patterns Langages OO
Encapsulation Héritage Surcharge & redéfinition Polymorphisme Composition 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, E. Freeman & E. Freeman, Edition O REILY
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 }; class Cfruit { public: Cfruit( typefruit fruit ); virtual ~Cfruit(); typefruit get( void ); void set( typefruit ); private: typefruit typeoffruit; }; #endif // CFRUITS_H 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 Enseignant Personne Administratif (personnel) Etudiant Personnel Vacataire Permanent (enseignant)
Héritage Relation : est un Concept Exploite les éléments commun entre les objets Personnel Personne E.g. de diagramme de classe UML du monde académique Etudiant Réutilisation en OO: Super classe / sousclasse classe de base / classe dérivée Administratif Vacataire Enseignant Permanent 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 Calcul de salaire Adresse Tarif horaire Moyenne générale salaire mensuel Nombre d heures travaillé Nom ID d un étudiant Casier de l enseignant Numéro de bureau
Héritage Attributs de classe Méthode Notez au combien de fois la méthode calculsalaire est héritée Personnel #bureau : uint +calculsalaire(mois) : double Administratif #salairemensuel : double +calculsalaire(mois) : double Personne #nom : char* #adresse : char* E.g. de diagramme de classe UML du monde académique Etudiant #moyenneg : ufloat #id : long Enseignant #casier : uint +calculsalaire(mois) : double Vacataire #tarifhorraire : double #nbheures : uint +calculsalaire(mois) : double Permanent #salairemensuel : double +calculsalaire(mois) : double 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 class Cfruit { public: Cfruit( void ); ~Cfruit( void ); } bool banana; bool apple; bool ananas; bool orange; #endif // CFRUIT_H Banana Apple Fruit #nom : char*
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 public class 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; // OK ptr = &obj_c; // Erreur, mais ok dans CCcc et toutes ses dérivées ptr = &obj_d; // Erreur, mais ok que dans CDdd 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; }; Préférer : virtual ~CPoint2D( void) Surcharge Préférer : virtual ~CCircle( void) Redéfinition
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 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 Classe Objet ClasseAttibut ObjetAttribut Autres attributs Methodes ClasseAttibut ObjetAttribut Attributs Methodes
Principes orienté objet «Open close» «Liskov substitution» «Single responsibility» «Interface segragation» «Dependency inversion» 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é http://philippe.developpez.com/articles/soliddotnet/#liv http://codingcraft.wordpress.com/tag/oop/ Principes OO «Single responsibility» «Il ne peut pas y avoir plus d une raison pour qu une classe change» Éviter la surcharge http://codingcraft.wordpress.com/tag/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 IT SIMPLE and «STUPID» to understand and as much as possible short http://codingcraft.wordpress.com/tag/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» http://codingcraft.wordpress.com/tag/oop/
UML Définition Eléments graphique Flèches Diagrammes Remarques importantes Formalisme classes et objets Formalisme Interaction et collaboration 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égories Circle centrex:int centrey:int=0 CircleA:Circle centrex:int centrey:int=0 <<interface>> TypeWriter draw() move(int X, Int Y) draw() move(int X, Int Y) keystroke() Classe Objet Interface Borrow Shapes Cas d utilisation Acteur 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 cas d utilisation Diagramme de séquence Diagramme de collaboration Diagramme étatstransitions Diagramme d activités UML Diagrammes résumé Dans ce cours Principalement diagrammes structuraux Class Objects Structure Utilisateur Implémentation Component Sequence Collaboration Comportement Statechart Activity Environnement Use Case Deployment
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» Vous