La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Object-Oriented Software Engineering Practical Software Development using UML and Java Chapitre 2: Review of Object Orientation.

Présentations similaires


Présentation au sujet: "Object-Oriented Software Engineering Practical Software Development using UML and Java Chapitre 2: Review of Object Orientation."— Transcription de la présentation:

1 Object-Oriented Software Engineering Practical Software Development using UML and Java Chapitre 2: Review of Object Orientation

2 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation2 2.1 Qu’est-ce que l’Orientation Objet? Paradigme procédural: Le logiciel est organisé autour de la notion de procédures Abstraction de procédures —Fonctionne bien lorsque les données sont simples Abstraction de données —Grouper ensemble les données décrivant une même entité —Aide à réduire la complexité du système Paradigme orienté objet: Les abstractions de procédures sont placées à l’intérieur des abstractions de données

3 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation3 Paradigme Orienté Objet Une approche consistant à organiser la solution d’un problème autour du concept d’objets. Ces objets sont des instances de classes: —Ce sont des abstractions de données —Contenant des abstractions de procédures Un programme devient alors un ensemble d’objets collaborant entre eux afin d’effectuer un tâche donnée

4 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation4 Illustration des ces deux paradigmes

5 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation5 2.2 Classes et Objets Un objet est un ensemble structuré de données s’exécutant dans un logiciel a des propriétés —représentant son état a un comportement —définissant ses actions et réactions —simulant parfois le comportement d’un objet du monde réel

6 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation6 Objets

7 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation7 Classes Une classe: Est une unité d’abstraction dans un programme orienté- objet Représente des objets similaires —ses instances Est un module logiciel —Décrivant la structure de ses instances (propriétés) —Contenant des méthodes définissant leur comportement

8 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation8 Classe ou instance? Quelque chose pouvant avoir des instances est une classe Quelque chose est une instance si il est l’un des éléments d’un ensemble (défini par la classe) Film Classe; ses instances sont les différents films. Bobine de Film: Classe; ses instances sont chacune des bobines existantes Bobine de film portant le numéro de série SW19876 Une instance de BobineDeFilm Science Fiction Instance de la classe Genre. Film de Science Fiction Classe; une de ses instances est le film ‘Star Wars’ Représentation du film ‘Star Wars’ au cinéma Le Phoenix à 19h: Une instance de Representation

9 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation9 Donner un nom à une classe Devrait toujours débuter par une lettre majuscule —E.g. Banque not banque Utiliser le singulier Utiliser le bon niveau de généralité —E.g. Municipalité pourrait être préférable à Ville Donner un nom non ambigu ayant un sens précis —E.g. Pièce peut avoir plusieurs sens

10 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation10 2.3 Variables d’instances Ce sont des variables définies à l’intérieur d’une classe Attributs —des données simples —E.g. nom, dateDeNaissance Associations —représentent une relation avec d’autres classes —E.g. superviseur, coursSuivis —Plus d’explications à venir au Chapitre 5

11 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation11 Variables vs. Objets Une variable Réfère à un objet Peut référer à différents objets à différents instants Un objet peut être simultanément référé par plus d’une variable Type d’une variable Détermine quelle classe d’objets elle peut référer

12 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation12 Variables de classe La valeur d’une telle variable est partagée par toutes les instances de la classe Aussi appelée variable statique Si l’une des instances modifie la valeur d’une variable de classe, alors toutes les autres instances verront ce changement Ces variables sont utiles pour: —représenter des constantes (e.g. PI) —représenter des propriétés d’appliquant à une classe en général Attention: ne pas faire un usage excessif des variables de classes

13 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation13 2.4 Méthodes, Opérations et Polymorphisme Opération Une abstraction procédurale de haut niveau correspondant à un comportement spécifique Indépendante de toute implémentation —E.g., calcul de l’aire d’une figure

14 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation14 Méthodes, Opérations et Polymorphisme Méthode Une abstraction de procédure utilisée pour implémenter un comportement dans une classe donnée Plusieurs classes différentes peuvent avoir des méthodes de même nom —Généralement c’est qu’elles réalisent la même opération d’une manière propre à chaque classe —E.g, le calcul de l’aire d’un rectangle et d’un cercle

15 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation15 Polymorphisme Une propriété importante liée au paradigme orienté- objet selon laquelle une même opération s’applique de différente façon dans différente classes Exige l’existence de plusieurs méthodes ayant le même nom La méthode qui sera exécutée par un objet dépend de la classe d’appartenance de cet objet Réduit grandement la nécessité d’insérer des énoncés de contôle tels que le if-else ou le switch

16 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation16 2.5 Organisation des Classes en Hiérarchies Super-classe contient les éléments communs à un ensemble de sous- classes Arbre d’héritage Montre la relation entre super-classes et sous-classes Le triangle est le symbole utilisé pour représenter une généralisation Héritage Le mécanisme selon lequel toutes les sous-classes possèdent implicitement les éléments de leurs super- classes

