| Penser en Java 2nde édition | - | Sommaire | Préface | Avant-propos | Chapitre : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Annexe : A B C D | Tables des matières | - | Thinking in Java |
Une autre particularité importante est la durée de vie d'un objet. Avec les langages qui autorisent la création d'objets dans la pile, le compilateur détermine combien de temps l'objet est amené à vivre et peut le détruire automatiquement. Mais si l'objet est créé dans le segment, le compilateur n'a aucune idée de sa durée de vie. Dans un langage comme le C++, il faut déterminer dans le programme quand détruire l'objet, ce qui peut mener à des fuites de mémoire si cela n'est pas fait correctement (et c'est un problème courant en C++). Java propose une fonctionnalité appelée ramasse-miettes (garbage collector) qui découvre automatiquement quand un objet n'est plus utilisé et le détruit. Java propose donc un niveau plus élevé d'assurance contre les fuites de mémoire. Disposer d'un ramasse-miettes est pratique car cela réduit le code à écrire et, plus important, le nombre de problèmes liés à la gestion de la mémoire (qui ont mené à l'abandon de plus d'un projet C++).
Le reste de cette section s'attarde sur des facteurs additionnels concernant l'environnement et la durée de vie des objets.
Si le nombre d'objets nécessaires à la résolution d'un problème est inconnu, ou combien de temps on va en avoir besoin, on ne peut pas non plus savoir comment les stocker. Comment déterminer l'espace nécessaire pour créer ces objets ? C'est impossible car cette information n'est connue que lors de l'exécution.
La solution à la plupart des problèmes en conception orientée objet est simple : il suffit de créer un nouveau type d'objet. Le nouveau type d'objets qui résout ce problème particulier contient des références aux autres objets. Bien sûr, un tableau ferait aussi bien l'affaire. Mais il y a plus. Ce nouvel objet, appelé conteneur (ou collection, mais la bibliothèque Java utilise ce terme dans un autre sens ; nous utiliserons donc le terme « conteneur » dans la suite de ce livre), grandira automatiquement pour accepter tout ce qu'on place dedans. Connaître le nombre d'objets qu'on désire stocker dans un conteneur n'est donc plus nécessaire. Il suffit de créer un objet conteneur et le laisser s'occuper des détails.
Heureusement, les langages orientés objet décents fournissent ces conteneurs. En C++, ils font partie de la bibliothèque standard (STL, Standard Template Library). Le Pascal Objet dispose des conteneurs dans sa Bibliothèque de Composants Visuels (VCL, Visual Component Library). Smalltalk propose un ensemble vraiment complet de conteneurs. Java aussi propose des conteneurs dans sa bibliothèque standard. Dans certaines bibliothèques, un conteneur générique est jugé suffisant pour tous les besoins, et dans d'autres (Java par exemple), la bibliothèque dispose de différents types de conteneurs suivant les besoins : des vecteurs (appelé ArrayList en Java) pour un accès pratique à tous les éléments, des listes chaînées pour faciliter l'insertion, par exemple, on peut donc choisir le type particulier qui convient le mieux. Les bibliothèques de conteneurs peuvent aussi inclure les ensembles, les files, les dictionnaires, les arbres, les piles, etc...
Tous les conteneurs disposent de moyens pour y stocker des choses et les récupérer ; ce sont habituellement des fonctions pour ajouter des éléments dans un conteneur et d'autres pour les y retrouver. Mais retrouver des éléments peut être problématique, car une fonction de sélection unique peut se révéler trop restrictive. Comment manipuler ou comparer un ensemble d'éléments dans le conteneur ?
La réponse à cette question prend la forme d'un itérateur, qui est un objet dont le travail est de choisir les éléments d'un conteneur et de les présenter à l'utilisateur de l'itérateur. En tant que classe, il fournit de plus un niveau d'abstraction supplémentaire. Cette abstraction peut être utilisée pour séparer les détails du conteneur du code qui utilise ce conteneur. Le conteneur, via l'itérateur, est perçu comme une séquence. L'itérateur permet de parcourir cette séquence sans se préoccuper de sa structure sous-jacente - qu'il s'agisse d'une ArrayList (vecteur), une LinkedList (liste chaînée), une Stack (pile) ou autre. Cela permet de changer facilement la structure de données sous-jacente sans perturber le code du programme. Java commença (dans les versions 1.0 et 1.1) avec un itérateur standard, appelé Enumeration, pour toutes ses classes conteneurs. Java 2 est accompagné d'une bibliothèque de conteneurs beaucoup plus complète qui contient entre autres un itérateur appelé Iterator bien plus puissant que l'ancienne Enumeration.
Du point de vue du design, tout ce dont on a besoin est une séquence qui peut être manipulée pour résoudre le problème. Si un seul type de séquence satisfaisait tous les besoins, il n'y aurait pas de raison d'en avoir de types différents. Il y a deux raisons qui font qu'on a besoin d'un choix de conteneurs. Tout d'abord, les conteneurs fournissent différents types d'interfaces et de comportements. Une pile a une interface et un comportement différents de ceux d'une file, qui sont différents de ceux fournis par un ensemble ou une liste. L'un de ces conteneurs peut se révéler plus flexible qu'un autre pour la résolution du problème considéré. Deuxièmement, les conteneurs ne sont pas d'une même efficacité pour les mêmes opérations. Prenons le cas d'une ArrayList et d'une LinkedList. Les deux sont de simples séquences qui peuvent avoir la même interface et comportement. Mais certaines opérations ont des coûts radicalement différents. Accéder à des éléments au hasard dans une ArrayList est une opération qui demande toujours le même temps, quel que soit l'élément auquel on souhaite accéder. Mais dans une LinkedList, il est coûteux de se déplacer dans la liste pour rechercher un élément, et cela prend plus de temps pour trouver un élément qui se situe plus loin dans la liste. Par contre, si on souhaite insérer un élément au milieu d'une séquence, c'est bien plus efficace dans une LinkedList que dans une ArrayList. Ces opérations et d'autres ont des efficacités différentes suivant la structure sous-jacente de la séquence. Dans la phase de conception, on peut débuter avec une LinkedList et lorsqu'on se penche sur l'optimisation, changer pour une ArrayList. Grâce à l'abstraction fournie par les itérateurs, on peut passer de l'une à l'autre avec un impact minime sur le code.
En définitive, un conteneur n'est qu'un espace de stockage où placer des objets. Si ce conteneur couvre tous nos besoins, son implémentation réelle n'a pas grande importance (un concept de base pour la plupart des objets). Mais il arrive que la différence de coûts entre une ArrayList et une LinkedList ne soit pas à négliger, suivant l'environnement du problème et d'autres facteurs. On peut n'avoir besoin que d'un seul type de séquence. On peut même imaginer le conteneur « parfait », qui changerait automatiquement son implémentation selon la manière dont on l'utilise.
L'une des controverses en POO devenue proéminente depuis le C++ demande si toutes les classes doivent être finalement dérivées d'une classe de base unique. En Java (et comme dans pratiquement tous les autres langages OO) la réponse est « oui » et le nom de cette classe de base ultime est tout simplement Object. Les bénéfices d'une hiérarchie de classes unique sont multiples.
Tous les objets dans une hiérarchie unique ont une interface commune, ils sont donc tous du même type fondamental. L'alternative (proposée par le C++) est qu'on ne sait pas que tout est du même type fondamental. Du point de vue de la compatibilité ascendante, cela épouse plus le modèle du C et peut se révéler moins restrictif, mais lorsqu'on veut programmer en tout objet il faut reconstruire sa propre hiérarchie de classes pour bénéficier des mêmes avantages fournis par défaut par les autres langages OO. Et dans chaque nouvelle bibliothèque de classes qu'on récupère, une interface différente et incompatible sera utilisée. Cela demande des efforts (et éventuellement l'utilisation de l'héritage multiple) pour intégrer la nouvelle interface dans la conception. Est-ce que la « flexibilité » que le C++ fournit en vaut réellement le coup ? Si on en a besoin - par exemple si on dispose d'un gros investissement en C - alors oui. Mais si on démarre de zéro, d'autres alternatives telles que Java se révèlent beaucoup plus productives.
Tous les objets dans une hiérarchie de classes unique (comme celle que propose Java) sont garantis d'avoir certaines fonctionnalités. Un certain nombre d'opérations élémentaires peuvent être effectuées sur tous les objets du système. Une hiérarchie de classes unique, accompagnée de la création des objets dans le segment, simplifie considérablement le passage d'arguments (l'un des sujets les plus complexes en C++).
Une hiérarchie de classes unique facilite aussi l'implémentation d'un ramasse-miettes (qui est fourni en standard en Java). Le support nécessaire est implanté dans la classe de base, et le ramasse-miettes peut donc envoyer le message idoine à tout objet du système. Sans une hiérarchie de classe unique et un système permettant de manipuler un objet via une référence, il est difficile d'implémenter un ramasse-miettes.
Comme tout objet dispose en lui d'informations dynamiques, on ne peut se retrouver avec un objet dont on ne peut déterminer le type. Ceci est particulièrement important avec les opérations du niveau système, telles que le traitement des exceptions, et cela permet une plus grande flexibilité dans la programmation.
Parce qu'un conteneur est un outil qu'on utilise fréquemment, il est logique d'avoir une bibliothèque de conteneurs conçus de manière à être réutilisables, afin de pouvoir en prendre un et l'insérer dans le programme. Java fournit une telle bibliothèque, qui devrait satisfaire tous les besoins.
Pour rendre ces conteneurs réutilisables, ils stockent le type universel en Java précédemment mentionné : Object. La hiérarchie de classe unique implique que tout est un Object, un conteneur stockant des Objects peut donc stocker n'importe quoi. Cela rend les conteneurs aisément réutilisables.
Pour utiliser ces conteneurs, il suffit d'y ajouter des références à des objets, et les redemander plus tard. Mais comme le conteneur ne stocke que des Objects, quand une référence à un objet est ajoutée dans le conteneur, il subit un transtypage ascendant en Object, perdant alors son identité. Quand il est recherché par la suite, on récupère une référence à un Object, et non une référence au type qu'on a inséré. Comment le récupérer et retrouver l'interface de l'objet qu'on a stocké dans le conteneur ?
On assiste ici aussi à un transtypage, mais cette fois-ci il ne remonte pas dans la hiérarchie de classe à un type plus général, mais descend dans la hiérarchie jusqu'à un type plus spécifique, c'est un transtypage descendant ou spécialisation, ou soustypage. Avec la généralisation, on sait par exemple qu'un Cercle est un type de Forme, et que le transtypage est donc sans danger ; mais on ne sait pas qu'un Object est aussi un Cercle ou une Forme, il est donc rarement sur d'appliquer une spécialisation à moins de savoir exactement à quoi on a affaire.
Ce n'est pas trop dangereux cependant, car si une spécialisation est tentée jusqu'à un type incompatible le système d'exécution générera une erreur appelée exception, qui sera décrite plus loin. Quand une référence d'objet est rapatriée d'un conteneur, il faut donc un moyen de se rappeler exactement son type afin de pouvoir le spécialiser correctement.
La spécialisation et les contrôles à l'exécution génèrent un surcoût de temps pour le programme, et des efforts supplémentaires de la part du programmeur. Il semblerait plus logique de créer le conteneur de façon à ce qu'il connaisse le type de l'objet stocké, éliminant du coup la spécialisation et la possibilité d'erreur. La solution est fournie par les types paramétrés, qui sont des classes que le compilateur peut personnaliser pour les faire fonctionner avec des types particuliers. Par exemple, avec un conteneur paramétré, le compilateur peut personnaliser ce conteneur de façon à ce qu'il n'accepte que des Formes et ne renvoie que des Formes.
Les types paramétrés sont importants en C++, en particulier parce que le C++ ne dispose pas d'une hiérarchie de classe unique. En C++, le mot clef qui implémente les types paramétrés est « template ». Java ne propose pas actuellement de types paramétrés car c'est possible de les simuler - bien que difficilement - via la hiérarchie de classes unique. Une solution de types paramétrés basée sur la syntaxe des templates C++ est actuellement en cours de proposition.
Chaque objet requiert des ressources, en particulier de la mémoire. Quand un objet n'est plus utilisé il doit être nettoyé afin de rendre ces ressources pour les réutiliser. Dans la programmation de situations simples, la question de savoir comment un objet est libéré n'est pas trop compliquée : il suffit de créer l'objet, l'utiliser aussi longtemps que désiré, et ensuite le détruire. Il n'est pas rare par contre de se trouver dans des situations beaucoup plus complexes.
Supposons qu'on veuille concevoir un système pour gérer le trafic aérien d'un aéroport (ou pour gérer des caisses dans un entrepôt, ou un système de location de cassettes, ou un chenil pour animaux). Cela semble simple de prime abord : créer un conteneur pour stocker les avions, puis créer un nouvel avion et le placer dans le conteneur pour chaque avion qui entre dans la zone de contrôle du trafic aérien. Pour le nettoyage, il suffit de détruire l'objet avion correspondant lorsqu'un avion quitte la zone.
Mais supposons qu'une autre partie du système s'occupe d'enregistrer des informations à propos des avions, ces données ne requérant pas autant d'attention que la fonction principale de contrôle. Il s'agit peut-être d'enregistrer les plans de vol de tous les petits avions quittant l'aéroport. On dispose donc d'un second conteneur des petits avions, et quand on crée un objet avion on doit aussi le stocker dans le deuxième conteneur si c'est un petit avion. Une tâche de fond s'occupe de traiter les objets de ce conteneur durant les moments d'inactivité du système.
Le problème est maintenant plus compliqué : comment savoir quand détruire les objets ? Quand on en a fini avec un objet, une autre partie du système peut ne pas en avoir terminé avec. Ce genre de problème arrive dans un grand nombre de situations, et dans les systèmes de programmation (comme le C++) où les objets doivent être explicitement détruits cela peut devenir relativement complexe.
Avec Java, le ramasse-miettes est conçu pour s'occuper du problème de la libération de la mémoire (bien que cela n'inclut pas les autres aspects du nettoyage de l'objet). Le ramasse-miettes « sait » quand un objet n'est plus utilisé, et il libère automatiquement la mémoire utilisée par cet objet. Ceci (associé avec le fait que tous les objets sont dérivés de la classe de base fondamentale Object et que les objets sont créés dans le segment) rend la programmation Java plus simple que la programmation C++. Il y a beaucoup moins de décisions à prendre et d'obstacles à surmonter.
Si cette idée est si bonne, pourquoi le C++ n'intègre-t-il pas ce mécanisme ? Bien sûr car il y a un prix à payer pour cette facilité de programmation, et ce surcoût se traduit par du temps système. Comme on l'a vu, en C++ on peut créer des objets dans la pile et dans ce cas ils sont automatiquement nettoyés (mais dans ce cas on n'a pas la flexibilité de créer autant d'objets que voulu lors de l'exécution). Créer des objets dans la pile est la façon la plus efficace d'allouer de l'espace pour des objets et de libérer cet espace. Créer des objets dans le segment est bien plus coûteux. Hériter de la même classe de base et rendre tous les appels de fonctions polymorphes prélèvent aussi un tribut. Mais le ramasse-miettes est un problème à part car on ne sait pas quand il va démarrer ou combien de temps il va prendre. Cela veut dire qu'il y a une inconsistance dans le temps d'exécution de programmes Java ; on ne peut donc l'utiliser dans certaines situations, comme celles où le temps d'exécution d'un programme est critique (appelés programmes en temps réel, bien que tous les problèmes de programmation en temps réel ne soient pas aussi astreignants).
Les concepteurs du langage C++, en voulant amadouer les programmeurs C, ne voulurent pas ajouter de nouvelles fonctionnalités au langage qui puissent impacter la vitesse ou défavoriser l'utilisation du C++ dans des situations où le C se serait révélé acceptable. Cet objectif a été atteint, mais au prix d'une plus grande complexité lorsqu'on programme en C++. Java est plus simple que le C++, mais la contrepartie en est l'efficacité et quelquefois son champ d'applications. Pour un grand nombre de problèmes de programmation cependant, Java constitue le meilleur choix.
Depuis les débuts des langages de programmation, le traitement des erreurs s'est révélé l'un des problèmes les plus ardus. Parce qu'il est difficile de concevoir un bon mécanisme de gestion des erreurs, beaucoup de langages ignorent ce problème et le déléguent aux concepteurs de bibliothèques qui fournissent des mécanismes qui fonctionnent dans beaucoup de situations mais peuvent être facilement contournés, généralement en les ignorant. L'une des faiblesses de la plupart des mécanismes d'erreur est qu'ils reposent sur la vigilance du programmeur à suivre des conventions non imposées par le langage. Si le programmeur n'est pas assez vigilant - ce qui est souvent le cas s'il est pressé - ces mécanismes peuvent facilement être oubliés.
Le système des exceptions pour gérer les erreurs se situe au niveau du langage de programmation et parfois même au niveau du système d'exploitation. Une exception est un objet qui est « émis » depuis l'endroit où l'erreur est apparue et peut être intercepté par un gestionnaire d'exception conçu pour gérer ce type particulier d'erreur. C'est comme si la gestion des exceptions était un chemin d'exécution parallèle à suivre quand les choses se gâtent. Et parce qu'elle utilise un chemin d'exécution séparé, elle n'interfère pas avec le code s'exécutant normalement. Cela rend le code plus simple à écrire car on n'a pas à vérifier constamment si des erreurs sont survenues. De plus, une exception émise n'est pas comme une valeur de retour d'une fonction signalant une erreur ou un drapeau positionné par une fonction pour indiquer une erreur - ils peuvent être ignorés. Une exception ne peut pas être ignorée, on a donc l'assurance qu'elle sera traitée quelque part. Enfin, les exceptions permettent de revenir d'une mauvaise situation assez facilement. Plutôt que terminer un programme, il est souvent possible de remettre les choses en place et de restaurer son exécution, ce qui produit des programmes plus robustes.
Le traitement des exceptions de Java se distingue parmi les langages de programmes, car en Java le traitement des exceptions a été intégré depuis le début et on est forcé de l'utiliser. Si le code produit ne gère pas correctement les exceptions, le compilateur générera des messages d'erreur. Cette consistance rend la gestion des erreurs bien plus aisée.
Il est bon de noter que le traitement des exceptions n'est pas une caractéristique orientée objet, bien que dans les langages OO une exception soit normalement représentée par un objet. Le traitement des exceptions existait avant les langages orientés objet.
L'un des concepts fondamentaux dans la programmation des ordinateurs est l'idée de traiter plus d'une tâche à la fois. Beaucoup de problèmes requièrent que le programme soit capable de stopper ce qu'il est en train de faire, traite un autre problème puis retourne à sa tâche principale. Le problème a été abordé de beaucoup de manières différentes. Au début, les programmeurs ayant des connaissances sur le fonctionnement de bas niveau de la machine écrivaient des routines d'interruption de service et l'interruption de la tâche principale était initiée par une interruption matérielle. Bien que cela fonctionne correctement, c'était difficile et non portable, et cela rendait le portage d'un programme sur un nouveau type de machine lent et cher.
Quelquefois les interruptions sont nécessaires pour gérer les tâches critiques, mais il existe une large classe de problèmes dans lesquels on tente juste de partitionner le problème en parties séparées et indépendantes afin que le programme soit plus réactif. Dans un programme, ces parties séparées sont appelés threads et le concept général est appelé multithreading. Un exemple classique de multithreading est l'interface utilisateur. En utilisant les threads, un utilisateur peur appuyer sur un bouton et obtenir une réponse plus rapide que s'il devait attendre que le programme termine sa tâche courante.
Généralement, les threads sont juste une façon d'allouer le temps d'un seul processeur. Mais si le système d'exploitation supporte les multi-processeurs, chaque thread peut être assigné à un processeur différent et ils peuvent réellement s'exécuter en parallèle. L'une des caractéristiques intéressantes du multithreading au niveau du langage est que le programmeur n'a pas besoin de se préoccuper du nombre de processeurs. Le programme est divisé logiquement en threads et si la machine dispose de plusieurs processeurs, le programme tourne plus vite, sans aucun ajustement.
Tout ceci pourrait faire croire que le multithreading est simple. Il y a toutefois un point d'achoppement : les ressources partagées. Un problème se pose si plus d'un thread s'exécutant veulent accéder à la même ressource. Par exemple, deux tâches ne peuvent envoyer simultanément de l'information à une imprimante. Pour résoudre ce problème, les ressources pouvant être partagées, comme l'imprimante, doivent être verrouillées avant d'être utilisées. Un thread verrouille donc une ressource, accomplit ce qu'il a à faire, et ensuite relâche le verrou posé afin que quelqu'un d'autre puisse utiliser cette ressource.
