1

C.MOUBSIT
 Plan du cours
1 Paradigme

2 Classes et objets

3 Abstraction et encapsulation

4 Relations entre classes

5 Polymorphismes

6 Orienté objets ou procédurale

2
C.MOUBSIT
 3
C.MOUBSIT
 4
C.MOUBSIT
 Un paradigme est une représentation du monde, une manière de
voir les choses. C’est un point de vue particulier sur une réalité, une
manière d’aborder une classe de problèmes.

5
C.MOUBSIT
 Aborder un pb, en utilisant un ens de notions et d’idées couramment admises par
une société ou une communauté scientifique, ne veut pas dire que c’est la
meilleure ou l’unique démarche possible l’histoire des sciences : de
nombreux paradigmes disparu ou améliorés au profit d’autres.
Deuxième siècle : Ptolémée (astronome grec) impose le géocentrisme.
Dix-septième siècle : Galilée ( inspiré des travaux de Copernic) : la terre tourne
autour du soleil
Critiques ……
Le soleil est il fixe ????

6
C.MOUBSIT
  Le monde de l’informatique ne fait pas l’exception a cette règle
du changement. ( Von Neumann – 1940)
 Un web désigner et un développeur d’application web
 Les concepts, selon lesquels nous interprétons un phénomène,
déterminent les éléments importants que nous cherchons à
identifier : ils dirigent notre attention vers certains détails et la
détournent d’autres.
 La capacité de passer d’1 paradigme à un autre : évolution
intellectuelle Ex
7
C.MOUBSIT
 8
C.MOUBSIT
 Différence entre paradigme et langage de programmation
 Un paradigme de programmation
* Traite la manière dont les solutions aux problèmes doivent être
formulées dans un langage de programmation.

* Oriente la façon d’analyser, de concevoir et de coder un programme

 Un langage de programmation

Permet de décrire ses comportements a un ordinateur

9
C.MOUBSIT
 EXEMPLES DE PARADIGMES DE
PROGRAMMATION

 Le paradigme de programmation :

 Impérative

 structurée/Procédurale

 Orienté Objet

10
C.MOUBSIT
 PARADIGMES DE PROGRAMMATION IMPÉRATIVE

 Est un paradigme naturel que l’être humain applique quotidiennement pour

gérer différents Pb dans sa vie courante ( il exécute ses tâches dans l’ordre

séquentiel).

 Les processeurs se basent sur le même principe; l‘exécution séquentielle,

instruction après instruction.

 Les instructions de branchement et de bouclage sont entiérement basées sur

l’instruction : « Go To »

11
C.MOUBSIT
 PARADIGMES DE PROGRAMMATION IMPÉRATIVE

 Exemple de structure « Si … Alors … Sinon »

1000 Si cond Goto 1200

1100 instruction 2

1110 etc

1200 instruction 1

1400 suite de l’algorithme

12
C.MOUBSIT
 PARADIGMES DE PROGRAMMATION PROCÉDURALE

 Basé sur le concept d’appel procédural.

 Une procédure est une série d’instructions regroupées dont le

but est d’effectuer une tâche bien précise.

 Une procédure peut être appelée de n’importe où dans le

programme.

 La notion de procédure permet le découpage des programmes

en modules indépendantes les uns des autres.
13
C.MOUBSIT
 PARADIGMES DE PROGRAMMATION STRUCTURÉE

 En programmation structurée on recommande une organisation

hiérarchique simple du code (structure de contrôle et structure

des données).

 Utilisation d’une analyse du problème descendante (découpage

du programme en plusieurs procédures et fonctions) ou

ascendante (réutilisation de l’existant).

14
C.MOUBSIT
 ETUDE DE CAS : UNE SIMULATION D’UN TRAFIC ROUTIER

Paradigmes de programmation structurée:

 Quel est le problème à résoudre ?

 Comment décomposer le problème?

15
C.MOUBSIT
 ETUDE DE CAS : UNE SIMULATION D’UN TRAFIC ROUTIER

Plusieurs véhicules (voitures, camions, bus, moto, …) et conducteurs de

caractéristiques différentes en plus d’un agent de circulation. Circulation sur une
route à deux, trois ou quatre bandes. Certains véhicules s’arrêtent, d’autres
démarrent lorsque le feu change. Des piétons traversent la route, etc.

Trop de de données différentes  problème de représentation.

16
C.MOUBSIT
 ETUDE DE CAS : UNE SIMULATION D’UN TRAFIC ROUTIER

Besoin d’une nouvelle représentation des objets de la simulation:

 Description des caractéristiques des objets (définir le modèle de la voiture, l’âge
du conducteur, le type du carrefour, etc.)
 Définition du comportement des objets (une voiture peut avancer, s’arrêter, ou
accélérer, les feux de signalisation changent de couleur, etc.).
 Définition des processus de communication entre les objets (changement de la
couleur du feu de signalisation agit sur le comportement des véhicules , etc.).
 Le paradigme orienté objet.
