La programmation orientée objet en Java

1 1 1 1 1 1 1 1 1 1 Rating 0.00 (0 Votes)
Submit to DeliciousSubmit to DiggSubmit to FacebookSubmit to Google PlusSubmit to StumbleuponSubmit to TechnoratiSubmit to TwitterSubmit to LinkedIn

La programmation orientée objet en Java

La P.O.O. (programmation orientée objet) possède de nombreuses vertus universellement reconnues désormais. Notamment, elle ne renie pas la programmation structurée (elle se fonde sur elle), elle contribue à la fiabilité des logiciels et elle facilite la réutilisation de code existant. Elle introduit de nouveaux concepts, en particulier ceux d'objets, d'encapsulation, de classe et d'héritage.

1. Les concepts d'objet et d'encapsulation

En programmation structurée, un programme est formé de la réunion de différentes procédures et de différentes structures de données généralement indépendantes de ces procédures.

En P.O.O., un programme met en œuvre différents objets. Chaque objet associe des données et des méthodes agissant exclusivement sur les données de l'objet. Notez que le vocabulaire évolue quelque peu : on parlera de méthodes plutôt que de procédures ; en revanche, on pourra utiliser indifféremment le mot données ou le mot champ.

Mais cette association est plus qu'une simple juxtaposition. En effet, dans ce que l'on pourrait qualifier de P.O.O. "pure", on réalise ce que l'on nomme une encapsulation des données. Cela signifie qu'il n'est pas possible d'agir directement sur les données d'un objet ; il est nécessaire de passer par ses méthodes, qui jouent ainsi le rôle d'interface obligatoire. On traduit parfois cela en disant que l'appel d'une méthode est en fait l'envoi d'un message à l'objet.

Le grand mérite de l'encapsulation est que, vu de l'extérieur, un objet se caractérise uniquement par les spécifications de ses méthodes, la manière dont sont réellement implantées les données étant sans importance. On décrit souvent une telle situation en disant qu'elle réalise une abstraction des données (ce qui exprime bien que les détails concrets d'implémentation sont cachés). À ce propos, on peut remarquer qu'en programmation structurée, une procédure pouvait également être caractérisée (de l'extérieur) par ses spécifications, mais que, faute d'encapsulation, l'abstraction des données n'était pas réalisée.

