La Programmation par les Objets

(1)

La Programmation par les Objets

  ^

Najib TOUNSI



Notes de cours:

2e année Informatique EMI

Last update :Sept 2009

(2)

I. LES FONDEMENTS DE LA POO II. LES CONCEPTS DE LA POO

III. LES LANGAGES A OBJETS

(3)



The Software Crisis

✗ Faire des programmes faciles à concevoir et mettre au point

✗ Programmes plus sûrs et plus fiables

✗ Programmes facilement maintenables, évolutifs et réutilisables

(4)

La POO repose sur des idées telles que:

◆ L'Abstraction:

Transparence et indépendance par rapport aux détails d'implantation

➪

« Données » manipulables par les opérations indépendamment de leur structure interne.

◆ Modularité:

Séparation des tâches/concepts en unités indépendantes

➪

Flexibilité / Réutilisation, Encapsulation / Protection...

◆ Héritage:

Classification des genres, développement progressif et structuré

.

➪

Une secrétaire est d'abord une employée. Un cercle est aussi une ellipse.

➪

Un vecteur est basé sur une liste dans laquelle on écrit et lit à un rang donné.

(5)

FONDEMENTS DE LA POO

◆

Caractériser les données par les opérations de manipulation (vs. leur structure et donc la façon de les utiliser, i.e. set = tableau, ==> accès par t[i] i=1..n, avec éventuellement for...)

 abstraction

On parlera donc d'objet et d'opérations

◆

Grouper les données parce qu'ils se manipulent de la même facon (opérations communes)

 modularité toute trouvée?

(6)

TYPE ABSTRAIT DE DONNÉES

On appelle type abstrait de données (TAD) un ensemble d'objets caractérisés par les opérations qui leur sont tous applicables.

Ang. Abstract Data Type (ADT)

Exemples:

pile

empiler(), dépiler(), sommet() …

Rectangle

tracer(), périmetre(), surface(), zoomer()

fenêtre

Afficher(), cacher(), agrandir(), déplacer() …

collection

ajouter, supprimer, appartient…

 Ce qui importe, c'est le concept véhiculé par un objet (et non la structure de données sous-jacente)

/* C'est plus stable */

(7)

TYPE ABSTRAIT DE DONNÉES

• Aspect Syntaxique

Profile des opérations (entête, prototype) Ex. Plus : N x N  N

• Aspect Sémantique

Sémantique des opérations, sens / comportement du type de donnée.

Ex. Plus (Succ (x), y)) = Succ (Plus(x, y))

• Représentation

Choix d’implantation

(8)

TYPE ABSTRAIT DE DONNÉES

 Schéma Syntaxique:

Profile des opérations

(ou entêtes)

Soit B (les booléens), P (les piles) et N (les entiers)

Type P =

vide :  P

/* Crée une pile vide et la retourne en résultat.*/

emPiler : P x N  P sommet : P  N déPiler : P  P pileVide : P  B pilePleine : P  B Fin

(9)

TYPE ABSTRAIT DE DONNÉES

 Aspect sémantique:

Spécification du comportement

(Fait partie de la description d'un TAD)



Par Commentaires: Verbosité, mais simple et facile (Clarté ?) vide () → Crée une pile vide et la retourne en résultat.

empiler (p, n) → Rajoute l’entier n au sommet de la pile p, et la retourne en résultat.

PileVide (p) → Teste si la pile p est vide.

etc.



Pré/Post conditions: Ce qu'exige une opération, et ce qu'elle garantit Pas toujours faciles mais plus formelles.

Empiler (p, n) Requiert: Non PilePleine( p )

Garantit: Non PileVide( p ), Sommet( p ) = n

cf. Programmation par contrat. Langage Eiffel cf. Assertions Java.

(10)

TYPE ABSTRAIT DE DONNÉES

 Aspect sémantique (suite)



Par Axiomes: On dit aussi de Spécifications algébriques. (Formelles)

Dépiler (Vide ()) = ERREUR Dépiler (Empiler (p, n)) = p

Sommet (Vide ()) = ERREUR Sommet (Empiler (p, n)) = n

PileVide (Vide ()) = Vrai PileVide (Empiler (p, n)) = Faux

☞

: Les axiomes traduisent les invariants qui caractérisent les propriétés d’un objet.



(11)

TYPE ABSTRAIT DE DONNÉES

 Notion de constructeur 

 

Opérations permettant d'obtenir (construire) tous objets potentiels d'un certain type.

N.B. Axiomes spécifient l'effet de certaines opérations ( dites

sélecteurs ou fonctions d’accès

) sur d'autres (dites

constructeurs

)

Constructeurs pour le TAD

pile

: •

vide()

•

empiler()

(12)

TYPE ABSTRAIT DE DONNÉES

 Notion de constructeur (suite) 