17
C.MOUBSIT
 PRGRAMMATION ORIENTÉ OBJET

La programmation orientée objet (POO), est une

façon d'architecturer une application
informatique en regroupant les données, appelées
attributs (caractéristiques) et les comportements
de l’objet, appelés méthodes au sein d'une même
entité qu’on appelle un OBJET.

f/r15
18
C.MOUBSIT
 19
C.MOUBSIT
 20
C.MOUBSIT
 OBJET, ATTRIBUTS ET MÉTHODES

objets Voiture 1 Voiture 2 Voiture 3

Données (attributs)

Marque : Volkswagen Volkswagen Mercedes

Modèle : Golf 5 Golf 2 250
Couleur : Rouge Noir Bleu
Numéro de série : 123456 123457 123458

Comportements Démarrer Démarrer Démarrer

S’arrêter S’arrêter S’arrêter
(Méthodes) Accélérer Accélérer Accélérer
freiner freiner freiner

21
C.MOUBSIT
 NOTION D’ATTRIBUT ET MÉTHODE
Objet voiture
• Un attribut est une propriété visible de
l’extérieur de l’objet, il est propre et particulier Attributs
à un être, à quelqu'un ou à quelque chose.
• Une méthode définit un comportement
particulier de l’objet. C’est une tâche que
Méthodes
l’objet exécute lorsqu’un autre objet le lui
demande.

 La signature d’une méthode ??????????

 Par quoi l’état d’un objet est définit ?????

 L’état de l’objet est-il fixe dans le temps????

22
C.MOUBSIT
 SIGNATURE D’UNE MÉTHODE
ETAT D’UN OBJET

 La signature d’une méthode est composée du :

 nom de la méthode

ainsi que de

 la liste des identifiants et types des arguments de la méthode.

 L’état d’un objet est définit par les valeurs de ses attributs.

 L’état de l’objet n’est pas fixe dans le temps, il change à chaque fois qu’on
modifie la valeur d’un attribut de l’objet.

23
C.MOUBSIT
 TYPE ET CLASSE

int Une variable entière possédant une

valeur entière : 3

monEntier 3
Une valeur
Entière positive ou négative

Déclaration de la
variable monentier.
Int monEntier = 3

De même on veut inventer un nouveau type « voiture » et définir ce

qu’il fait, pour pouvoir créer des objets à partir de ce nouveau type

24
C.MOUBSIT
 NOTION DE CLASSE
marque
model Structure de données identique
couleur… mais avec des valeurs différentes.

demarer()
arreter() marque : mercedes
model : 250
couleur : rouge
….
Objet 1
Structure de données commune
à tous les objets voiture marque : mercedes
model : 220
couleur : bleu
Classe Voiture: Création d’objets …. Objet 2

Voiture=identifiant ou
référence Deux vrais objets voiture crées avec
la même structure de données à
partir du Type Voiture

Une classe représente un modèle de construction d'un objet, Il s'agit

d'une description abstraite en terme de données et de comportements
d'une famille d'objets.
25
C.MOUBSIT
 CLASSE

Classe
Le nom de la classe

L’ensemble des attributs de la classe

L’ensemble des méthodes de la classe

26
C.MOUBSIT
 CLASSE ET INSTANCIATION D’OBJETS

Moule représentant la Les objets gâteau crées à

classe « Gâteau » partir de la classe (moule)

• La création d’un objet à partir d’une classe s’appelle:

l’INSTANCIATION
• Le ‘’point’’ permet d’accéder à tous ce que contient l’objet, que ce soit
les attributs ou les méthodes.
voiture1.marque = Mercedes
voiture1. démarrer()
27
C.MOUBSIT
 REPRÉSENTATION GRAPHIQUE DES CLASSES
ET OBJETS
Classe Objets
Voiture1 :Voiture Voiture2 :Voiture
Couleur : rouge Couleur : bleu
numSerie : 54FD numSerie : 3321
vitesse : 0 vitesse : 0
vitesseMax : 100 vitesseMax : 160
moteur : true moteur : true
plaque : ABCD plaque : GRTD
nbrePlaces : 6 nbrePlaces : 6

UML (en anglais Unified Modeling Language ou « langage de

modélisation unifié ») est un langage de modélisation graphique. Ce
langage introduit des outils qui facilitent la conception orientée objet f/r26
28
C.MOUBSIT
C.MOUBSIT 29
 Ex
30
C.MOUBSIT
 31
C.MOUBSIT
 ABSTRACTION

 L’abstraction est le processus qui consiste à simplifier

un problème complexe. Quand nous essayons de
résoudre un problème, nous ne nous attardons pas sur
les détails inutiles . Nous ne nous intéressons, en effet,
qu’aux détail qui nous semblent importants pour la
solution du problème.