L'encapsulation des données présente un intérêt manifeste en matière de qualité de logiciel. Elle facilite considérablement la maintenance : une modification éventuelle de la structure des données d'un objet n'a d'incidence que sur l'objet lui-même ; les utilisateurs de l'objet ne seront pas concernés par la teneur de cette modification (ce qui n'était bien sûr pas le cas avec la programmation structurée). De la même manière, l'encapsulation des données facilite grandement la réutilisation d'un objet.

2. Le concept de classe

Le concept de classe correspond simplement à la généralisation de la notion de type que l'on rencontre dans les langages classiques. En effet, une classe n'est rien d'autre que la description d'un ensemble d'objets ayant une structure de données commune et disposant des mêmes méthodes. Les objets apparaissent alors comme des variables d'un tel type classe (en P.O.O., on dit aussi qu'un objet est une instance de sa classe). Bien entendu, seule la structure est commune, les valeurs des champs étant propres à chaque objet. En revanche, les méthodes sont effectivement communes à l'ensemble des objets d'une même classe.

Lorsque, comme cela arrive parfois dans l'écriture d'interfaces graphiques, on est amené à ne créer qu'un seul objet d'une classe donnée, la distinction entre les notions d'objet et de classe n'est pas toujours très évidente.

En revanche, lorsque l'on dispose de plusieurs objets d'une même classe, le principe d'encapsulation s'appliquera à la classe et non à chacune de ses instances, comme nous le verrons.

3. L'héritage

Un autre concept important en P.O.O. est celui d'héritage. Il permet de définir une nouvelle classe à partir d'une classe existante (qu'on réutilise en bloc !), à laquelle on ajoute de nouvelles données et de nouvelles méthodes. La conception de la nouvelle classe, qui hérite des propriétés et des aptitudes de l'ancienne, peut ainsi s'appuyer sur des réalisations antérieures parfaitement au point et les spécialiser à volonté. Comme on peut s'en douter, l'héritage facilite largement la réutilisation de produits existants, d'autant plus qu'il peut être réité.

Cette technique s'appliquera aussi bien aux classes que vous serez amenés à développer qu'aux très nombreuses classes fournies es en standard avec Java.

Certains langages, tels C++, offrent la possibilité d'un héritage multiple : une même classe peut hériter simultanément de plusieurs autres. Ce n'est pas le cas de Java, mais nous verrons que la notion d'interface permet de traiter plus élégamment les situations correspondantes.

4. Le polymorphisme

En Java, comme généralement, en P.O.O., une classe peut "redéfinir" (c'est-à-dire modifier) certaines des méthodes héritées de sa classe de base. Cette possibilité est la clé de ce que l'on nomme le "polymorphisme", c'est-à-dire la possibilité de traiter de la même manière des objets de types différents, pour peu qu'ils soient issus de classes dérivées d'une même classe de base. Plus précisément, on utilise chaque objet comme s'il était de cette classe de base, mais son comportement effectif dépend de sa classe effective (dérivée de cette classe de base), en particulier de la manière dont ses propres méthodes ont été redéfinies. Le polymorphisme permet d'ajouter de nouveaux objets dans un scénario préétabli et, éventuellement, écrit avant d'avoir connaissance du type exact de ces objets.

5. Java est presque un pur langage de P.O.O.

Certains langages ont été conçus pour appliquer à la lettre les principes de P.O.O. C'est notamment le cas de Simula, Smalltalk et de Eiffel. Dans ce cas, tout est objet (ou instance de classe) et l'encapsulation des données est absolue. Les procédures sont obligatoirement des méthodes, ce qui revient à dire qu'il n'existe pas de procédures indépendantes, c'est-à-dire susceptibles de s'exécuter indépendamment de tout objet.

D'autres langages, comme Pascal ou C++, ont cherché à appliquer une "philosophie objet" à un langage classique. Les objets y cohabitent alors avec des variables usuelles. Il existe à la fois des méthodes, applicables à un objet, et des procédures indépendantes. À à la limite, on peut réaliser un programme ne comportant aucun objet.
Java se veut un langage de la première catégorie, autrement dit un pur langage de P.O.O. Par nature, un programme s'y trouvera formé d'une classe ou de la réunion de plusieurs classes et il instanciera des objets. Il sera impossible de créer un programme n'utilisant aucune classe. Cependant, il faut apporter quelques nuances qui troublent très légèrement la pureté du langage.

  • Java dispose de types dits primitifs pour représenter les entiers, les flottants, les caractères et les booléens. Les variables correspondantes ne sont pas des objets. Certes, la plupart du temps, ces types primitifs seront utilisés pour définir les champs d'une classe, donc finalement d'un objet ; cependant, il y aura des exceptions...
  • Une classe pourra comporter des méthodes particulières dites méthodes de classe (déclarées avec le mot-clé static) qui seront utilisables de façon indépendante d'un objet. Comme ces méthodes peuvent déclarer localement des variables d'un type primitif, on voit qu'on peut ainsi retrouver les possibilités des procédures ou des fonctions des langages non objet. La seule différence (purement syntaxique) viendra de ce que ces méthodes seront localisées artificiellement dans une classe (on verra qu’il existe une telle méthode nommée main jouant le rôle de programme principal). À la limite, on peut concevoir un programme ne comportant aucun objet (mais obligatoirement au moins une classe). 
  • L’encapsulation se trouve naturellement induite par la syntaxe du langage mais elle n’est pas absolue.

 

Submit to DeliciousSubmit to DiggSubmit to FacebookSubmit to Google PlusSubmit to StumbleuponSubmit to TechnoratiSubmit to TwitterSubmit to LinkedIn