17 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation17 Un exemple d’arbre d’héritage

18 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation18 Règle “est-un(e)” La généralisation obéit toujours à une règle d’état “Un compte chèque est un compte de banque” “Un village est une municipalité” Est-ce qu’une Province devrait être une sous-classe de Pays? Non! —“Une province n’est pas un pays”

19 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation19 Un arbre d’héritage pour des entités géométriques

20 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation20 Tous les éléments hérités doivent s’appliquer adéquatement aux sous-classes

21 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation21 2.6 Héritage, polymorphisme et variables

22 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation22 Quelques opérations pour des formes géométriques

23 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation23 Classes abstraites et Méthodes abstraites Une opération doit être définie au plus haut niveau d’abstraction possible A ce niveau, l’opération peut être abstraite Dans ce cas la classe devient aussi abstraite —Aucun instance directe peut être créée —Une classe non abstraite est une classe concrète Si une classe possède une opération abstraite, l’une de ses sous-classe doit définir concrètement cette opération —Toutes les opérations d’une classe au bas de l’arbre d’héritage doivent être concrètes

24 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation24 Redéfinition Une méthode héritée peut être redéfinie Dans un but de restriction —E.g. scale(x,y) ne fonctionne pas dans Circle Dans un but d’extension —E.g. SavingsAccount peut inclure des frais additionnels dans le cas d’un retrait Dans un but d’optimization —E.g. la méthode getPerimeterLength dans Circle est beaucoup plus simple que celle de Ellipse

25 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation25 Objets immuables Les variables d’instance de tels objets ne peuvent être affectées que lors de la construction Aucune des opérations de ces objets peut changer la valeur de ces variables —E.g. dans un tel cas, la méthode scale devrait plutôt produire un nouvel objet

26 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation26 Comment se détermine la méthode qui sera exécutée 1.D’abord vérifier si il existe une définition pour cette méthode dans la classe de l’objet de référence 2.Sinon, vérifier dans la super-classe de niveau immédiatement supérieur 3.Répéter l’étape 2, en remontant les niveaux jusqu’à ce qu’une méthode concrète soit trouvée 4.Si aucune méthode concrète n’est trouvée, il y a erreur En Java et C++ une telle erreur est identifiée à la compilation

27 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation27 Liaison dynamique Se produit lorsque la décision concernant la méthode à exécuter se prend lors de l’exécution du programme Nécessaire lors que: —Une variable réfère à un objet dont la classe d’appartenance fait partie d’une hiérarchie —Et lorsque plus d’une méthode existe pour une même opération (polymorphique)

28 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation28 2.7 Concepts clé de l’orienté objet Pour qu’un langage puisse être dit orienté objet Identité —Chaque objet a une existence distincte —Deux objets demeurent distincts même si leurs variables contiennent les même valeurs Classes —Le programme s’organise en un ensemble de classes décrivant les objets qui feront partie du système Héritage —Le mécanisme permettant aux sous-classes d’hériter des propriétés et comportements de leur super-classes Polymorphisme —Le mécanisme suivant lequel il peut exister plusieurs méthodes pour la même opération

29 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation29 Concepts clé de l’orienté objet Abstraction Objet -> du monde réel Classe -> objets Super-classe -> sous-classes Opération -> méthodes Attributs et associations -> variables d’instances Modularité Le programme se construit entièrement à l’intérieur de classes Encapsulation Tous les détails sont cachés à l’intérieur des classes Principe de masquage de l’information: —Un programmeur n’a pas besoin de connaître l’intérieur d’une classe pour en faire usage

30 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation30 Le langage Java Histoire Le premier langage orienté objet fut Simula-67 —Conçu pour faciliter l’écriture de programmes de simulation Au début des années 1980, Smalltalk fut développé à Xerox PARC —Syntaxe nouvelle, importante librairie à code ouvert, indépendance de plate-forme, ramasse-miette, bytecode A la fin des années 1980, C++ fut développé par B. Stroustrup, —Tire profit des avantages de l’orienté-objet tout en profitant de la popularité de C En 1991, les ingénieurs de Sun Microsystems lance un projet afin concevoir un langage à être utilisé dans les petits appareils intelligents: Oak —Avec l’avènement de l’Internet, une nouvelle opportunité se dessine pour cette technologie —Ce nouveau langage renommé Java, fut officiellement lancé en 1995 à la conférence SunWorld ’95

31 Révision Java 1.Notions de classe 2.Attributs et méthodes 3.Objets et Instantiation 4.Les packages © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation31

32 Notion de Classe Une classe est un support d’encapsulation : c'est un ensemble de données et de fonctions regroupées dans une même entité. Une classe est une description abstraite d'un objet. Instancier une classe consiste à créer un objet Pour accéder à une classe il faut en déclarer une instance de cette classe (ou un objet). Une classe comporte sa déclaration, des variables et la définition de ses méthodes. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation32

