Programmation orientée objet et introduction à l'environnement Java

On attend du lecteur une certaine expérience de la programmation (de préférence en langage C ou ayant une syntaxe similaire, étant donné que les structures de contrôle autres fonctionnalités de base de tout langage procédural ne seront pas réexpliquées dans la partie Java).

Le principe de Parnas explique qu'il ne faut pas fournir trop d'informations à l'utilisateur d'une classe : la définition d'une classe fournit à l'extérieur toutes les informations nécessaires à la manipulation de ses instances et rien d'autre. De même, l'implémentation de ses méthodes se base sur toutes les informations nécessaires à la tâche et rien d'autre.

Notamment, on ne peut pas documenter l'implémentation d'une classe ou se baser sur des hypothèses qui ne seront pas vraies dans chaque cas d'utilisation possible.

Plusieurs visibilités sont possibles : public ou privé, notamment (on distinguera également protégé avec l'héritage et package ou défaut en Java). En UML, on les distingue par + et - (# pour la visibilité protégée, ~ pour la visibilité par défaut en Java).

Un élément public est accessible par tout objet.

Un élément privé d'un objet n'est accessible que par les instances de la classe à laquelle il appartient (notamment, toutes les variables, sauf rare exception : un objet extérieur ne peut pas modifier l'état de l'objet courant, sous peine de le mettre dans un état incohérent et de dépendre de ses structures internes, ce qui conduirait à des programmes peu fiables et peu modulaires).

Un élément protégé n'est visible qu'à la classe courante et aux classes filles

On distingue les variables de classe (dont une seule instance est partagée entre tous les objets d'une même classe) et les variables d'instance (qui existent pour chaque objet).

En UML, on souligne les éléments de classe.

Par exemple, pour émettre une série de tickets de caisse, il vaut mieux utiliser une variable de classe : on veut que chaque nouveau ticket ait le numéro immédiatement suivant le précédent et que chaque numéro soit unique. On stockera donc comme variable de classe le numéro courant ; à l'initialisation d'un nouveau ticket, on incrémentera ce nombre, de telle sorte que le numéro pris soit à coup sûr unique.

Par contre, pour un compteur, on préférera une variable d'instance : on veut disposer d'une série de compteurs indépendants. Incrémenter la valeur d'un ne peut pas changer la valeur d'un autre.

La même distinction existe pour les méthodes : un méthode de classe ne peut qu'utiliser des variables de classe, tandis que les méthodes d'instance peuvent également accéder aux variables de l'objet.

Les méthodes d'instances sont identiques entre les objets, elles n'en définissent pas l'état : leur code est partagé par toutes les instances d'une classe.

De manière générale, on développe un programme orienté objet en suivant les tâches suivantes, répétées itérativement :

1. Isoler un ensemble de scénarios qui décrivent le comportement souhaité dans une série de situations représentatives de son utilisation ;
2. Identifier des composants du système ;
3. Attribuer à chaque composant ses responsabilités et en organiser la délégation.

Chaque composant aura un ensemble simple et bien défini de responsabilités ; on tentera de limiter l'interaction entre les composants pour favoriser la modularité.

On peut décrire sur une carte CRC (composant, responsabilités, collaborateurs) l'utilité du composant, ses responsabilités, les interactions qu'il devra avoir. Chaque carte devra rester simple, on ne peut pas y donner les détails du système (la place disponible sur la carte n'est pas extensible : si on arrive à court de place, il vaut probablement mieux scinder le composant) ; ces cartes sont plastifiées : on peut effacer et réécrire à l'envi, en fonction de l'évolution de l'étude des scénarios.

Par exemple, on peut vouloir représenter un triangle à partir de trois points ; la seule fonctionnalité qui sera requise dans cette application en sera le calcul d'aire. On aura un seul collaborateur : le point, qui sera responsable de son côté du stockage de ses coordonnées. Le triangle en utilisera trois (fournis lors de sa construction) pour calculer la hauteur.

On peut également utiliser une carte pour le point.

On définit ainsi une hiérarchie des classes, qui lie entre elles les classes composant un programme orienté objet. Les descendants d'une classe (sous-classes) sont des spécialisations, les classes parentes seront les généralisations.

L'héritage est un mécanisme associé à cette hiérarchie : une sous-classe hérite par défaut des mêmes variables et méthodes que ses parents, tout en gardant la possibilité de définir de nouvelles variables ou méthodes ou de remplacer les éléments hérités par des éléments propres. L'héritage est transitif : si une classe est une généralisation d'une autre, alors cette autre est une spécialisation de la première.

Par conséquent, on dispose du polymorphisme des objets : l'interface d'une sous-classe inclut nécessairement celles de ses parents, on peut utiliser un objet d'une classe enfante comme s'il était instancié de la classe parente.

Il est aussi intéressant de définir des classes abstraites, quine sont pas destinées à être instanciées mais à fournir des éléments à hériter. Une telle classe ne doit pas forcément fournir un corps pour chaque méthode définie, les méthodes sans corps sont alors appelées « méthodes abstraites ». En cas d'héritage, ces méthodes abstraites devront être implémentées. Une classe abstraite permet de factoriser du code et de mettre une interface en évidence : au lieu de réécrire le code, on hérite de cette classe abstraite ; toute classe en héritant disposera d'au moins une certaine interface.

Une sous-classe doit être utilisable dans toutes les situations où ses classes parentes peuvent l'être, sans qu'il soit possible de percevoir une différence.

Dans ce cas, la sous-classe est bien une version spécialisée de la classe parente, un sous-type du type de données défini par les classes parentes. Il s'agit du but premier de l'héritage, bien que d'autres utilisations soient possibles.

Sans héritage, deux visibilités ont été étudiées : public et privé. On peut exposer des méthodes supplémentaires aux classes enfants grâce à la visibilité protégée : tout ce qui est marqué protégé n'est visible que par les sous-classes. En UML, elle est notée par un carré (#).

Une classe possède ainsi deux interfaces : une interface publique, envers ceux qui instancieront la classe ; une interface protégée, envers ceux qui spécialiseront la classe.

Toutes ces utilisations ne sont pas à conseiller, certaines sont cependant le seul recours quand on ne peut pas modifier la hiérarchie des classes.

• Spécialisation : une instance de la sous-classe représente un cas particulier d'instance de ses classes parentes. Cette utilisation garantit l'application du principe de substitution, tout en partageant du code.
• Spécification : une classe définit un comportement qu'elle n'implémente pas. On impose par là une interface commune, pas forcément du code commun, ce qui impose le respect du principe de substitution.
• Construction : une sous-classe fait usage des opérations implémentées par ses classes parentes sans en constituer un sous-type. Cette approche est suivie pour modifier l'interface d'une classe tout en gardant l'interface précédente. Le principe de substitution n'est pas satisfait, il vaut mieux utiliser la composition que l'héritage.
• Généralisation : une sous-classe modifie ou remplace entièrement certaines des opérations héritées afin de les rendre plus générales. On prend la hiérarchie à rebrousse-poil, ce qui viole explicitement le principe de substitution ; cet usage est réservé aux cas où il est impossible de faire autrement.
• Extension : une sous-classe ajoute de nouvelles opérations à celles héritées, sans modifier les opérations héritées. On ne viole pas le principe de substitution, on se situe à proximité de la spécialisation.
• Limitation : une sous-classe restreint les modalités d'utilisation de certaines opérations héritées de ses classes parentes. Les sous-classes ne sont pas des sous-types, il vaut mieux utiliser la composition.
• Variation : une sous-classe et sa parente directe constituent chacune une variante l'une de l'autre, le sens de la relation hiérarchique étant choisi arbitrairement. Il vaut mieux préférer une interface commune, car on viole le principe de substitution.
• Combinaison : une sous-classe hérite des éléments de plus d'une classe parente directe. La relation de hiérarchie des classes n'est plus alors forcément un arbre, il s'agira d'un graphe dirigé (acyclique de préférence). Des ambiguïtés sont possibles si plusieurs classes parentes définissent des éléments de même nom ; un élément peut être hérité de manière transitive d'une classe en suivant plusieurs chemins distincts dans le graphe de hiérarchie. Quel code faut-il exécuter ? Quels constructeurs appeler, dans quel ordre ? Comment résoudre un conflit de noms - une méthode possédant le même nom, les mêmes arguments mais des types de retour différents ?

Une définition de classe est composée de deux parties : une déclaration (nom de la classe et caractéristiques) et un corps. La déclaration ressemble à ceci :

[visibility] class ClassName

Par convention, le nom de la classe s'écrit en CamelCase : on prend les mots formants le nom de la classe et on met une majuscule à la première lettre de chacun.

Le qualificateur de visibilité public (visibilité publique) spécifie que la classe peut être utilisée par toute autre partie du programme (par défaut, uniquement dans le module courant). Pour les classes internes, on peut également utiliser les marqueurs protected et private (respectivement, ces mots-clés correspondent aux visibilités protégée et privée).

Le corps de la classe contient notamment les déclarations des variables de classe et d'instance et les définitions des méthodes.

Une définition de variable dans le corps d'une classe ressemble à ceci :

[visibility] [attributes] type variableName [= value];

Le marqueur de visibilité peut être public (variable accessible depuis d'autres classes), private (variable accessible uniquement depuis la même classe et les objets instancié depuis cette classe) ou protected (variable accessible uniquement depuis la classe courante et celles qui en héritent ; aussi accessible des autres classes du package courant). S'il n'y en a pas, la variable est accessible par le module courant (visibilité par défaut).

Les attributs peuvent être une combinaison de static (variable de classe), final (après attribution, la valeur ne peut plus être modifiée, une propriété qui doit être vérifiable à la compilation, sans ambiguïté), transient (valeur négligeable lors de la sérialisation, elle ne fait pas partie de l'état de l'objet) et volatile (la variable peut être modifiée par des éléments extérieurs à la méthode lors de son exécution).

Le type peut être un type primitif ou une référence. Les types primitifs sont bien définis :

• entiers signés :
  • sur huit bits : byte,
  • sur seize bits : short,
  • sur trente-deux bits : int,
  • sur soixante-quatre bits : long ;
• nombres réels (IEEE 754) :
  • sur trente-deux bits (simple précision) : float,
  • sur soixante-quatre bits (double précision) : double ;
• caractère Unicode (seize bits) : char ;
• booléen (un bit) : boolean.

Toute valeur qui n'est pas primitive est une référence vers un objet. Le langage définit la valeur spéciale null pour les références vides. this est une référence sur l'objet courant. Un tableau, notamment, est une référence vers un vecteur de données (que ce soit un type primitif, une référence ou un tableau) :

int[][] v;

À chaque type primitif correspond une classe : Integer pour int, Double pour double, Float pour float et ainsi de suite (1). À l'aide de l'autoboxing(2), on peut passer sans problème d'un type primitif à une référence équivalente : new Integer(9) et 9 sont deux expressions équivalentes (le compilateur s'occupe de la conversion et ajoute le code requis pour passer d'une forme à l'autre selon le besoin ; cependant, ce mécanisme a un revers si on n'y prête pas attention : la conversion n'est pas gratuite et le passage répété du type primitif à la référence peut avoir un impact négatif sur les performances du programme). Ce mécanisme est surtout utile pour les génériques (3).

On dispose également de classes gérant des nombres de précision arbitraire, tant entiers que décimaux : BigInteger et BigDecimal. Voir leur documentation pour plus d'informations à leur sujet.

Les types primitifs semblent voués à disparaître avec les prochaines versions de Java, en en faisant un langage complètement orienté objet

La forme canonique de déclaration de méthode est la suivante :

[visibility] [attributes] returnType methodName(type arg) {
    // Travail utile (corps de la méthode)
}

Le marqueur de visibilité est identique à celui d'une variable.

Les attributs sont déclarés à l'aide d'une combinaison de static (méthode de classe) et native (méthode implémentée en dehors de la machine virtuelle).

Le type de retour peut être un type primitif ou une référence. S'il n'y a pas de retour, le type fictif void est utilisé.

S'il n'y a pas d'argument, la liste est vide (()).

Les méthodes native n'ont pas de corps (il est remplacé par un ;).

On dispose également du polymorphisme : on peut déclarer, dans une même classe, plusieurs méthodes avec le même nom, pour autant qu'elles diffèrent par leur liste d'arguments (type et/ou nombre des arguments). Le type de retour n'intervient jamais dans la différentiation des méthode. Lors de la réception d'un message, on pourra déterminer la méthode à appeler en fonction de la liste de paramètres.

Les paramètres d'une méthode sont toujours passés par valeur, pas par variable (le type ou la référence) : quand on passe en paramètre une instance d'une classe, on passe la valeur de la référence.

Un programme orienté objet est un ensemble de définitions de classes ; pour structurer l'application, il est préférable de les encapsuler dans un groupe de classes (package). On tentera au maximum de limiter un groupe à une identité fonctionnelle propre et de les découpler autant que possible.

Ces groupes sont eux-mêmes organisés dans une architecture arborescente où les noms doivent être uniques. À cette fin, les noms de groupes seront constitués d'une suite d'indicateurs séparés par des points.

Pour définir l'appartenance à un groupe, on utilise le mot-clé package en début de fichier source (cette instruction doit être la première de la classe) ; de plus, la structure des fichiers doit correspondre au groupe (le contenu du groupe netscape.javascript doit se trouver dans le dossier netscape/javascript).

package netscape.javascript; 

public class Interpreter { 
    // ...
}

Pour accéder au contenu d'un groupe, on doit spécifier le nom complet de la classe, groupe y compris (netscape.javascript.Interpreter), ou bien importer les classes à l'aide du mot-clé import (il s'agit d'un sucre syntaxique pour éviter de taper le nom du groupe à chaque fois qu'on utilise la classe). Le groupe java.lang est toujours automatiquement importé.

package netscape.browser; 

import netscape.javascript.Interpreter; 
import netscape.javascript.*; 

public class Window { 
    // ...
}

Les groupes introduisent un nouveau niveau de visibilité, qui n'utilise pas de mot-clé : la visibilité de groupe, toutes les classes du même groupe ont accès à la classe ou aux méthodes sans niveau d'accès précisé. De même, les éléments protected seront également accessibles depuis le groupe courant.

Dans un programme réel, utiliser des groupes de classes n'est pas facultatif, il vaut mieux prendre l'habitude de les utiliser dès les premiers essais en Java.

Un message est une requête transmise à un objet ou à une classe de manière synchrone afin d'effectuer une certaine opération en fonction de certains paramètres éventuels. Il peut renvoyer une valeur.

Pour créer un objet, on évalue une expression de l'opérateur new :

new Class()

Cette évaluation provoquera l'instanciation de l'objet et renvoie une référence vers l'objet nouvellement créé.

En particulier, on peut instancier des tableaux :

new type[expression]...[expression][]...[]

À l'instanciation, les variables d'instances sont initialisées à l'aide des expressions définies dans leur déclaration. Si on veut exécuter des instructions plus complexes, on utilise le mécanisme du constructeur :

[visibility] Class(argument, argument...) { ... }

On peut définir plusieurs constructeurs (polymorphisme) ; par défaut, toute classe dispose d'un constructeur par défaut vide (si on définit un seul autre constructeur, il ne sera pas créé par le compilateur) ; on peut également chaîner les constructeurs, à condition qu'on n'appelle qu'un seul autre constructeur et qu'il s'agisse de la première instruction.

[visibility] Class(argument, argument...) { 
    this(expression, expression...); 
    // ...
}

Ce mécanisme de constructeur permet de s'assurer que du code a été exécuté si l'objet a été instancié.

De même, on peut définir des blocs statiques d'initialisation, qui initialiseront les classes à leur chargement :

[visibility] class Class {
    // ...

    static {
        // ...
    }

    // ...
}

On peut en définir plusieurs par classe, ils seront exécutés l'un après l'autre dans leur ordre de définition.

La destruction des objets est gérée exclusivement par le garbage collector, qui libère automatiquement la mémoire des objets qui ne sont plus accessibles (il travaille de manière asynchrone tant que l'exécution du programme peut se poursuivre : on ne peut jamais être sûr du moment de la destruction d'un objet).

Pour exécuter une application autonome, on doit définir une classe publique contenant une méthode main statique et publique :

[visibility] class Class {
    // ...

    public static void main(String[] args) {
        // ...
    }

    // ...
}

Ce mécanisme peut mener à des situations ambiguës, résolues différemment pour les méthodes et les variables d'instance.

Pour les méthodes, le code à appeler sera déterminé de manière dynamique : par le type de l'objet instancié.

Pour les variables d'instance, la variable référencée sera déterminée de manière statique : par le type de la référence sur l'objet instancié.

En effet, une lecture ou écriture de variable ne prend pas beaucoup de temps, alors que la recherche de la variable correspondante dans l'objet requiert la recherche dans une structure de données : il serait très lourd d'écrire dans une variable, puisque le temps de la recherche ne sera pas compensé par le temps de l'opération. A contrario, pour une méthode, on suppose qu'il y aura une certaine quantité de code à exécuter, qui prendra nettement plus de temps que la résolution du bout de code à exécuter.

Définir une nouvelle variable d'instance ou de classe dans une sous-classe avec le même nom qu'une variable de la classe parente reviendra à masquer la première variable ; on peut toutefois y accéder par le mot-clé super (ou par un cast de this avec ((ParentClass) this).member).

Cependant, il vaut mieux éviter d'avoir des variables d'instance ou de classe qui ont le même nom que celles de la classe parente, pour des raisons de lisibilité.

Pour les méthodes, tout s'effectue de manière dynamique : caster this n'aura aucun effet, il faut utiliser super.

Dans les sous-classes, il est nécessaire que les constructeurs appellent les constructeurs des parents, par chaînage des constructeurs, pour s'occuper de la partie parente. Par défaut, le constructeur appelle le constructeur par défaut de la classe parente, sans argument, comportement que l'on peut surcharger à l'aide du mot-clé super (chaînage des constructeurs).

En Java, il est possible d'hériter de plusieurs interfaces, une forme très allégée de l'héritage multiple où on n'hérite que des éléments d'interface, pas de code. Cependant, cette forme d'héritage multiple souffre de défauts communs avec l'héritage multiple classique : il n'est pas possible d'implémenter plusieurs interfaces qui ont un conflit de noms (plusieurs méthodes ont la même signature mais des types de retour différents, sans compter les exceptions).

Une interface Java est une classe définissant une collection de déclarations de méthodes publiques sans implémentation et de constantes publiques.

interface Interface {
    type method(type arg); 
    // ...

    type name = value; 
    // ...
}

On peut établir une relation hiérarchique entre classes et interfaces : une classe peut implémenter une ou plusieurs interfaces à l'aide du mot-clé implements.

class ClassI implements I1, I2 {
    // ...
}

Un graphe d'héritage peut également être établi entre les interfaces à l'aide du mot-clé extends.

interface Interface extends I1, I2 {
    // ...
}

On peut définir des interfaces vides, dont l'implémentation représente l'engagement à se conformer à certaines règles de comportement et de structure.

Java distingue deux types d'exceptions : les exceptions d'exécution, pouvant arriver n'importe où sans qu'il soit utile ou faisable de les gérer particulièrement (erreur arithmétique, dépassement d'un tableau, insuffisance mémoire, etc.) ; les exceptions contrôlées, rencontrées dans des opérations particulières dont on peut récupérer plus facilement (lecture de fichier interrompue, mauvais format de données, etc.). Une autre catégorie d'exceptions existe : les erreurs, dont il est strictement impossible de récupérer (erreur au niveau de la machine virtuelle ou du système).

Toutes les exceptions doivent hériter de la classe Throwable, comme Error et Exception. Parmi les classes enfantes de Exception, on trouve RuntimeException, dont les classes enfantes sont les exceptions d'exécution, pas forcément contrôlées ; toutes les autres classes héritant de Throwable sont des exceptions contrôlées. Vu la gravité des exceptions de type Error, elles ne doivent pas être contrôlées.

Pour traiter les exceptions, on place le code dans un bloc try : ce code sera exécuté jusqu'à ce qu'une exception survienne ; les exceptions seront récupérées dans les blocs catch suivants ; le code du bloc finally est toujours exécuté, qu'il y ait eu ou non exception, avant un return s'il y en a avant. Seul le bloc try est obligatoire dans cette construction, les deux autres peuvent être omis.

try {
    // Code pouvant lancer une exception (partie utile).
}

try {
    // Code pouvant lancer une exception (partie utile).
}

catch(Exception1 e) {
    // Code de gestion des exceptions de type Exception1.
}
catch(Exception2 e) {
    // Code de gestion des exceptions de type Exception2.
}
// ...

try {
    // Code pouvant lancer une exception (partie utile).
}

catch(Exception1 e) {
    // Code de gestion des exceptions de type Exception1.
}
catch(Exception2 e) {
    // Code de gestion des exceptions de type Exception2.
}
// ...

finally {
    // Code toujours à exécuter, qu'une exception ait été lancée ou pas. 
}

Il n'est pas toujours possible de traiter toutes les exceptions de la sorte : elles sont alors transmises à la méthode appelante, jusqu'à ce qu'une clause catch appropriée soit rencontrée. Si l'exception remonte jusqu'à la machine virtuelle, une erreur est transmise à l'utilisateur. Toute méthode doit spécifier (à l'aide du mot-clé throwsAuteur inconnu2012-07-16T16:29:22.91throw ou thows ou thrown ?Unknown Author2012-07-17T14:27:15.92Reply to Auteur inconnu (16/07/2012, 16:29): "..."On déclare avec throws, on lance avec throw, thrown n'est pas un mot-clé.) les exceptions contrôlées qui peuvent survenir sans être récupérées (y compris les constructeurs) :

type method(type arg) throws Exception1, Exception2 {
    // ...
}

Pour lancer une exception, on utilise le mot-clé throw.

type method(type arg) throws Exception {
    throw new Exception("Message."); 
}

Ainsi, pour définir une nouvelle exception, on doit hériter de la classe Throwable (on hérite de préférence de Exception) et fournir deux constructeurs, un sans argument et un avec une chaîne de caractères :

class NewException extends Exception {
    public NewException() {
        super(); 
    }

    public NewException(String s) {
        super(s); 
    }
}

On peut également définir un constructeur pour le chaînage des exceptions, il prend en paramètre une exception. Il sert, par exemple, lorsqu'on a reçu une exception d'un composant sous-jacent de bas niveau et qu'on souhaite renvoyer une exception de plus haut niveau sans perdre les informations apportées par la première exception.

Une bonne pratique est de définir les mêmes constructeurs que la classe Throwable, soit un constructeur par défaut (sans argument), avec un message, avec une cause (le chaînage), ainsi qu'avec cause et message.