Vous êtes sur la page 1sur 73

Chapitre 1 UML: Notions de base

Responsable de cours : Sahar GHRAB


Année universitaire : 2023/2024
Discipline : 1MR-SII

1
Plan

Rappel d’UML
Rappel de la Programmation orientée Objet
(POO)
Les design patterns (patron de conception)

2
Introduction
• L’approche objet est la dernière proposition dans l’Analyse
et la Conception des SI, elle permet :
- Intégrer dans l'objet des données et des traitements.
- Profiter des avantages des concepts objet pour la
conception.
- Prendre en compte une plus large gamme d'applications.
- Favoriser la conception et la réutilisation de composants.
- Améliorer la productivité et la rentabilité des concepteurs.
- Faciliter le prototypage.
- Simplifier le passage Conceptuel / Physique

3
UML
• UML est un langage de modélisation unifié: en
réponse à divers concepts utilisés, divers modèles
proposés, diverses démarches suivies, diverses
notations graphiques supportées et diverses
sémantiques accordées aux mêmes concepts.
– regroupe les plus récentes propositions dans :
• Concepts de modélisation des données.
• Modélisation des processus d’affaires (WorkFlow).
• Modélisation objet.
• Modélisation des composants.
– peut être associé à toute démarche de conception :
• à n’importe quelle étape de la démarche.
• avec différents environnements de programmation.

4
UML
• C’est le langage de modélisation standard le plus utilisé
• Il permet d’aller au delà des modèles simplement
structurels Entités/Relations.
• Il permet de documenter les travaux.
• C’est un très bon outil de communication des travaux
(spécification fonctionnelle, dossier de conception, …).
• Chaque type de diagramme UML :
• possède une structure :
– les types des éléments de modélisation (concepts)
qui le composent sont prédéfinis
• véhicule une sémantique précise :
– un type de diagramme offre toujours la même vue
d'un système
5
UML

6
UML
• Les 9 diagrammes d’UML (1.3) :
– 5 diagrammes structurels (Vue (modèle) statique du système) :
• de cas d'utilisation,

}
• d'objets,
• de classes,
• de composants et de quoi est fait le système ?
• de déploiement.
– 4 diagrammes comportementaux (Vue ou modèle dynamique) :
• de collaboration,
• de séquence,
}
• d'états-transitions et
• d'activités.
comment se comporte le système ?

(on peut avoir : vue statique, vue dynamique et vue fonctionnelle)

7
UML
• Les différents types de diagrammes UML combinés :
– offrent une vue complète des aspects statiques et
dynamiques d'un système.
• Les diagrammes UML supportent l'abstraction :
– Leur niveau de détail caractérise le niveau
d'abstraction du modèle
• La structure des diagrammes UML et la notation
graphique des éléments de modélisation sont
normalisées (document "UML notation guide").
• La sémantique des éléments de modélisation et de leur
utilisation est définie par le métamodèle UML
(document "UML semantics") (voir WWW. omg.org)
8
UML: diagramme de cas d’utilisation

9
UML: diagramme de classes
• Le diagramme de classes exprime la structure statique
du système.
• Il englobe l’ensemble
– Classes + relations entre les classes.
– Interfaces, paquetages + leurs relations.
• Une classe décrit un groupe d’objets ayant les mêmes
propriétés (attributs), un même comportement
(opérations), et une sémantique commune (domaine
de définition).
• Un objet est une instance d’une classe. La classe
représente l’abstraction de ses objets.
• Au niveau de l’implémentation, c’est-à-dire au cours de
l’exécution d’un programme, l’identificateur d’un objet
correspond une adresse mémoire. 10
UML: diagramme de classes

Un attribut est une propriété élémentaire d’une classe. Pour


chaque objet d’une classe, l’attribut prend une valeur (sauf cas
d’attributs multivalués)
Une opération est une fonction applicable aux objets d’une
classe. Une opération permet de décrire le comportement d’un
objet. Une méthode est l’implémentation d’une opération.

Un stéréotype constitue un moyen de classer les éléments de la modélisation. 11


