Ce cours introduit la programmation orientée objet (encapsulation, abstration, héritage, polymorphisme) en l'illustrant en langage Java. Il présuppose connues les bases de la programmation (variables, types, boucles, fonctions, ...). Il est conçu comme la suite du cours « Initiation à la programmation (en Java) ». Comme son prédécesseur, ce cours s'appuie sur de nombreux éléments pédagogiques : vidéos sous-titrées, quizz dans et hors vidéos, exercices, devoirs notés automatiquement, notes de cours.
Introduction
Loading...
En provenance du cours de École Polytechnique Fédérale de Lausanne
Introduction à la programmation orientée objet (en Java)
175 notes
École Polytechnique Fédérale de Lausanne
175 notes
À partir de la leçon
Introduction à la Programmation Orientée Objet
Cette semaine vous accueille dans le cours et vous présente les premiers concepts de base de la programmation dite « orientée objet ».
Rencontrer les enseignants
Jamila SamDr
School of Computer and Communication Sciences
Jean-Cédric ChappelierDr.
School of Computer and Communication Sciences
Nous abordons aujourd'hui ensemble un volet très important de votre
apprentissage de la programmation,
à savoir la programmation dite orientée objet.
Il s'agit d'une façon particulière de programmer qui n'est d'ailleurs pas
spécifique au langage Java, qu'on va pouvoir retrouver dans d'autres langages
et qui va conférer, donner à vos programmes un certain nombre de propriétés
intéressantes, notamment en termes de maintenabilité et de modularité.
A ce stade du cours, vous êtes censés connaître un certain nombre d'éléments
fondamentaux relatifs à la programmation tout court.
Vous savez par exemple exprimer des traitements en utilisant des structures de
contrôle comme par exemple des boucles conditionnelles.
Vous savez aussi structurer un minimum vos données en
utilisant par exemple des tableaux et vous savez surtout modulariser vos programmes
en utilisant la notion centrale de fonction.
Cet outillage de base va vous permettre d'exercer un style de programmation
particulier dit programmation procédurale ou impérative,
qui a la particularité de faire en sorte que les données et les traitements
apparaissent de façon séparée dans dans un programme.
Certes, il y a une interaction entre les deux.
Les traitements opèrent typiquement sur les données, lesquelles influencent à leur
tour les traitements mais les deux entités apparaissent de façon séparée.
Par exemple,
les traitements peuvent s'exprimer par le biais de fonctions et le lien entre
données et traitements peut se faire alors par le biais du passage des arguments.
Les données manipulées apparaissent
au travers d'entités distinctes comme par exemple des variables.
Une des particularités fondamentales de l'orienté objet est de permettre le
regroupement des traitements et des données en une seule et même entité.
Partons d'un exemple concret.
Imaginons par exemple que je souhaite écrire un programme qui travaille
avec la notion de rectangle.
Un rectangle est défini par une largeur, une hauteur et une des manipulations
que je souhaite faire sur les rectangles est le calcul de la surface du rectangle.
En programmation procédurale,
j'aurais tendance à faire les choses de cette façon-là.
Je vais déclarer une variable pour la largeur à laquelle je vais donner une
valeur particulière, également une variable pour la hauteur,
en l'initialisant à la valeur qu'il lui faut et ensuite,
je peux calculer la surface du rectangle en passant la largeur et la hauteur à une
fonction qui me permet de faire le bon calcul.
Alors, on voit bien au travers de cet exemple que les données et les traitements
s'expriment de façon séparée.
Les variables me permettent de représenter et de stocker mes données
et ma fonction de surface me permet de réaliser les traitements.
Ces deux entités sont séparées dans le programme.
Le lien se fait entre les deux par le biais du passage des arguments.
Une critique fondamentale que l'on peut émettre
sur ce programme est l'absence de lien sémantique entre les différentes entités.
Par exemple, le lien sémantique qui unit la largeur et la hauteur, en fait, c'est
la largeur et la hauteur d'un rectangle, n'est pas immédiatement visible.
Si je ne suis pas francophone,
que je ne comprends pas très bien ce que veut dire largeur et hauteur,
il est très difficile pour moi de voir qu'il existe un lien entre les deux.
Il s'agit de la largeur et de la hauteur d'un rectangle.
De même, le lien sémantique entre les données
et les traitements est difficile à établir.
Par exemple, imaginez que j'appelle ma fonction,
ma méthode, produit, donc un nom moins parlant, et que je sois aussi
un peu moins explicite sur le nom des arguments, eh bien,
il devient très difficile pour moi de voir ici que je fais un calcul de surface.
Donc, hormis ce petit texte explicatif, le lien sémantique qui existe entre les
données et le traitement est relativement difficile à voir dans ce programme.
Hors, ce lien existe conceptuellement.
Ici, c'est bien la notion de rectangle que je souhaite
manipuler au travers de la largeur et de la hauteur et ici,
c'est bien la surface d'un rectangle que je souhaite calculer.
Donc, le fait de pouvoir regrouper en une seule et même entité
la notion de rectangle, les données caractéristiques du rectangle, à savoir sa
largeur et sa hauteur, et les traitements qui s'y attachent spécifiquement
permettent d'établir explicitement le lien entre ces différentes entités.
Il s'agit là de l'un des fondamentaux de la programmation orientée objet.
Ce qu'il faut savoir de façon globale, c'est que la programmation orientée objet
va vous donner un certain nombre d'outillages permettant davantage de
robustesse, de modularité, de lisibilité
à vos programmes, ce qui va dans le sens d'une meilleure maintenabilité.
Alors, robustesse par rapport au changement.
Si votre programme est amené à changer un jour,
à être étendu ou qu'on ne veut pas être dans l'obligation de tout réécrire
et de robustesse face aux erreurs de manipulation, par exemple des données.
En effet, la plupart des applications développées de nos jours ne sont pas
redéveloppées depuis zéro mais consistent à étendre, à maintenir du code existant
et il est important de pouvoir le faire à moindre coût.
Nous allons voir que les propriétés fondamentales de l'orienté objet,
à savoir davantage de robustesse,
de modularité et de lisibilité vont exactement dans ce sens-là.
La programmation orientée objet offre en réalité quatre concepts centraux,
encapsulation, abstraction, héritage et polymorphisme, qui permettent de mieux
organiser les programmes dans le sens de la robustesse, lisibilité, modularité et
maintenabilité comme je l'ai exprimé tout à l'heure et ces concepts centraux ne sont
pas spécifiques à un langage, il s'agit des concepts centraux de l'orienté objet.
Dans la séquence présente, nous allons essentiellement nous occuper de définir
encapsulation et abstraction et nous aborderons dans les séquences suivantes
les notions fondamentales d'héritage et de polymorphisme.
Ce que l'on entend par encapsulation,
c'est le fait de pouvoir regrouper dans une seule et même entité des
données et les traitements qui agissent sur ces données.
Donc typiquement dans l'exemple du rectangle, nous allons regrouper
dans une seule et même entité, la largeur et la hauteur qui caractérisent la
représentation du rectangle et la fonctionnalité du calcul de surface.
Donc en terme de jargon, on va parler pour les données de la notion d'attribut
et on va parler pour les fonctionnalités de la notion de méthode.
Donc, en programmation orientée objet,
on va être dans la possibilité de définir des nouveaux types de données au travers,
nous allons le voir un peu plus tard, de la notion de classe.
Ces types de données peuvent être utilisés pour travailler concrètement avec des
données de types plus abstraits, le rectangle, et ces données vont
être des objets qui vont cohabiter dans le programme et interagir dans le programme.
Un programme orienté objet va donc typiquement travailler avec des objets
qui sont caractérisés par leurs attributs et leurs méthodes.
Parlons un peu de la notion d'abstraction.
Imaginez que je souhaite écrire un programme qui manipule un certain nombre
de rectangles, pas uniquement un seul.
Donc, dans une approche procédurale, je devrais déclarer autant
de variables hauteur et largeur que j'ai de rectangles.
Donc ceci pour le premier et puis je devrais faire
exactement la même chose pour le second rectangle.
Donc, on voit que c'est relativement fastidieux.
Imaginez par exemple que je travaille maintenant
avec des rectangles en trois dimensions où j'ai non seulement une hauteur,
une largeur mais aussi une profondeur, eh bien,
je me retrouverais avec six variables à devoir initialiser de façon appropriée.
Pour mon calcul de surface eh bien pour chacun des rectangles, je devrais invoquer
ma méthode de calcul de surface en passant à chaque fois les bons arguments.
[AUDIO_VIDE]
Donc, on voit rapidement que c'est fastidieux et puis,
c'est source d'erreurs.
Imaginez que je me trompe, et qu'ici je fasse
un calcul de surface qui implique hauteur 1 et largeur 2.
Du coup, je perds la cohérence,
je n'ai plus le bon calcul de surface pour chacun de mes rectangles.
Alors, le mécanisme, le processus de l'abstraction
est le processus par le biais duquel je me rends compte qu'effectivement
pour chacun des rectangles qui apparaît dans mon programme,
j'ai la même représentation générique au travers d'une largeur et d'une hauteur.
J'ai un même calcul de surface qui intervient.
Du coup, je vais pouvoir travailler avec une notion beaucoup plus abstraite qui est
celle de rectangle.
Le mécanisme de l'encapsulation va me permettre de regrouper
dans la notion de rectangle tout ce qui est nécessaire à le modéliser.
[AUDIO_VIDE] Du coup,
je vais permettre à mon programme de désormais pouvoir travailler
avec des entités plus abstraites.
Je vais travailler avec un premier rectangle et un deuxième rectangle,
tous les deux de type rectangle dans le programme,
je vais invoquer des calculs de surface sur ces rectangles.
On va voir qu'en orienté objet, j'anticipe un petit peu sur la suite, que on va dire,
je calcule la surface du premier rectangle.
Donc, on va voir par la suite comment tout ceci s'exprime de façon beaucoup plus
précise, et du coup,
eh bien, je permets à mon programme de se focaliser sur l'essentiel.
Donc, je ne suis plus en train de me préoccuper du fait qu'un Rectangle
est constitué d'une largeur et d'une hauteur.
Je me focalise sur les aspects essentiels.
Je travaille avec des Rectangles, je fais un calcul de surface sur un Rectangle.
Au niveau de l'utilisation,
je ne vois désormais du Rectangle que ce que l'on appelle en jargon orienté objet
son interface d'utilisation, c'est-à-dire les fonctionnalités qui sont offertes
pour la manipulation du Rectangle, comme ici le calcul de surface.
Faisons une analogie avec un objet de la vie courante.
Lorsque vous conduisez votre voiture,
vous n'avez typiquement besoin d'en connaître que l'interface d'utilisation.
Concrètement, eh bien, vous avez besoin d'avoir un volant, un accélérateur,
une pédale de frein.
Et à nul moment,
il ne vous est utile de savoir comment le moteur est concrètement construit.
Donc, pour conduire votre voiture,
vous n'avez besoin d'en connaître que l'interface d'utilisation.
C'est exactement le même principe en programmation orientée objet.
Pour utiliser un nouveau type d'objet,
une nouvelle classe, vous n'avez besoin d'en connaître que l'interface
d'utilisation qui est prévue par le programmeur de la classe.
Le reste est du détail d'implémentation interne qu'il n'est pas utile
de connaître.
Il y a donc deux niveaux de perception d'un objet.
Un niveau externe qui est utile au programmeur utilisateur,
celui qui utilise la notion de Rectangle.
Dans un programme, donc il existe désormais un type Rectangle.
Je peux déclarer des variables de type Rectangle,
les initialiser de façon appropriée.
Et ensuite, ce qui m'intéresse en tant que programmeur utilisateur,
c'est les fonctionnalités utiles, le calcul de surface.
Donc, ce niveau externe est le niveau qui intéresse le programmeur utilisateur,
celui qui utilise le type Rectangle.
Second niveau, le niveau interne, celui qui a programmé le nouveau type,
le type Rectangle, a dû se préoccuper de tous les détails d'implémentation.
A savoir qu'un Rectangle, c'est une hauteur et une largeur.
Il a dû définir comment se fait concrètement le calcul de surface.
Donc ceci constitue la partie implémentation.
C'est un niveau interne qui n'est pas forcément utile à celui qui utilise
le Rectangle.
Donc, en programmation orientée objet, nous aurons non seulement la possibilité
de regrouper en une seule et même entité des données et des traitements.
Mais, on va pouvoir également définir des niveaux de visibilité.
Celui qui programme le nouveau type Rectangle,
concrètement une classe Rectangle, va pouvoir dire ceci est un détail
d'implémentation qui ne sera pas accessible à l'utilisateur externe.
Ceci est une fonctionnalité que l'on souhaite offrir à l'utilisateur
externe et donc qui va être accessible à cet utilisateur.
Tout ce qui est accessible à l'utilisateur, donc visible, constitue ce
que l'on appelle l'interface d'utilisation de la classe, du type en question.
Donc ici, dans notre classe Rectangle, dans notre nouveau type Rectangle,
nous avons défini comme interface d'utilisation le calcul de surface.
Le reste constitue des détails d'implémentation qui ne
sont pas accessibles au programmeur qui utilise le type Rectangle.
Et nous avons ici une clé fondamentale nous permettant d'atteindre l'objectif
d'une meilleure robustesse de nos programmes face au changement.
Typiquement, lorsque vous changez de voiture,
même si la technologie du moteur a changé, l'interface globalement reste la même.
Vous pouvez continuer, vous savez toujours conduire votre voiture, même si les
détails internes de mise en œuvre de votre voiture ont changé entretemps.
Donc, vous ne voyez de votre voiture que quelque chose d'abstrait.
Vous ne voyez de votre voiture concrètement que ce qui vous permet de la
conduire, à savoir le volant, l'accélérateur, la pédale de frein.
Pour synthétiser, encapsuler c'est donc regrouper en une seule et même
entité les données et les traitements qui la caractérisent.
C'est aussi dissimuler les détails d'implémentation.
Définir une interface d'utilisation d'une classe d'objet,
justement au travers de cet outillage de l'encapsulation, va nous
permettre d'aboutir à une abstraction, une vision abstraite de l'objet.
On ne va voir de l'objet que ce qu'offre
son interface d'utilisation en termes de manipulations possibles.
Donc concrètement,
le programmeur concepteur va donc décider de l'existence d'un
nouveau type et va devoir se préoccuper de tous les détails d'implémentation.
Il va devoir décider de ce qui est
visible pour le monde extérieur, de ce qui est utilisable et de ce qui ne l'est pas.
Le programmeur utilisateur de son côté est client du nouveau type de données.
Il va pouvoir l'utiliser.
Mais va pouvoir l'utiliser uniquement au travers de l'interface,
c'est-à-dire des méthodes visibles, typiquement.
Et n'aura pas accès aux détails internes.
L'interface d'utilisation est typiquement ce qui va permettre
d'établir le lien entre le concepteur développeur et l'utilisateur.
Et de façon très concrète, cette interface va pouvoir être entièrement décrite par
l'entête des méthodes qui sont offertes au programmeur utilisateur.
Alors, un des intérêts fondamentaux d'abstraire et d'encapsuler est d'assurer
une meilleure visibilité, une meilleure cohérence au programme.
Comparez ici une approche procédurale, où je manipule des données de bas niveau,
avec l'approche orientée objet, que vous allez être capables
dès les séquences suivantes de pouvoir programmer par vous-mêmes.
Où je manipule explicitement la notion de Rectangle.
Il n'était pas vraiment explicite ici que je manipule cette notion de Rectangle.
Où je fais,
j'établis le lien sémantique entre le Rectangle et le calcul de surface.
Alors qu'ici, ce lien était établi de façon très indirecte.
Donc premier avantage, meilleure visibilité, meilleure cohérence.
De plus ici, de par le fait que le programmeur utilisateur de la
classe Rectangle ne peut plus utiliser la notion de Rectangle qu'au travers de
l'interface d'utilisation prévue par le programmeur concepteur de la classe.
Eh bien, il devient possible à ce programmeur concepteur d'en modifier les
détails internes sans que cela n'impacte l'utilisation concrète.
Si comme évoqué précédemment, le concepteur de la classe Rectangle
décide de revisiter, de revoir son implémentation initiale,
qui consistait à représenter la hauteur et la largeur au moyen de deux doubles.
Donc, s'il décide de discuter ce choix, de le modifier, par exemple en utilisant un
tableau, alors s'il
adapte proprement le calcul de surface à sa nouvelle structure de données,
celui qui utilise le calcul de surface n'est nullement impacté.
Il découle donc de la séparation entre le niveau interne, détails d'implémentation,
et externe, interface d'utilisation, un cadre d'utilisation plus rigoureux.
Les modifications que l'on fait à l'intérieur de la structure interne
restent invisibles à l'extérieur.
Il en découle une règle généralement suivie par tout bon programmeur
orienté objet.
De par le fait que les attributs, pour leur modélisation,
nécessitent des choix techniques, des choix d'implémentation.
On doit décider par exemple de leur type.
On va les considérer habituellement comme des détails d'implémentation.
Et donc, on va faire en sorte qu'ils ne soient pas accessibles depuis l'extérieur
de la classe.
Pour résumer, lorsque l'on définit un nouveau type d'objet au travers d'une
classe, on va être amené à définir les attributs caractéristiques de la classe,
ainsi que les méthodes qui lui sont spécifiques.
Et on va devoir se préoccuper de définir concrètement ce qui est visible,
l'interface d'utilisation, et ce qui ne l'est pas, les détails d'implémentation.
Donc, une fois qu'on aura décidé de ce qui est à cacher.
Donc, l'utilisateur externe n'aura de vision de cet objet qu'une
vision abstraite qui est matérialisée par l'interface d'utilisation.
Je ne vois d'un Rectangle que son calcul de surface.
Et si je veux suivre les bonnes règles de programmation orientée objet,
je vais considérer que les attributs sont également des détails d'implémentation.
Et donc, l'interface va se limiter à un certain nombre de méthodes bien choisies.
L'utilisateur externe n'aura de vision de l'objet que cette interface d'utilisation.
A retenir de la séquence d'aujourd'hui.
Le résultat du processus d'abstraction est ce que l'on appelle une classe.
[AUDIO_VIDE] Qui me permet de désigner une catégorie d'objet.
Une classe va définir va définir dans un programme un nouveau type.
Je dispose désormais du type Rectangle que je peux manipuler dans un programme.
Je peux déclarer des variables de ce type-là.
Une réalisation concrète, donc la déclaration d'une variable de ce nouveau
type est ce qu'on appelle dans le jargon orienté objet un objet.
Et elle est généralement manipulée au travers d'une variable.
Pour résumer et pour illustrer le propos, celui qui écrit la classe
Rectangle va décider de l'existence conceptuelle de ce nouveau type.
Il va le faire évidemment en écrivant un programme qui contient le
code de cette classe Rectangle.
Celui qui l'utilise va utiliser ce nouveau type en déclarant des variables
du type Rectangle, qui vont avoir une existence concrète au moment où le
programme s'exécute, donc au moment où on crée de nouveaux objets de ce type-là,
on va pouvoir commencer à travailler avec ces objets concrètement dans un programme.
Donc, l'utilisateur va travailler concrètement avec des réalisations
des objets de la classe Rectangle.
Nous voici maintenant arrivés au terme de la présentation de ces concepts
fondamentaux de l'orienté objet que sont l'encapsulation et l'abstraction.
Vous allez, dès les séquences suivantes,
commencer à les pratiquer de façon très concrète en Java.
Explorer notre catalogue
Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.
Coursera propose un accès universel à la meilleure formation au monde,
en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.
© 2019 Coursera Inc. Tous droits réservés.