33 Syntaxe d’une Classe modificateur class nom_classe [extends super_classe] [implements interface]{ // Insérer ici les champs et les méthodes } © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation33 ModificateurRôle publicLa classe est accessible partout privateLa classe n’est accessible qu’à partir du fichier où elle est définie finalLa classe ne peut pas être modifié. abstractLa classe contient une ou des méthodes abstraites. Une classe abstraite ne peut pas être instanciée.

34 Classe abstraite abstract class GraphicObject { int x, y; void moveTo(int newX, int newY) {... } abstract void draw(); abstract void resize(); } © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation34

35 Classe abstraite class Circle extends GraphicObject { void draw() { … } void resize() { … } © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation35

36 Attributs et Méthodes Les attributs Les données d’une classe sont contenues dans les attributs. Syntaxe générale: [modificateur de visibilité] [= ]; class Rectangle { private int longueur; protected int largeur; public Point Centre; } © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation36

37 Les variables de classe Les variables de classes sont définies avec le mot clé static. Les constantes sont définies avec le mot clé final : public class MaClasse { static int compteur; //Les variables de classe final double pi = 3.14 ; // Une constante } © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation37

38 Les méthodes Les méthodes sont des fonctions qui implémentent les traitements de la classe. Syntaxe générale modificateurs type_retourné nom_méthode ( arg1,... ) { // Définition des variables locales et du bloc d'instructions // Les instructions } © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation38

39 Exemple d’une méthode class Rectangle { private int longueur ; int largeur ; public int calcul_surface ( ) { return (longueur*largeur) ; } public void initialise (int x, int y) { longueur =x ; largeur = y ; } public static void main (String args[]) {... } } © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation39

40 Les constructeurs La déclaration d'un objet est suivie d'une sorte d'initialisation par le moyen d'une méthode particulière appelée constructeur pour que les variables aient une valeur de départ. Le constructeur n'est systématiquement invoquée que lors de la création d'un objet. Le constructeur suit la définition des autres méthodes excepté que son nom doit obligatoirement correspondre à celui de la classe. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation40

41 Exemple d’un constructeur class Rectangle { private int longueur ; private int largeur ; Rectangle () {longueur =10 ; largeur = 5 ;} // C’est un constructeur sans paramètres Rectangle (int x, int y) {longueur =x ; largeur = y ;} // constructeur avec 2 paramètres Rectangle (int x) {longueur =2*x ; largeur = x ;} // constructeur avec 1 paramètre } © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation41

42 Utilisation d’un package En java, il existe un moyen de regrouper des classe voisines ou qui couvrent un même domaine : ce sont les packages. Ex. import nomPackage.*; import java.applet.*; Avantages - Facilite le développement des bibliothèques et des modules autonomes. - Les classes d’un même package travaillent conjointement sur un même domaine. - Facilite la réutilisabilité. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation42

43 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation43 Documentation Être capable de connaître les classes et les méthodes d’un système orienté-objet est fondamental Un outil appelé Javadoc permet de construire automatiquement la documentation associée à un programme écrit en Java —Cette documentation est construite à partir du code et des commentaires écrits par le programmeur —Un format spécial doit être respecté pour les commentaires —Ceux-ci peuvent même inclure du html http://docs.oracle.com/javase/1.5.0/docs/api/index.html

44 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation44 Style de programmation Toujours garder à l’esprit qu’un programme est fait pour être lu Toujours retenir l’alternative la plus simple Écarter toute approche aussi futée soit elle, mais difficile à saisir Un programme plus court n’est pas nécessairement meilleur Choisir des noms appropriés Ils doivent être très descriptifs

45 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation45 Style de programmation Commenter Tout ce qui pourrait ne pas être évident Les commentaires peuvent représenter de 25à 50% du programme Organiser les classes de façon consistante Variables, constructeurs, méthodes publiques et méthodes privées Structurer le code de façon consistante http://java.sun.com/docs/codeconv/CodeConventions.pdf

46 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation46 Style de programmation Éviter toute duplication de code Ne pas cloner le code —Créer plutôt une méthode (privée) regroupant le code commun

47 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation47 Style de programmation Se conformer aux bons principes de l’orienté objet Minimiser le nombre de méthodes publiques Bien séparer les interfaces et l’application

48 © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation48 2.10 Risques et difficultés liés à la programmation orientée objet Les langages sont en constantes évolution http://docs.oracle.com/javase/1.4.2/docs/api/java/awt/Co mponent.html#action(java.awt.Event, java.lang.Object) L’efficacité peut être quelques fois problématique


Télécharger ppt "Object-Oriented Software Engineering Practical Software Development using UML and Java Chapitre 2: Review of Object Orientation."

Présentations similaires


Annonces Google