UML: diagramme de classes
Les droits associés à chaque niveau
de confidentialité sont:
• Public (+): attribut ou opération
visible par tous
• Protégé (#): attribut ou
opération visible seulement à
l’intérieur de la classe et pour
toutes les sous-classes de la
classe.
• Privé(-): attribut ou opértion
seulement visible à l’intérieur
de la classe
• Paquetage (~): attribut ou
opération ou classe visible à
l’intérieur du paquetage où se
12
trouve la classe
UML: diagramme de classes
• La visibilité déclare la possibilité pour un élément de modélisation
de référencer un élément qui se trouve dans un espace de noms
différents de celui de l’élément qui établit la référence: public (+),
private (-), protected (#), package (~).
• Le mécanisme en UML qui permet de définir des niveaux de
visibilité des éléments d’un conteneur est l’encapsulation.
• L’encapsulation est un mécanisme consistant à rassembler les
données et les méthodes au sein d’une structure en cachant
l’implémentation de l’objet, c’est-à-dire en empêchant l’accès aux
données par un autre moyen que les services proposés.
• Ces services accessibles (offerts) aux utilisateurs de l’objet
définissent ce que l’on appel l’interface de l’objet (sa vue externe).

13
UML: diagramme de classes
• Un attribut dérivé peut être calculé à partir d’autres attributs et de
formules de calcul.
• Les attributs dérivés sont symbolisés par l’ajout d’un « / » devant leur
nom.

• Un attribut statique (static en Java ou en C++) est un


attribut de la classe qui garde une valeur unique et
partagée par toutes les instances de la classe. Les
instances ont accès à cet attribut mais n’en
possèdent pas une copie. Un attribut de classe n’est
donc pas une propriété d’une instance mais une
propriété de la classe et l’accès à cet attribut ne
14
nécessite pas l’existence d’une instance.
UML: diagramme de classes
Agrégation et composition entre classes
• L’agrégation est une association qui permet de représenter un lien de
type « ensemble » comprenant des « éléments ». Il s’agit d’une relation
entre une classe représentant le niveau « ensemble » et 1 à n classes de
niveau « éléments ». L’agrégation représente un lien structurel entre une
classe et une ou plusieurs autres classes.

15
UML: diagramme de classes
Agrégation et composition entre classes
• La composition est une relation d’agrégation dans laquelle il existe une
contrainte de durée de vie entre la classe « composant » et la ou les classes
« composé ». Autrement dit, la suppression de la classe « composé »
implique la suppression de la ou des classes « composant ».

16
UML: diagramme de classes
Généralisation/spécialisation et héritage simple
• La généralisation est la relation entre une classe et deux autres classes ou
plus partageant un sous-ensemble commun d’attributs et/ou d’opérations.
• La classe qui est affinée s’appelle super-classe, les classes affinées
s’appellent sous-classes.
• L’opération qui consiste à créer une super-classe à partir de classes
s’appelle la généralisation. Inversement, la spécialisation consiste à créer
des sous-classes à partir d’une classe.

17
UML: diagramme de classes
Généralisation/spécialisation et héritage simple
• Par défaut, les sous-classes ont des instances disjointes les unes par rapport
aux autres. Dans certains cas, il existe un recouvrement d’instances entre
les sous-classes. D’une manière générale, quatre situations peuvent se
rencontrer et se représentent sous forme de contraintes :
– {chevauchement} : deux sous-classes peuvent avoir, parmi leurs instances, des instances
identiques ;
– {disjoint} : les instances d’une sous-classe ne peuvent être incluses dans une autre sous-
classe de la même classe ;
– {complète} : la généralisation ne peut pas être étendue ;
– {incomplète} : la généralisation peut être étendue.

18
UML: diagramme de classes
Généralisation/spécialisation et héritage simple
• L’ajout de propriétés dans une sous-classe correspond à une extension
de classe.
• Le masquage de propriétés dans une sous-classe correspond à une
restriction de classe.

19
UML: diagramme de classes
Classe abstraite et interface
• Une interface est une classe abstraite pure qui ne comporte que des méthodes
abstraites.
• Graphiquement, on ajoute un stéréotype <<interface>> devant le nom de la
classe.
• Une classe d’interface permet de décrire la vue externe d’une classe.
• La classe d’interface, identifiée par un nom, comporte la liste des
opérations accessibles par les autres classes.
• Le compartiment des attributs ne fait pas partie de la description d’une
interface.

20
UML: diagramme de classes
Classe abstraite et interface
• Une classe abstraite est une classe qui n’a pas d’instance directe mais
dont les classes descendantes ont des instances. Dans une relation
d’héritage, la super-classe est par définition une classe abstraite.
• Une classe abstraite définit au moins une méthode abstraite ou
lorsqu’une classe parent contient une méthode abstraite non encore
réalisée.
• Une méthode est dite abstraite lorsqu’on connaît son entête mais pas la
manière dont elle peut être réalisée.

21
UML: diagramme de classes
Héritage multiple
• Dans certains cas, il est nécessaire de faire hériter une même classe de
deux classes « parentes » distinctes. Ce cas correspond à un héritage
multiple.

22
UML: diagramme de classes
Association, multiplicité, navigabilité et contraintes

• Un lien est une connexion physique ou conceptuelle entre instances de


classes donc entre objets.
• Une association décrit un groupe de liens ayant une même structure et
une même sémantique. Un lien est une instance d’une association.
• Chaque association peut être identifiée par son nom. Une association
entre classes représente les liens qui existent entre les instances de ces
classes.
• Le rôle tenu par une classe vis-à-vis d’une association peut être précisé
sur l’association.

23
UML: diagramme de classes
Association, multiplicité, navigabilité et contraintes
• La multiplicité indique un domaine de valeurs pour préciser le nombre
d’instance d’une classe vis-à-vis d’une autre classe pour une association
donnée. La multiplicité peut aussi être utilisée pour d’autres usages
comme par exemple un attribut multivalué.
• Le domaine de valeurs est décrit selon plusieurs formes :
– Intervalle fermé
• Exemple : 2, 3 ..15.
– Valeurs exactes
• Exemple : 3, 5, 8
– Valeur indéterminée notée *
• Exemple : 1..*.

24
UML: diagramme de classes
Association, multiplicité, navigabilité et contraintes
• La navigabilité indique si l’association fonctionne de manière
unidirectionnelle ou bidirectionnelle, elle est matérialisée par une ou
deux extrémités fléchées.
• La non-navigabilité se représente par un « X » Intervalle fermé.
• Par défaut, on admet qu’une navigabilité non définie correspond à une
navigabilité implicite.

25
UML: diagramme de classes
Association, multiplicité, navigabilité et contraintes
• D’autres propriétés particulières (contraintes) sont proposées dans UML
pour préciser la sémantique d’une association.
• Des relations sémantiques définies sur une association ou sur un groupe
d’associations qui permettent de:
– étendre ou de préciser la sémantique
– restreindre le nombre d'instances visées
• Elles peuvent s'exprimer en :
• Langage Naturel (L’age d’une personne est supérieur à zéro) ou
• graphiquement avec un {texte} ({longueur > largeur}) ou
• En OCL (Object Constraint Language) FENETRE
L’age d’une
personne est > 0 {longueur > largeur}
PERSONNE 26
UML: diagramme de classes
Association, multiplicité, navigabilité et contraintes
• Ordre de tri : Pour une association de multiplicité supérieure à 1, les
liens peuvent être :
– non ordonnés (valeur par défaut),
– ordonnés ou triés lorsque l’on est au niveau de l’implémentation (tri sur une valeur
interne).
• Il est possible d’indiquer des contraintes particulières relatives aux
conditions de mise à jour des liens.
– {interdit} : interdit l’ajout, la suppression ou la mise à jour des liens.
– {ajout seul} : n’autorise que l’ajout de liens.

27
UML: diagramme de classes
Association, multiplicité, navigabilité et contraintes
• Une association de dimension supérieure à 2 se représente en utilisant
un losange permettant de relier toutes les classes concernées.
• Une classe-association permet de décrire soit des attributs soit des
opérations propres à l’association.
• Cette classe-association est elle-même reliée par un trait en pointillé au
losange de connexion.
• Une classe-association peut être reliée à d’autres classes
d’un diagramme de classes.

28
UML: diagramme de classes
Application
Chaque agence est caractérisée par un code, un
intitulé, une date de création et une date de
fermeture. À une agence sont rattachées une à
plusieurs personnes. Chaque personne est caractérisée
par les données : numéro, qualité (M., Mme, Mlle),
nom, prénom, date de naissance, date prévisionnelle
d’arrivée, date d’arrivée et date de départ. Il est
demandé d’élaborer le diagramme de classe de ce
premier sous-ensemble du SI de cette entreprise.

Diagramme de classes

Diagramme d’objets

29
UML: diagramme de composants
• Le diagramme de composant permet de représenter les composants logiciels
d’un système ainsi que les liens existant entre ces composants. Les composants
logiciels peuvent être de deux origines : soit des composants métiers propres à
une entreprise soit des composants disponibles sur le marché comme par
exemple les composants EJB, CORBA, .NET, WSDL.
• Chaque composant est assimilé à un élément exécutable du système. Il est
caractérisé par :
– un nom ;
– une spécification externe sous forme soit d’une ou plusieurs interfaces requises1, soit d’une ou
plusieurs interfaces fournies2 ;
– un port de connexion.
– Le port d’un composant représente le point de connexion entre le composant et une interface.
L’identification d’un port permet d’assurer une certaine indépendance entre le composant et son
environnement extérieur.
• Un composant logiciel définit les services logiciels qu’il rend et aussi les services
dont il est en attente pour pouvoir fonctionner. Ainsi, un composant spécifie les
interfaces qu’il fournit (qu’il réalise) et les interfaces qu’il requiert.

30
UML: diagramme de composants
• Un composant est unité autonome faisant partie d’un système ou d’un
sous-système qui encapsule un comportement (i.e., implémentation) et qui
offre une ou plusieurs interfaces publiques. Un composant est une partie
constituante d’un système qui peut être remplacée ou/et réutilisée.
• Granularité ? Un composant peut représenter quelque chose d’aussi fin
qu’un objet, comme il peut représenter un sous-système complexe
• Un composant est dessiné comme un rectangle avec le
stéréotype «component». Si le composant est gros alors UML suggère de
remplacer le stéréotype «component» par «subsystem».

Exemples de composants: Binaire


exécutable (<<executable>>), bibliotheque
dynamique/statique (<<librairy>>), un
fichier à interpréter (<<file>>)…

31
UML: diagramme de composants
Notation concise

Notation avec stéréotype 32


UML: diagramme de composants
Composite, port, connecteurs de délégation et d’assemblage
• Les composants primitifs ne contiennent pas d’autres composants
• Les composites sont composés de composants primitifs et de
composites.
• Les composants à l’intérieur d’un composite sont connectés par des
connecteurs dits d’assemblage.
• Les interfaces offertes et requises sont connectées à des ports du
composite et les ports sont à leur tour connectés aux composants
de l’intérieur par des connecteurs dits de délégation.
• La notion de port matérialise le passage du contrôle de l’extérieur
vers l’intérieur et vice versa. Non montré dans cette diapositive, les
composants primitifs sont en général constitués de classes.
• Un modèle de composant hiérarchique, c’est-à-dire intégrant la
notion de composants primitif et composite, permet d’étudier le
système à différents niveaux de granularité : tout le système est un
composite, que l’on peut ouvrir récursivement pour en connaître
plus de détails, jusqu’à trouver les classes dans les composants 33
primitifs.
UML: diagramme de composants
Composite, port, connecteurs de délégation et d’assemblage

34
UML: diagramme de composants
Structure interne du composant magasin

35
UML: diagramme de déploiement
• Le diagramme de déploiement permet de
représenter l’architecture physique supportant
l’exploitation du système. Cette architecture
comprend des nœuds correspondant aux
supports physiques (serveurs, routeurs…) ainsi
que la répartition des artefacts logiciels
(bibliothèques, exécutables…) sur ces nœuds.
C’est un véritable réseau constitué de nœuds et
de connexions entre ces nœuds qui modélise
cette architecture.

36
UML: diagramme de déploiement
Notions de nœuds, liens et artefacts
• Un nœud est un composant mécanique : ordinateur, serveur,
imprimante, environnement d’exécution... ´
• Un nœud peut contenir d’autres nœuds ou artefacts
• Un nœud est représenté par un cube

• Un lien est un élément permettant de connecter les noeuds 37


UML: diagramme de déploiement
Notions de nœuds, liens et artefacts
• Un artefact est un élément concret de l’application (fichier contenant du code
source, table d’une base de données, script...)
• Un artefact peut manifester : résulter et implémenter un élément de modèle

38
UML: diagramme de déploiement
Notions de nœuds, liens et artefacts

39
UML: diagramme de déploiement
Notions de nœuds, liens et artefacts

40
UML: diagramme de paquetage
• Un paquetage est un regroupement d’éléments de modèle et
de diagrammes. Il permet ainsi d’organiser des éléments de
modélisation en groupes. Il peut contenir tout type d’élément
de modèle : des classes, des cas d’utilisation, des interfaces, des
diagrammes, … et même des paquetages imbriqués
(décomposition hiérarchique).

41
UML: diagramme de paquetage
La dépendance entre paquetages peut être qualifiée par un niveau de
visibilité qui est soit public soit privé (par défaut public). Les deux types
de dépendances entre paquetages sont :
– « import » : permet d’importer l’espace de nommage d’un autre paquetage.
Tous les membres de ce paquetage ont accès à tous les noms des membres du
paquetage importé sans avoir à utiliser explicitement le nom du paquetage
concerné. Ce type de dépendance correspond à un lien ayant une visibilité «
public ».
– « access » : permet d’avoir accès à l’espace de nommage d’un paquetage cible.
L’espace de nommage n’est donc pas importé et ne peut être transmis à
d’autres paquetages par transitivité. Ce type de dépendance correspond à un
lien ayant une visibilité « privé ».

42
UML: diagramme de paquetage
Exemple

43
Chapitre 2 Programmation orientée objet

Responsable de cours : Sahar GHRAB


Année universitaire : 2023/2024
Discipline : 1MR-SII

44
Plan

Rappel d’UML
Rappel de la Programmation orientée Objet
(POO)
Les design patterns (patron de conception)

45
Paradigme de programmation
• Programmation séquentielle: les instructions
sont exécutées de façon linéaire. Les données
sont globales et aucune réutilisation du code
n’est réutilisée.
• Programmation procédurale: il s’agit de
découper un programme en une série de
fonctions réalisant un traitement particulier.
• Programmation orientée objet (POO): il s’agit de
regrouper l’ensemble des données et les
traitements qui s’appliquent à ces données. On
procède à un découpage des données et du
traitement des données. Le concept de classe
permet d’établir cette relation donnée- 46
Programmation orientée objet
• La POO est un style de programmation où les
composants autonomes (les objets) disposent de
ressources et de moyens d’interaction entre eux.
• La POO se base principalement sur qu’est ce
qu’on va manipuler avant de se concentrer sur la
façon dont on va les manipuler.

47
Programmation orientée objet
• Mon chat miaule, marche et mange:
– Nous connaissons les manifestations extérieures du
miaulement, mais la façon dont le son est produit nous est
masqué.
• Le chat devient alors une abstraction dont on ne montre
seulement que quelques comportements.
• Une interface représente cette abstraction.
– L’interface énonce les services offerts et les détails de
fonctionnement sont cachés.
• L’emphase est mise sur la compréhension des éléments
importants, sans se soucier de l’implantation

48
Classe / objet
• La classe n’est qu’une moule servant à créer des objets
• Une classe est un modèle de définition pour des objets
ayant une sémantique commune.
• Un objet est aussi nommé une instance d’une classe.
• Une classe possède des caractéristiques
– Attributs: variables qui représentent les données de
l’objet? Les valeurs de ces données sont les états de
l’objet.
– Méthodes: représentent le comportement des objets de
cette classe. Elles manipulent les champs des objets et
caractérisent les actions pouvant être effectuées par les
objets.
• La classe est une extension de la notion de structure 49
Exemple
• Ecrire un programme qui permet de gérer le
calcul des salaires des employés d’une
entreprise.
• Un employé est caractérisée par son nom,
prénom, cin, code cnss, nombre de jour de
travail, mail, telephone.
Le programme demande à l’utilisateur de saisir les
informations des employés, ensuite affiche les
informations de chaque employé et son salaire
approprié.
50
Exemple
• Approche procédurale:
– Question: Quelle est la structure de données relative à
un employé?
– Réponse : Tableaux à indices correspondant aux
employés et de leurs salaires.
– Question : Comment peut-on découper le programme
pour le simplifier?
– Réponse : procédure Saisie_données, et une fonction
calcul_salaire.
• Approche Orientée Objet:
– Question: de quoi est composé le programme?
– Réponse : classe Employe ayant pour attributs
51
(données) et ses méthodes (procédures ou fonctions)
Encapsulation
• L’encapsulation est le fait de masquer le contenu
d’un objet et montrer ce qui est nécessaire pour
son utilisation. Une donnée peut être déclarée en
accès :
– public : les autres objets peuvent accéder à la valeur
de cette donnée ainsi que la modifier ;
– private : les autres objets n’ont pas le droit d’accéder
directement à la valeur de cette donnée (ni de la
modifier). En revanche, ils peuvent le faire
indirectement par des méthodes de l’objet concerné
(si celles-ci existent en accès public).

52
Constructeur
• Chaque classe doit définir une ou plusieurs méthodes particulières
appelées des constructeurs.
• Un constructeur est une méthode invoquée lors de la création d’un
objet. Cette méthode, qui peut être vide, effectue les opérations
nécessaires à l’initialisation d’un objet.
• Chaque constructeur doit avoir le même nom que la classe où il est
défini et n’a aucune valeur de retour (c’est l’objet créé qui est renvoyé).
• Plusieurs constructeurs peuvent être définis s’ils acceptent des
paramètres d’entrée différents.

53
Constructeur

54
Objet
• Un objet est une instance d’une classe et est
référencé par une variable ayant un état (ou
valeur).
• Pour créer un objet, il est nécessaire de déclarer
une variable dont le type est la classe à instancier,
puis de faire appel à un constructeur de cette
classe.

55
Application

56
Application

57
Modificateur de visibilité
• Java propose plusieurs niveaux de visibilité (modificateurs
d’accès) utilisables sur les données et les méthodes d'une
classe pour assurer le principe de l’encapsulation:
– « public » : accessible à partir d’une instance par n’importe
quelle classe.
– « private » : accessible uniquement par la même classe dont
elle est déclarée.
– « protected » : accessible par la même classe, ses classes
dérivées (cf héritage) et les classes du même package
– « static » : donnée ou méthode de classe et non pas d’instance.
Dans ce cas, une méthode static n’a pas besoin d’être appelé
avec un objet.
• Si on ait dans la même classe on fait l’appel directement par le nom de
la méthode
• si on ait dans une autre classe on appelle la méthode avec le nom de
la classe suivi d’un point puis du nom de la méthode.
58
Modificateur de visibilité
• « final » :
– Une classe définie comme final ne peut pas être dérivée (on ne
peut pas créer une nouvelle classe héritant de cette classe).
– Une méthode déclarée final ne peut pas être redéfinie dans une
classe dérivée.
– Un attribut définie comme final, permet de spécifier que cet
attribut est une constante (sa valeur ne pourra jamais être
modifiée). Un attribut final doit obligatoirement être initialisée lors
de sa déclaration (puisqu'on ne peut pas le modifier après cela ) !
• Par Défaut: l’accès est dit friendly : le champs sera public vis à
vis du package, et privé pour le reste

59
Exemple

60
Exemple

61
Héritage
• L'héritage est la définition d'une classe par
extension des caractéristiques d'une autre classe.
• Il consiste à définir différent niveaux d’abstraction
permettant ainsi de factoriser certains attributs
et/ou méthodes communs à plusieurs classes.
• Une classe générale (parente) définit alors un
ensemble d’attributs et/ou méthodes qui sont
partagés par d’autres classes (fils), dont on dira
qu’elles héritent de cette classe générale.
62
Héritage

Les classes Chat et chien héritent


l’attribut nom de la classe Animal
Chaque sous-classe aoute ses méthodes spécifiques

63
Héritage
• Le mécanisme d’héritage permet de redéfinir des
méthodes d’une classe parente dans les classes
dérivées avec le même nom et les même
paramètres mais avec un comportement différent
• Une classe abstraite est une classe ayant au
moins une méthode abstraite.
• Une méthode abstraite ne possède pas de
définition.
• Une classe abstraite ne peut pas être instanciée
(new).
• Elle doit être marquée avec le mot réservé
abstract.
64
Héritage
• Si la classe mère est une classe abstraite, il y a de forte
chance qu'elle présente des caractéristiques abstraites
(retardées). Pour être instanciable, la classe fille doit
alors les définir, sinon elle sera elle-même abstraite.
• Si la classe mère est instaciable (c'est-à-dire que toutes
ses caractéristiques sont définies) alors la classe fille
est également instanciable. Il est possible d'y ajouter
des caractéristiques, d'utiliser les caractéristiques
héritées (appartenant aux parents) et de redéfinir les
méthodes héritées.
• Généralement cette redéfinition se fait par surcharge
sémantique (on déclare de nouveau la méthode avec le
même nom et la même signature).
65
Héritage

Redéfinition de la
Redéfinition de la méthode surface
méthode surface

Redéfinition de la
Redéfinition de
méthode périmètr
la méthode
périmètre

Programme
principal

66
Interface
• Parfois, on aurait bien envi de faire de
l'héritage multiple comme dans
l'exempe ci-dessous :

•La solution à ce problème en JAVA :


les interfaces (protocoles dans
d'autres langages)

67
Interface
• Une interface est similaire à une classe abstraite sauf que:
– Le mot clé Interface remplace les mots clés Abstract Class
– Toutes les méthodes définies dans une interface sont implicitement
abstraites
– Toutes les variables définies dans une interface doivent l’être en tant
que constantes (static final)
• De la même manière qu’une classe étend sa super-classe, elle peut
de manière optionnelle implémenter une ou plusieurs interfaces.
• Pour implémenter une interface dans une classe Java, il faut:
– Dans la définition de la classe, après la clause extends nomSuperClasse
faire apparaître explicitement le mot clé implements suivit du nom de
l’interface implémentée.
– Fournir une implémentation (un corps) à chacune des méthodes
abstraites définies dans l’interface

68
Interface

Programme principal

69
Surcharge
• Le surcharge ressemble à la redéfinition de méthodes ;
mais ici dans la même classe.
• Surcharger une méthode c’est redéfinir une méthode avec
le même nom mais un type de retour et /ou des
paramètres différents dans une même classe.
• Les méthodes comme les constructeurs peuvent être
surchargées: (overloaded) Leur nom est le même et e
nombre ou le type de leurs paramètres varie
• L’objectif est de fournir plusieurs définitions pour la même
méthode
• Le compilateur doit pouvoir trouver celui qui convient le
mieux au « site d'appel », c'est à dire au nombre et au type
des arguments
• Si aucune méthode ne correspond exactement, le
compilateur peut prendre une méthode approchée en 70
fonction du typage
Surcharge

71
Polymorphisme
• Le polymorphisme est la faculté attribuée à un
objet d’être une instance de plusieurs classes.
• Il a une seule classe “réelle” qui est celle dont le
constructeur a été appelé en premier (c’est-à-dire
la classe figurant après le new) mais il peut aussi
être déclaré avec une classe supérieure à sa
classe réelle.
• Cette propriété est très utile pour la création
d’ensembles regroupant des objets de classes
différentes
72
Polymorphisme

73

Vous aimerez peut-être aussi