32
C.MOUBSIT
 ABSTRACTION
L’abstraction du problème
 Pour notre problème de simulation de trafic routier, nous ne
nous intéressons qu’à la modélisation des classes qui ont une
influence sur le trafic ( Voiture , Conducteur , Feu de
signalisation,...

 Pour Lampadaire, Trottoir, Bâtiment, Zone verte ????

 Nous sommes obligés de prendre en considération

certains éléments de la vie réelle et faire abstraction d’autres
afin de simplifier le passage du monde réelle a celle
informatique.

33
C.MOUBSIT
 ABSTRACTION

L’abstraction des modèles

 Qu’est ce qui nous a guidés dans le choix des

attributs et des méthodes de notre classe
« Voiture» ???
 Pour quelle raisons nous avons choisi
d’intégrer dans classe Voiture comme attributs
la couleur ou le nb de places et non pas des
attributs tels que le poids et la consommation
du moteur par exemple ??

34
C.MOUBSIT
 ABSTRACTION
L’abstraction des modèles

 L’abstraction est le passage du monde réel à la

modélisation. Le passage d’un objet réel à un
objet informatique se fait en ne gardant que les
détails (Attribut) qui nous intéressent

Prenons un exemple

35
C.MOUBSIT
 ABSTRACTION

 La granularité de la représentation correspond au niveau du

détail de la modélisation.
 Celle utilisée par l’infographiste est plus fine ( plus de détail)
que celle du mathématicien.

36
C.MOUBSIT
 ABSTRACTION
 Pour Voiture dans notre simulation, les attributs suivants
apparaissent essentiels :
 la couleur : facilite la représentation dans l’interface graphique
 numSerie : unique pour chaque voiture
 Vitesse actuelle et maximale
 moteur :pour distinguer la voiture des véhicules sans moteur et
de modéliser différents types d’accélération.

Ex
37
C.MOUBSIT
 38
C.MOUBSIT
 Notre code enfin finalisé nous passons aux tests
de notre simulation.

Des vitesses négatives !!!.

Des voiture ont une certaines vitesse alors
qu’ils sont à l’arrêt !!!.

39
C.MOUBSIT
 Le 1er principe de la POO n’est
pas respecté.

40
C.MOUBSIT
 ENCAPSULATION

L'encapsulation est un mécanisme consistant à

rassembler les attributs et les méthodes au sein
d'une classe en cachant l'implémentation de
l'objet, càd en empêchant l'accès direct aux
attributs tout en proposant des méthodes
permettant la manipulation de ces attributs

41
C.MOUBSIT
 ENCAPSULATION

 L'interdiction d'accès aux attributs se fait en les déclarants

comme prive.
 La notion de prive, opposée a publique, permet d'indiquer que
la manipulation des attributs est restreinte au seul objet
possédant ces attributs, et de ce fait, ils seront invisibles au
monde extérieur.
 D'une manière générale, tous les attributs doivent être prives et
la plupart des méthodes doivent être publiques.
=> vue interne et externe sur une classe.

42
C.MOUBSIT
 ENCAPSULATION
L’encapsulation permet d’obtenir:
 Un niveau externe : la partie visible de l’objet :
 Des données et des méthodes visibles depuis l’extérieur
 C’est l’interface de l’objet avec l’extérieur

 Un niveau interne : l’implémentation de l’objet :

 Les méthodes et attributs visibles uniquement de
l’intérieur de l’objet
 Définition de l’ensemble des attributs et des méthodes
 C’est le corps de l’objet
P35/36
43
C.MOUBSIT
 ACCÉDER AUX DONNÉES PROTÉGÉES

Par quel moyen pouvons nous modifier les

attributs même s’ils sont privés ??

44
C.MOUBSIT
 ACCÉDER AUX DONNÉES PROTÉGÉES

Deux méthodes publiques permettront d’accéder à un attribut

protégé :
un setter qui modifie la valeur d’un attribut.
un getter qui récupère la valeur d’un attribut.

Exemples
public void setVistesse(int v) { public int getVitesse() {
if (v >= 0 ) vitesse = v ; return vitesse ;
} }

Ex
45
C.MOUBSIT
 EXERCICE
On vient de résoudre le Pb des vitesses négatives.

Mais pour une voiture qui n’est pas en marche

et sa vitesse est > 0 ???.

public void setVistesse(int v) { public int getVitesse() {
if (v >= 0 ) vitesse = v ; return vitesse ;
} }

46
C.MOUBSIT
 public void setVistesse(int v) {
if (v >= 0 et estDemarre == true)
vitesse = v ;
}

47
C.MOUBSIT
 ACCÉDER AUX DONNÉES PROTÉGÉES
+ Voiture

numSerie
couleur
vitesse
vitesseMax
estDemarre
puissanceMoteur
+demarrer()
+arreter()
+Accelerer(int)
+Freiner()

Classe ( voiture ) après modification

48
C.MOUBSIT
 INTERFACE D’UN OBJET

 L’interface d’un objet définit l’ensemble des tâches que l’objet

peut effectuer si la demande lui est formulée par un autre
objet. Chaque tâche est représentée par une méthode publique.
 NE JAMAIS MODIFIER UNE INTERFACE en effectuant
des suppressions de méthodes ou en modifiant leurs signatures
( une seule possibilité est d’ajouter de nouvelles méthodes à
une interface).
 Le concepteur d’une classe peut faire des modifications sur la
structure interne de la classe sans aucune répercussion sur le
travail des utilisateurs qui ont une vue externe sur la classe.
P36
49
C.MOUBSIT
 SIGNATURE D’UNE MÉTHODE

 La signature d’une méthode permet de l’identifier de manière

unique.

 La signature est composé du :

 Nom de la méthode
 La liste des arguments

 2 méthodes ont le même nom et la même liste des arguments

sont elles identiques ???
50
C.MOUBSIT
 SIGNATURE D’UNE MÉTHODE

 Deux méthodes possédant le même nom et la même liste

d’attributs ne sont pas nécessairement identiques,
en effet :
 le type des arguments
 l’ordre dans lequel ils sont déclarés

Doivent aussi être pareils afin d’avoir la même signature

f/r42 Ex
51
C.MOUBSIT
 52
C.MOUBSIT
 Les relations entre
Classes

53
C.MOUBSIT
 COMMUNICATION ENTRE LES OBJETS

 Un MESSAGE est un moyen UNIQUE de communication

avec les objets (impossible d'accéder directement aux
données encapsulées d'un objet).
 Un MESSAGE contient:
• nom de l'objet destinataire,
• énoncé de la demande (le nom de la méthode que l’objet
doit exécuter),
• les arguments nécessaires (données supplémentaires
nécessaires pour réaliser correctement la demande)

54
C.MOUBSIT
 COMMUNICATION ENTRE LES OBJETS

Envoyer un message à un objet, c'est lui demander

d'exécuter une de ses méthodes
55
C.MOUBSIT
 COMMUNICATION ENTRE LES OBJETS

On ne peut demander à un objet d’exécuter que les

services qu’il propose via son interface.
56
C.MOUBSIT
 COMMUNICATION ENTRE LES OBJETS

Vis à vis des messages, un objet peut se comporter comme :

• Acteur : objet actif, à l’origine de l’envoi de messages, ne reçoit
jamais de messages, exemple : objet feu de signalisation;
• Serveur : objet passif destinataire des messages, n’envoie jamais
de messages, exemple : objet voiture;
• Agent : objet à la fois Acteur et Serveur, peut interagir avec les
autres objets, de sa propre initiative ou suite à un message,
exemple : objet conducteur.

57
C.MOUBSIT
 COMMUNICATION ENTRE LES OBJETS

 Les relations entre classes peuvent être de plusieurs natures :

• L’Association, simple relation permettant à deux classes

d’échanger des messages ;

• l’Héritage, traduit une classification ;

• La contenance (Agrégation, Composition), traduit une

composition ;

 Les relations entre classes modélisent les interactions (les

"liens") entre objets ;

58
C.MOUBSIT
 LA RELATION D’ASSOCIATION

Une association exprime une simple relation bidirectionnelle

entre classes :

 Les classes associées ont simplement "conscience" de

l’existence les unes des autres.

 Le fait que 2 classes soient associées suffit pour qu’elles

puissent échanger des messages.

59
C.MOUBSIT
 EXEMPLE D’ASSOCIATION
 Le ZOO est composé d’ :

• Un ensemble de cages.
• Un ensemble d'animaux.
• Un ensemble de gardiens.

un gardien s'occupe:

• d’un certain nombre d'animaux.

• nettoie un certain nombre de cages.

une cage regroupe certains animaux

60
C.MOUBSIT
 LA MULTIPLICITÉ D’ASSOCIATION

La multiplicité d’une association (cardinalité)

représente le nombre d’objets de la classe

considérée, objets reliés à un objet d’une autre

classe.

61
C.MOUBSIT
 LA RELATION D’ASSOCIATION

Une association exprime une simple relation bidirectionnelle

entre classes. Ex
62
C.MOUBSIT
 LA RELATION D’ASSOCIATION

63
C.MOUBSIT
 ETUDE DE CAS : UNE SIMULATION D’UN TRAFIC ROUTIER

64
C.MOUBSIT
 ETUDE DE CAS : UNE SIMULATION D’UN TRAFIC ROUTIER

 Attributs communs : couleur, numSerie, vitesse, vitesseMax

 Méthodes communes : demarrer, arreter, accelerer, freiner.
65
C.MOUBSIT
 PREMIÈRE VERSION DU DIAGRAMME DE CLASSES

Il suffit de créer un mécanisme pour dire : un Bus est un Véhicule; un

Bus peut avoir toutes les informations d’un Véhicule et de lui rajouter
d’autres propriétés spécifiques qui font de lui un Bus et non un Camion.
Un tel mécanisme s’appelle l’héritage.
66
C.MOUBSIT
 DEUXIÈME VERSION DU DIAGRAMME DE CLASSES

67
C.MOUBSIT
 TROISIÈME VERSION DU DIAGRAMME DE CLASSES

68
C.MOUBSIT
 LA RELATION D’HÉRITAGE
• L’héritage est une technique rationnelle (appelée aussi dérivation)

permettant de réutiliser et de spécialiser les classes existantes.

• La classe dont dérive une classe se nomme la classe de base, la

superclasse ou la classe mère… La classe dérivée se nomme la

classe fille ou la sous-classe.

• La classe dérivée bénéficie des attributs (données

membres) et des comportements (fonctions membres) de

la classe dont elle dérive.

69
C.MOUBSIT
 LA RELATION D’HÉRITAGE

• Ce n’est pas parce que deux classes possèdent des attributs

communs et des méthodes communes qu’on peut tjs regrouper leur

caractéristiques communes dans une nouvelle classe.

• Contre exemple :

Un étudiant possède un âge, un genre, et un nom;

Un enseignant de même;

Un chien de même;

Ex
70
C.MOUBSIT
 LA RELATION D’HÉRITAGE

Ex
71
C.MOUBSIT
 LA RELATION D’HÉRITAGE

Ex
72
C.MOUBSIT
 LA RELATION D’HÉRITAGE

Ex
73
C.MOUBSIT
 LA RELATION D’HÉRITAGE

74
C.MOUBSIT
 L’HÉRITAGE MULTIPLE
• L’héritage peut être simple ou multiple.

Véhicule Poidslourd

Camion

l’héritage multiple
NB: certains langages(comme Java) ne supportent pas l’héritage multiple

75
C.MOUBSIT
 HÉRITAGE PAR
SPÉCIALISATION
• L’héritage peut être utilisé en conception de deux façons :

• héritage par spécialisation (descendant)

- Une classe de base est dérivée pour produire une ou

plusieurs classes dérivées spécialisées dans certains
traitements, ou comportant des attributs particuliers

- démarche très utilisée dans les phases initiales de conception

car elle permet :
- de réutiliser tout ou partie des attributs et des méthodes
d’une classe de base,
- de ne rajouter dans la classe dérivée que les attributs et les
méthodes qui la spécialisent.

76
C.MOUBSIT
 HÉRITAGE PAR
GÉNÉRALISATION

• héritage par généralisation (ascendant)

- factorisation d’un ensemble d’attributs ou de

méthodes que l’on regroupe dans une classe de base

- démarche fréquente en fin de phase de conception,

après mûrissement, quand on s’aperçoit que certaines
classes possèdent des attributs ou des comportements
communs factorisables dans une classe de base.

77
C.MOUBSIT
 RÉUTILISATION DES COMPOSANTS
Considérons un autre projet de un jeu de course de voitures.

Classe voiture

78
C.MOUBSIT
 JEU DE COURSE DE VOITURES.

 La classe « Moteur » : puissance, nombre de

cylindre.

 La classe « Pneu » : marque, pression, type de

gommage.

 La classe « Carrosserie » : poids, largeur, longueur,

hauteur.

79
C.MOUBSIT
 LA RELATION D’AGRÉGATION ET DE COMPOSITION

• L’ Agrégation entre 2 classes est une relation bidirectionnelle,

qui exprime un couplage plus fort que la simple association
du fait qu’elle exprime des relations de type contenant-
contenu.

• La relation de Composition entre classes est une forme

d’agrégation avec un couplage encore plus fort : la destruction
de l’agrégat (l’objet en question) entraîne la destruction des
composants agrégés (les objets qui le constituent).

80
C.MOUBSIT
 LA RELATION D’AGRÉGATION ET DE COMPOSITION

81
C.MOUBSIT
 LA RELATION D’AGRÉGATION ET DE COMPOSITION

Agrégation

Composition

f/r61 Ex
82
C.MOUBSIT
 LA RELATION D’AGRÉGATION ET DE
COMPOSITION

83
C.MOUBSIT
 Polymorphisme

84
C.MOUBSIT
 POLYMORPHISME
 Notion de super type
 Le polymorphisme traite de la capacité d’un objet à posséder
plusieurs formes (plusieurs types : son propre type et les super

types).

Exemple: Un objet voiture peut être traité comme une Voiture, mais

aussi comme un Véhicule, mais aussi comme un

VehiculeAvecMoteur ou VehiculePersonnel.

 La POO autorise la redéfinition de méthode.

85
C.MOUBSIT
 POLYMORPHISME

86
C.MOUBSIT
 POLYMORPHISME

87
C.MOUBSIT
 POLYMORPHISME

 Au cours de l’exécution : Quelle méthode choisir ??

 Le polymorphisme est donc la capacité d’un système

à choisir, dynamiquement, la méthode qui

correspond au type réel de l’objet en cours.

88
C.MOUBSIT
 POLYMORPHISME

89
C.MOUBSIT
 PARAMÈTRE POLYMORPHE
Soit une nouvelle classe « Réparation » qui possède une
méthode réparer(…) dont le rôle est de réparer des
véhicules.

Pour réparer des voitures, nous devons écrire une

méthode déclarée comme suit : «Réparer(Voiture v)».

Pour les autres : «Réparer(Bus b)».

Pour des camions : «Réparer(Camion c)»…..

90
C.MOUBSIT
 PARAMÈTRE POLYMORPHE
On va se retrouver avec une prolifération de méthodes
qui remplissent le même rôle et dont seul le paramètre
qu’on lui transmet change.
Autant de méthodes que de types de véhicules n’est pas
vraiment une solution.

Nous allons donc nous baser sur la notion de super type

pour résoudre ce problème.

En effet «Voiture», «Bus», et «Camion» ont un type en

commun
91
C.MOUBSIT
 PARAMÈTRE POLYMORPHE

Donc on va créer une seule méthode :

« Réparer (Véhicule v ) ».

Et celle-ci va accepter tous les type de véhicule passé en paramètre.

Pour voiture, il sera accepte parce que l’objet voiture est un

véhicule, etc

 Paramètre Polymorphe

f/r72
92
C.MOUBSIT
 ORIENTE « OBJET»
OU PROCEDURAL ?

93
C.MOUBSIT
 ORIENTE « OBJET» OU PROCEDURAL ?
• Malgré la multitude de paradigmes et de langages de
programmation existants, tout problème pouvant être
résolu par un programme écrit dans un langage peut
également être résolu par un autre programme écrit dans
un autre langage.
• Cependant, même si la résolution du problème est faite, le
choix d'un paradigme plutôt qu'un autre ou d'un langage
plutôt qu'un autre peut influencer les qualités du
programme final.
• En effet, la qualité d'un programme n'est pas définie
seulement par le résultat obtenu, mais aussi par une
multitude de critères, certains plus importants que d'autres.

94
C.MOUBSIT
 ORIENTE « OBJET» OU PROCEDURAL ?
• La réalisation de logiciels est composée de
plusieurs phases dont le développement ne
constitue que la première partie.
• Elle est suivie, dans la plupart des cas, d'une
phase dite de maintenance, phase qui consiste à
corriger le logiciel et à le faire évoluer.
• Cette dernière phase représente 70 % du coût
total d'un logiciel. D'où la nécessité d'utiliser
des règles permettant d'assurer une certaine
qualité de réalisation.
95
C.MOUBSIT
 les plus importants critères
qu’il faut tenir compte lors de
la réalisation d'un projet

96
C.MOUBSIT
 CRITÈRES…
• Voici une liste des critères les plus importants dont il faut
tenir compte lors de la réalisation d'un projet :

la correction ou la validité: le fait qu'un logiciel effectue

exactement les tâches pour lesquelles il a été conçu.

l'extensibilité: la possibilité de modifier facilement le

logiciel pour l'adapter à des modifications effectuées au
niveau des spécifications de départ.

Exemple: introduire un nouveau type de véhicules dans

la simulation.
97
C.MOUBSIT
 CRITÈRES…
la réutilisabilité: les composants-logiciels écrits doivent
pouvoir être réutilisables, totalement ou en partie, dans un autre
logiciel.
Exemple: réutilisation de la classe « Voiture » de la
simulation dans la course de voitures;
la robustesse: l'aptitude d'un logiciel à fonctionner
correctement même dans des conditions anormales.
Exemple : attribuer une valeur négative à la vitesse d'un
objet « Voiture ».

NB: La robustesse est supposée atteinte si le logiciel est

capable de détecter qu'il se trouve dans une situation
anormale.
98
C.MOUBSIT
 CRITÈRES…

L’efficacité: cela se traduit par la bonne utilisation des

ressources (temps, mémoire, etc.).

Exemple: la simulation doit se faire en temps réel. Il ne

faut pas attendre trois heures pour simuler une minute de
trafic.

99
C.MOUBSIT
 Comparaison entre

programmation procédurale

et POO

100
C.MOUBSIT
 COMPARAISON ENTRE PROGRAMMATION
PROCÉDURALE ET POO
L ’Approche procédurale

• La base de la réflexion, pivote autour des traitements. Le

concepteur considère les tâches - que doit accomplir le
programme - en décomposant celui-ci en une série de tâches
simples.
• En procédant par étapes, on réduit chaque tâche en sous-tâches,
puis celles-ci en sous-tâches plus petites, et ainsi de suite
jusqu'à ce que les sous-tâches obtenues soient suffisamment
simples pour être implémentées directement en
fonctions(approche de haut en bas, approche descendante).

101
C.MOUBSIT
 COMPARAISON ENTRE PROGRAMMATION
PROCÉDURALE ET POO

L ’Approche procédurale

• Après avoir déterminé ces fonctions, on cherche la manière avec

laquelle on va stocker les données traitées par les fonctions.

• En résumé, dans l'approche procédurale :

o Algorithmes + Structures de données = Programme

• Avec cette approche, on a une séparation très nette entre les

données et les traitements.

102
C.MOUBSIT
 COMPARAISON ENTRE PROGRAMMATION
PROCÉDURALE ET POO

L ’Approche POO

• La POO inverse cet ordre et place les données au premier

plan avant de déterminer l'algorithme qui sera employé pour
traiter ces données.
• Nous identifions, d'abord, les classes (concepts) pour,
ensuite, chercher les méthodes. .
• Dans la démarche « objet », la décomposition conduit à
concevoir des objets.
• Le logiciel s'articule autour d'objets qui interagissent les uns
avec les autres.

103
C.MOUBSIT
 COMPARAISON ENTRE PROGRAMMATION
PROCÉDURALE ET POO
L ’Approche POO
 les données sont encapsulées dans l’objet. les traitement et les données
peuvent évoluer sans pour autant remettre en cause l’ensemble de
l’application.

Communication entre objets

104
C.MOUBSIT
 COMPARAISON ENTRE PROGRAMMATION
PROCÉDURALE ET POO

Différence entre les deux approches

• Afin de montrer la différence entre l’approche

procédurale et orienté «objet», nous proposons d’étudier
et d’appliquer ces deux approche sur un exemple concret.

• L’exemple que nous avons choisi présent la réalisation

d’une application nécessitant 1000 fonction en
programmation procédurale.

105
C.MOUBSIT
 COMPARAISON ENTRE PROGRAMMATION
PROCÉDURALE ET POO
Fonction 1

Fonction 2 Données La réalisation d’une

Globales
application avec une
Fonction 3 approche procédurale

Fonction ….

Fonctions 1000 1000

• Si une erreur survient au niveau des données, il devient

difficile d’identifier la fonction coupable puisque toutes
les fonctions peuvent modifier la donnée en question.
106
C.MOUBSIT
 COMPARAISON ENTRE PROGRAMMATION
PROCÉDURALE ET POO
• La réalisation de cette application en POO pourra, par exemple
être décomposée en 50 classes possédant, en moyenne, 20
méthodes chacune.

Fonction 1 Données

Fonction 50 de
l’objet la réalisation d’une
application avec une
Données
Fonction 1
de
approche orienter
Fonction 50
l’objet
« objet »
Données
Fonction 1 de
Fonction 50 l’objet

107
C.MOUBSIT
 COMPARAISON ENTRE PROGRAMMATION
PROCÉDURALE ET POO

• Cette structure est plus facile à maîtriser par un

programmeur et à répartir parmi les membres d’une
équipe.

• Si une données devient erronée, il est plus facile de

trouver la méthode responsable de l’erreur parmi les 20
méthodes permettant d’accéder à ses donnes que de
trouve la méthode responsable parmi les 1000 fonctions
de la programmation procédurale.

108
C.MOUBSIT
 Avantages et Inconvénients
des deux approches

109
C.MOUBSIT
 PROGRAMMATION PROCÉDURALE
Avantages Inconvénients

* La modularité des programmes n’est pas optimale :

* Les programmes possèdent Une certaine les modules sont adaptées au type de problème
modularité. pose au départ et ne permettant que peu
d’extensibilité du système obtenu et peu de
* L’approche est logique et facile à réutilisabilité.
comprendre. * Cette approche implique une forte dépendance du
programme par rapport aux données : il est difficile,
dans ces conditions, de maintenir et de protéger les
structures des donnes.

* Il n’est pas toujours évidant d’identifier le traitement,

ou leurs enchainement, impliqués dans un système
informatique complexe (exemple : système
d’exploitations).

* La programmation procédurale s’appuie sur des

spécifications stables or les spécifications sont loin
d’être stables, ce que conduit à la fragilité du
système .

* La modification des données induit la modification

des fonctions qui les utilisent.

* Il est difficile de comprendre et de réutiliser des

110
C.MOUBSIT programmes complexes ou faits par d’autres
 POO
Avantage Inconvénients

* L’approche à de bonnes qualités de

modularité. * L’ approche engendre une perte apparente
* On peut développer une partie d’un de la logique séquentielle d’un programme.
programme sans connaitre les détails Problème qui se pose, surtout, pour les
internes des autres parties, cela facilite le débutants en programmation.
partage des tâches au sein d’une équipe.
* On peut apporter des modifications locales à
un module sans que cela n’affecte le reste du
programme.
* On peut réutiliser des classes développé
dans un projet différent.
* L’extension des fonctionnalités d’un
programme se fait de manière simple et
rapide.
* Les donnes sont bien protégées grâce au
mécanisme d’encapsulation.
* (voir tous les autres avantages expliqués
dans les chapitres précédents)

111
C.MOUBSIT
 Choix d’un paradigme

112
C.MOUBSIT
 CHOIX D’UN PARADIGME

• Si votre application doit fournir un résultat à un instant «t+1»

qui dépend du résultat précédent à l'instant t, il est préférable de
choisir la POO.

• C'était le cas de notre simulation.

• En effet, pour connaître l'état du trafic à un instant précis, nous

devons nous baser sur l'état du trafic à l'instant précédent et
ainsi de suite jusqu'à atteindre l'instant où la simulation
démarre.

113
C.MOUBSIT
 CHOIX D’UN PARADIGME
• La raison du choix de la POO est très simple à comprendre.
Pour calculer la vitesse d'un véhicule à un instant « t+1», nous
devons nous baser sur sa vitesse à l'instant t.
• Il faut donc avoir stocké cette vitesse quelque part. Le même
raisonnement s'applique pour l'état « démarré» ou « arrêté»,
« changement de voie », etc.
• Donc, chaque véhicule doit stocker un ensemble de valeurs
(état interne) sur lesquels nous nous basons pour trouver
l'état suivant. De manière intuitive.

• Nous pouvons conclure que la meilleure façon de procéder

est d'avoir différents objets « véhicule », chacun stockant son
propre état.
114
C.MOUBSIT
 CHOIX D’UN PARADIGME
• Si, par contre, nous voulons réaliser une application dont
le but est d'effectuer des calculs mathématiques, nous
allons devoir implémenter un ensemble de fonctions
mathématiques.

• La question à se poser est la suivante:

«est-ce qu'une fonction mathématique a besoin de
connaître l'état précédent de notre application pour nous
fournir un résultat correct ??? »

• La réponse est Non !!!.

115
C.MOUBSIT
 CHOIX D’UN PARADIGME
• Exemples :

• la méthode int max (int a, int b) une fonction à laquelle

nous passons deux entiers et qui retourne le plus grand
des deux.
• Cette fonction a-t-elle besoin d'autres variables, autres
que ses variables locales a et b, pour fonctionner
correctement? (La réponse est NON).
• Est-ce que le fait d'avoir calculé max (3 ,4) va influencer
le calcul suivant: max (6 .9) ???

116
C.MOUBSIT
 CHOIX D’UN PARADIGME
•

117
C.MOUBSIT
 CHOIX D’UN PARADIGME

• Nous nous apercevons donc que l'ensemble de nos

fonctions n'ont besoin que des valeurs que nous leur
transmettons pour remplir leurs tâches et que le
résultat d'un calcul n'est pas influencé par le calcul
précédent.

• Dans ce cas nous pouvons nous passer de

l’oriente « objet» et utiliser la programmation
procédurale qui est plus adaptée.

118
C.MOUBSIT
 CHOIX D’UN PARADIGME
• Un autre critère de choix du paradigme à utiliser,
consiste en la nature du projet sur lequel nous
travaillons.

• Un projet de taille moyenne ou petite, nécessitant une

personne ou deux pour son développement avec un
cahier de charges fixe dans le temps peut, parfaitement,
être développer en recourant à la programmation
procédurale.
• Fin
119
C.MOUBSIT
 Critères de qualité
d’un logiciel

120
C.MOUBSIT
 CRITÈRES DE QUALITÉ D’UN LOGICIEL

Correct
- Le logiciel est capable de produire exactement les fonctions qu'on lui
demande par les spécifications.
- Demander 20$ au guichet bancaire automatique => obtenir 20$.
Robuste
- Le logiciel est capable de bien fonctionner dans des conditions
anormales.
- essayer une séquence de touches NON prévue au guichet bancaire
automatique => ne donne pas 500$ en conséquence.
Extensible
- Il est possible de modifier le logiciel simplement pour l'adapter à des
modifications dans les spécifications.
121
C.MOUBSIT
 CRITÈRES DE QUALITÉ D’UN LOGICIEL

Extensible
- Ajouter une nouvelle fonction dans le guichet
bancaire automatique
Réutilisable
- Le logiciel peut être utilisé intégralement ou en partie
dans de nouvelles applications.
- Distributeur de boissons => Distributeur de tickets de
métro.
Portable
- C'est la facilité d'exécuter le logiciel sur différentes
plates-formes.
122
C.MOUBSIT
 CRITÈRES DE QUALITÉ D’UN LOGICIEL
Efficace
- Cela se traduit par la bonne utilisation des ressources
(temps, mémoire, etc.)
- Ne pas attendre 15 minutes au guichet bancaire
automatique pour retirer 20$!

123
C.MOUBSIT