empiler ( empiler ( empiler ( vide(), 1), 4), 3) empiler ( empiler ( ( vide(), 1), 4)

empiler ( empiler ( empile r( vide(), 1), 4), 5)

☞ Notion importante reprise dans les langages à objets

.

(13)

TYPE ABSTRAIT DE DONNÉES

Autre exemple: Objet Date (constituée de 3 entiers)

Type Date = Profiles

Date :N X N X N → D Jour : D → N

Mois : D → N

Année : D → N

Demain : D → D Axiomes:

Jour ( Date ( j, m, a)) = j;

Mois ( Date ( j, m, a)) = m;

Année ( Date ( j, m, a)) = a;

Demain ( Date ( j, m, a)) = si j< 28 alors Date(j+1, m, a) sinon /* faire le plus dur ...*/

Date(1, m+1, a) Fin

Remarque : Pour plus d’abstraction, introduire les TAD Jour/Mois/Année au lieu des trois

(14)

entiers.

(15)

TYPE ABSTRAIT DE DONNÉES

Exercices:

• Quelles seraient les pré/post conditions de l'exemple Date.

• Définir les TADs:

Collection (d'entiers) Un article de commerce

Un autre TAD de votre choix (inspiré de l'informatique matériel/logiciel) Entier naturel (utiliser axiomes de Peano)

N.B. : Indiquer les constructeurs éventuels.

 

(16)

TYPE ABSTRAIT DE DONNÉES Objet Collection (d’entiers)

Type ColEnt = Profiles

Vide : → C Ajout : C X N → C Appt: : C X N → B Supp: : C X N → C EstVide: : C → B

Axiomes /* Ensemble sans double */ /* c

Collection ; x, y entiers */

Appt ( Vide(), x) = Faux

Appt ( Ajout (c, y), x) = si (x=y) alors Vrai sinon Appt ( c, x)

Supp ( Vide(), x) = Vide()

Supp ( Ajout (c, y), x) = si (x=y) alors Supp (c, x) sinon Ajout ( Supp (c, x), y)

EstVide ( Vide()) = Vrai EstVide ( Ajout (c, y)) = Faux Fin

Exercice: "Ensemble" avec Double ?

(17)

TYPE ABSTRAIT DE DONNÉES

 Représentation:

Choix d'implémentation du TAD (concrétisation).

Structure de données + algorithmes des opérations

Type Pile:

Représentation

tableau t [MAX];

entier top;

opérations

Vide (p) { p.top = -1; } Empiler (p, n) { p.top = p.top+1;

p.t[p.top] = n; } Depiler(p) { p.top = p.top-1; } Sommet(p) { return p.t[p.top]; } PileVide(p) { return p.top < 0; }

PilePleine(p) { return p.top = (MAX-1); } fin

☼

(18)

TYPE ABSTRAIT DE DONNÉES

 Représentation



Remarque: Prise en compte des cas d'exceptions dans les algorithmes (spécif. sans Pré/post):

Empiler (p, n) {

if top<(MAX)

p.top = p.top+1;

p.t[p.top] = n;

else

erreur("pile pleine");

endif }



Exercices:  Programmer le reste des opérations.

 Choisir et programmer la représentation des TADs de l'exercice précédent.

(19)

TYPE ABSTRAIT DE DONNÉES

 Exemple de mise en oeuvre:



"Ecrire l’image miroir d’un mot.( emir -> rime)

char c; pileChar p;

p = Vide();

Lire (c);

while (c défini)

if (not PilePleine(p)) Empiler(p, c);

lire (c) endwhile

while (not PileVide(p)) c = Sommet(p);

écrire(c) Dépiler(p);

endwhile

(20)

TYPE ABSTRAIT DE DONNÉES

 Ce qu'est l' Abstraction Å   %

^L

✘ Objets connus à travers une interface officielle

(et non à travers leur représentation) ✔ On n'a pas besoin de connaître sa représentation, pour utiliser un objet

✔ On peut différer son choix (i.e. développer sans avoir encore décidé comment la faire).

✔ On peut la changer l'implémentation sans remettre en cause les programmes

✘ Pour programmer, on n'a besoin de connaître que la spécification du TA: (le quoi)

profile et sémantique des opérations (càd l'interface)

✘ On ne se préoccupe pas des détails d'implémentation

,

✔ On se concentrer sur l'essentiel, ce qui fait l'intérêt d'un objet (de quoi a-t-on besoin) ✔ Un objet est une abstraction (modélisation) d'une réalité.

✘ Un TAD peut être conçu indépendamment du système auquel il appartient

✔ Il peut être réutilisé pour plusieurs systèmes différents.



(21)

MODULARITÉ

 Compilation séparée et modularité

Pour maîtriser la complexité d'un système logiciel, il est nécessaire de le décomposer en éléments plus simples, appelés modules. Le système sera vu comme une composé de plusieurs unités, chacune réalisant une tâche bien spécifique.

 Chaque module peut constituer une unité de compilation (compilé séparément).

 Un programme est composé d'un ensemble de modules.

 Programme principale = appels nécessaires pour lancer et contrôler l'application.

 Relations (interconnexion) entre modules réduites au stricte nécessaire.

 Chaque module peut être écrit en plusieurs versions.

 Modules autonomes pouvant servir ailleurs (réutilisés).

 Chaque module doit avoir une interface bien spécifiée.

(22)

MODULARITÉ

 Décomposition Modulaire : Cas 1

✘ Procédures ou fonctions classiques

✔ Des fonctions plus élémentaires concourent à la réalisation de la fonction globale.

✔ Processus réapplicable.

✔ Paradigme Cartésien.

❦

(23)

MODULARITÉ

Insuffisances décomposition modulaire classique /

 Interactions possibles par partage de données globales en plus des appels explicites.

 Evolution des spécifications pas toujours facile à traduire. (un programme correspond aux fonctions demandées et se révèle plus rigide).

 Découpage centré autour des étapes de calcul (vs les objets ou entités d'intérêt).

 Parfois (e.g. programmes interactifs) on n'a pas d'ordre de traitement préétabli.

 Fonctions opèrent sur des données sans discernement.

 Changement dans structures de données peuvent avoir de graves conséquences.

(24)

Exemple

d'illustration (2 derniers points).

Générer et imprimer 6 nombres aléatoires

begin

tableau P.



Remplir P avec 6 nombres aléatoires



Imprimer P end



.



.

aléatoire () { ...}

for j = 1 to i-1 if (P[i] = a) then return true endfor

return false



while i < 6



. a = aléatoire();



. if not appartient (a, P) then P[i] = a;

i = i+1 endif

endwhile



while (i < 6) écrire (P[i]) endwhile

(25)

Remarques:



Défaut d'abstraction • La structure de données contraint la conception •

• On a déja choisi un tableau

• On agit directement sur ce tableau

Nouvelles exigences.

✔ On voudrait une liste chaînée

✔ n nombre aléatoires au lieu de 6

✔ Imprimer ces nombre dans l'ordre croissant.

✔ etc.



(26)

MODULARITÉ

 Décomposition Modulaire : Cas 2  Modules de PARNAS

(D. L. PARNAS 1972)

◊ Un module est un ensembles de fonctions (ou procédures) logiquement reliées et pouvant partager des données communes, ressource, déclarées au sein du module.

◊

Protection de l'information «information hiding» ( cf. encapsulation). Seuls les procédures autorisées peuvent accéder à la ressource.

◊

Module = boite noire connu par ses propriétés officielles, son interface, (conservant en son sein les détails internes).

◊

Un programme est un ensemble des tels modules qui utilisent leurs services les uns les autres.



(27)

MODULARITÉ

 Modules de PARNAS : exemple

☛

Module GestEmp

file employes;

. . . proc créer

{. . . }

proc ajouter (employé e) { . . .}

proc supprimer (employé e) { . . .}

proc chercher (ident id) --> employé { . . .}

proc augSalaire (integer tx) {. . .}

etc.

end

(28)

MODULARITÉ

 Modules de PARNAS: à noter



 Le fichier est protégé des accès extérieurs (sources d'erreurs).

 L'interface est l'entête des procédures avec les spécifications nécessaires.

 On peut changer d'organisation de fichier sans changements sur le reste.

 Mise au point et maintenance faciles.

 Effets des changements localisés.

 Paramétrage par le type de fichier possible

etc.

(29)

MODULARITÉ

 Intérêts

 Développement progressif et structuré.

 Modules extensibles et réutilisables

 Les changements sont localisables et leurs effets localisés.

 Pas nécessaire de recompiler toute l'application.

 Bibliothèque de composants logiciels.

(30)

MODULES et TYPES ABSTRAITS DE DONNEES

1968 → Langage SIMULA(Norvège): Notion de classe groupe des déclarations de variables représentant un objet, leur initialisation et les fonctions d'accès correspondantes.

Smalltalk est le premier langage à prendre la relève.

1972 → Travaux de D. PARNAS: Notion de module avec masquage des informations qui est une grande contribution. Extensibilité et réutilisabilité.

1974 → B. LISKOV: Tentative de formalisation avec la notion de TAD qui encapsule les opérations et cache la structure sous-jacente d'un objet.

Langages CLU, ALPHARD, MODULA ... ADA

 SmallTalk Objective_C C++ Eiffel Java...

(31)

PROGRAMMATION DIRIGÉE PAR LES DONNÉES

Algorithms + Data Structures = Programmes

Privilégier les données plutôt que les traitement.



Pour traiter un problème, on commence par définir les types (abstraits) d'objets

^appropriées, avec leurs opérations spécifiques. Chaque entité manipulée dans un programme étant une instance, un objet d'un de ces types.



L'univers d'un problème est modélisable en un ensemble d'objets, détenant chacun les clés de leur comportement et représentant les centres d'intérêt du problème.

Plutôt qu'un ensemble de routines opérant sur des données sans discernement.



L'aspect dynamique du problème est modélisé par les échanges de messages entres objets (appels des services offerts par leur type)



L'unité modulaire dans un tel système est une classe qui décrit une implémentation d'un TAD

(32)

_____________________________________________

_____________________________________________________________________________________________________________

Les Langages à Objets 31

_____________________________________________________________________________________________________________

***********************************************************************************************************************

**********************************************************************************************

31

La Programmation par les Objets