Thinking in Java, 3rd ed. Revision 4.0

Tous les langages de programmation fournissent des abstractions. On peut dire que la complexité des problèmes qu'on est capable de résoudre est directement proportionnelle au type et à la qualité de nos capacités d'abstraction. Par « type », il faut comprendre « Qu'est-ce qu'on tente d'abstraire ? » Le langage assembleur est une petite abstraction de la machine sous-jacente. Beaucoup de langages « impératifs » (tels que Fortran, BASIC et C) sont des abstractions du langage assembleur. Ces langages sont de nettes améliorations par rapport à l'assembleur, mais leur abstraction première requiert une réflexion en termes de structure ordinateur plutôt que de structure du problème qu'on essaye de résoudre. Le programmeur doit établir l'association entre le modèle de la machine (dans « l'espace solution », qui est l'endroit où le problème est modélisé, tel que l'ordinateur) et le modèle du problème à résoudre (dans « l'espace problème », qui est l'endroit où se trouve le problème). Les efforts requis pour réaliser cette association, et le fait qu'elle est étrangère au langage de programmation, produit des programmes difficiles à écrire et à maintenir, et comme effet de bord a mené à la création de l'industrie du « Génie Logiciel ».

L'autre alternative à la modélisation de la machine est de modéliser le problème qu'on tente de résoudre. Les premiers langages tels que LISP ou APL choisirent une vue particulière du monde (« Tous les problèmes se ramènent à des listes » ou « Tous les problèmes sont algorithmiques », respectivement). PROLOG convertit tous les problèmes en chaînes de décisions. Des langages ont été créés en vue de programmer par contrainte, ou pour programmer en ne manipulant que des symboles graphiques (ces derniers se sont révélés être trop restrictifs). Chacune de ces approches est une bonne solution pour la classe particulière de problèmes pour laquelle ils ont été conçus, mais devient une horreur dès lors que vous les sortez de leur domaine d'application.

L'approche orientée objet va un cran plus loin en fournissant des outils au programmeur pour représenter des éléments dans l'espace problème. Cette représentation se veut assez générale pour ne pas restreindre le programmeur à un type particulier de problèmes. Nous nous référons aux éléments dans l'espace problème et leur représentation dans l'espace solution en tant qu'« objets ». L'idée est que le programme est autorisé à s'adapter à l'esprit du problème en ajoutant de nouveaux types d'objets, de façon à ce que, quand on lit le code décrivant la solution, on lit aussi quelque chose qui décrit le problème. C'est une abstraction plus flexible et puissante que tout ce qu'on a pu voir jusqu'à présent. (2) Ainsi la POO vous permet de décrire le problème dans les termes du problème, plutôt que dans les termes de l'ordinateur sur lequel la solution tournera. Il y a toujours un lien avec l'ordinateur : chaque objet ressemble un peu à un petit ordinateur. Il a un état, et des opérations que vous pouvez lui demander d'exécuter. Cependant, ce ne semble pas être une si mauvaise analogie aux objets du monde réel - ils en ont les caractéristiques et les comportements.

Alan Kay résume les cinq caractéristiques principales de Smalltalk, le premier véritable langage de programmation orienté objet et l'un des langages sur lequel est basé Java. Ces caractéristiques représentent une approche purement orientée objet :

• Tout est objet. Pensez à un objet comme à une variable spéciale ; il stocke les données, mais vous pouvez « faire des requêtes » sur cet objet, lui demander de réaliser des opérations sur lui-même. En théorie, on peut prendre n'importe quel composant conceptuel du problème qu'on essaye de résoudre (un chien, un immeuble, un service administratif… ) et le représenter en tant qu'objet dans le programme.
• Un programme est une série d'objets se disant mutuellement ce qu'ils ont à faire en s'envoyant des messages. Pour faire une requête à un objet, vous « envoyez un message » à cet objet. Plus concrètement, vous pouvez penser à un message comme à un appel à une méthode qui appartient à un objet particulier.
• Chaque objet a son propre espace de mémoire composé d'autres objets. Dit d'une autre manière, on crée un nouveau type d'objet en créant un paquetage contenant des objets déjà existants. Ainsi, la complexité d'un programme est cachée par la simplicité des objets mis en œuvre.
• Chaque objet a un type. En jargon, chaque objet est une instance de sa classe, et ici « classe » est synonyme de « type ». La plus importante caractéristique distinctive d'une classe est : « Quels messages peut-on lui envoyer ? »
• Tous les objets d'un type particulier peuvent recevoir les mêmes messages. C'est vraiment une caractéristique lourde de sens, comme vous le verrez plus tard. Parce qu'un objet de type « Cercle » est aussi un objet de type « forme », un cercle garantit d'accepter les messages des formes. Ce qui veut dire que vous pouvez écrire du code qui parle avec les formes et sera automatiquement accepté par tout ce qui correspond à la description d'une forme. Cette capacité de substitution est l'un des concepts les plus puissants de la POO.

Booch donne une description encore plus succincte d'un objet :

Un objet a un état, un comportement et une identité.

Ce qui veut dire qu'un objet peut avoir des données internes (qui lui donne son état), des méthodes (qui lui donne son comportement), et chaque objet peut être distingué de n'importe quel autre objet - ce qui concrètement veut dire qu'un objet a une adresse unique en mémoire. (3)

Aristote fut probablement le premier à étudier soigneusement le concept de type ; il parla « de la classe des poissons et de la classe des oiseaux ». L'idée que chaque objet, bien qu'étant unique, fait aussi partie d'une classe d'objets qui ont des caractéristiques et des comportements en commun fut utilisée directement dans le premier langage orienté objet, Simula-67, grâce à son mot clé fondamental, class, qui introduit un nouveau type dans un programme.

Simula, comme son nom l'indique, fut créé pour construire des simulations, telles que le problème classique du « guichetier de banque ». Dans cette simulation, on a un groupe de guichetiers, de clients, de comptes, de transactions et d'unités monétaires - soit un grand nombre d'« objets ». Les objets qui sont identiques, hormis leur état durant l'exécution d'un programme, sont regroupés dans des « classes d'objets » ; c'est de là que vient le mot clé class. La création de types abstraits de données (les classes) est un concept fondamental de la programmation orientée objet. Les types abstraits de données fonctionnent presque exactement comme les types intégrés : on peut créer des variables de ce type (appelées objets ou instances dans le jargon orienté objet) et manipuler ces variables (c'est ce qu'on appelle l'envoi de messages ou les requêtes; on envoie un message et l'objet comprend ce qu'il faut faire avec lui). Les membres (éléments) d'une classe donnée ont quelques points en commun : chaque compte a un solde, chaque guichetier peut recevoir un dépôt, etc. Cependant, chaque membre a un état qui lui est propre : chaque compte a un solde différent, chaque guichetier a un nom. De cette manière, guichetiers, clients, comptes, transactions, etc. peuvent être chacun représentés par une entité unique dans le programme informatique. Cette entité est l'objet, et chaque objet appartient à une classe particulière qui définit ses caractéristiques et son fonctionnement.

Ainsi, bien que ce soient de nouveaux types de données que l'on crée réellement dans la programmation orientée objet, tous les langages de programmation orientée objet utilisent en pratique le mot clé « class ». Quand on voit le mot « type », il faut penser « classe » et vice-versa. (4)

Puisqu'une classe décrit un ensemble d'objets qui ont des caractéristiques identiques (éléments d'information) et un fonctionnement identique (fonctionnalités), une classe est vraiment un type de données, parce que, par exemple, un nombre en virgule flottante possède également un ensemble de caractéristiques et de fonctionnalités. La différence est qu'un programmeur définit une classe qui s'adapte à un problème plutôt que d'être contraint d'utiliser un type de données existant qui a été conçu pour représenter une unité de mémoire dans une machine. On étend le langage de programmation en lui ajoutant de nouveaux types de données spécifiques aux besoins que l'on a. Le système de programmation accepte les nouvelles classes, se charge d'elles et vérifie leur type de la même manière qu'il le fait pour les types intégrés.

L'approche orientée objet n'est pas limitée à la construction de simulations. Que vous admettiez ou non que tout programme est une simulation du système en cours de conception, l'utilisation des techniques de POO peut faciliter la réduction d'un grand ensemble de problèmes à une solution simple.

À partir du moment où la classe est créée, on peut fabriquer autant d'objets de cette classe que l'on veut, puis les manipuler comme s'ils étaient les éléments existants dans le problème que l'on essaie de résoudre. En effet, un des défis de la programmation orientée objet est de créer une correspondance univoque entre les éléments dans l'espace du problème et les objets dans l'espace de la solution.

Mais comment obtenir d'un objet qu'il fasse un travail utile pour soi ? Il doit y avoir un moyen de requérir de l'objet qu'il fasse quelque chose, tel qu’effectuer une transaction, tracer quelque chose sur l'écran ou mettre en marche un commutateur. Et chaque objet ne pourra satisfaire que certaines requêtes. Les requêtes que l'on peut faire sur un objet sont définies par son interface, et le type est ce qui détermine l'interface. Un exemple simple pourrait être la représentation d'une ampoule électrique :

Light lt = new Light();
lt.on();

L'interface précise quelles requêtes peuvent être faites sur un objet particulier. Néanmoins, il faut du code quelque part pour satisfaire cette requête. Ceci, ainsi que les données cachées, constitue l'implémentation. Du point de vue de la programmation procédurale, ce n'est pas si compliqué que cela. Un type possède une méthode associée à chaque requête possible, et quand on fait une requête particulière sur un objet, cette méthode est appelée. Ce processus est en général résumé en disant que l'on « envoie un message » (on fait une requête) à un objet, et l'objet comprend ce qu'il faut faire avec ce message (il exécute le code).

Ici, le nom du type/de la classe est Light (N.D.T. : lumière), le nom de cet objet Light particulier est lt et les requêtes que l'on peut faire sur un objet Light sont allumer, éteindre, augmenter l'intensité, diminuer l'intensité. On crée un objet Light en définissant une « référence » (lt) à cet objet et en appelant new pour demander un nouvel objet de ce type. Pour envoyer un message à l'objet, on donne le nom de l'objet et on le relie à la demande de message par un point. Du point de vue de l'utilisateur d'une classe prédéfinie, c'est à peu près tout ce que recouvre la programmation objet.

Le diagramme ci-dessus utilise le format du Langage de Modélisation Unifié (UML). Chaque classe est représentée par un rectangle, avec le nom du type dans sa partie haute, tous les membres de données que l'on estime intéressants à décrire dans sa partie médiane et les méthodes (les fonctions qui appartiennent à l'objet, qui reçoivent tout message envoyé à l'objet) dans sa partie basse. Souvent, seuls le nom de la classe et les méthodes publiques sont indiqués dans le rectangle, ce qui fait que la partie médiane n'est pas affichée. Si l'on n'est intéressé que par le nom de la classe, alors on n'a pas besoin non plus d'afficher la partie basse.

Quand on essaie de développer ou de comprendre la conception d'un programme, une des meilleures façons d'appréhender les objets est d'y penser en tant que « fournisseurs de services ». Votre programme lui-même fournira des services à l'utilisateur et il accomplira cela en utilisant les services offerts par d'autres objets. Votre but est de produire (ou mieux encore de repérer dans des bibliothèques de code existantes) un ensemble d'objets qui fournisse les services idéaux pour résoudre votre problème.

Un moyen de démarrer ce processus est de vous demander « Quels objets résoudraient mon problème, si je pouvais les sortir d'un chapeau comme par magie ? » Supposons, par exemple, que vous êtes en train de créer un programme de comptabilité. Vous pourriez imaginer certains objets qui contiennent des écrans de saisie comptable prédéfinis, un autre ensemble d'objets qui effectuent des calculs comptables et un objet qui gère l'impression des chèques et des factures sur toutes sortes d'imprimantes. Certains de ces objets existent peut-être déjà, et pour ceux qui n'existent pas, à quoi devraient-ils ressembler, quels services ces objets devraient-ils fournir, et de quels objets auraient-ils besoin pour remplir leurs obligations ? Si vous continuez ce processus, vous arriverez à un stade où vous pourrez dire, soit « cet objet est suffisamment simple pour s'arrêter là et le coder », ou bien « je suis sûr que cet objet existe déjà ». C'est une manière réfléchie de décomposer un problème en un ensemble d'objets.

Penser à un objet en tant que fournisseur de services a un autre avantage : cela permet d'améliorer la cohésion de l'objet. Un haut degré de cohésion est une qualité fondamentale de la conception d'un logiciel : cela signifie que les différents aspects d'un composant logiciel (tel un objet, encore que cela pourrait aussi s'appliquer à une méthode ou à une bibliothèque d'objets) « vont bien ensemble ». Un des problèmes que les gens rencontrent quand ils conçoivent des objets est de fourrer beaucoup trop de fonctionnalités dedans. Par exemple, dans votre module d'impression de chèques, vous pourriez décider que vous avez besoin d'un objet qui sait tout du formatage et de l'impression. Vous découvrirez probablement que c'est beaucoup trop pour un objet et que ce dont vous avez besoin est trois objets ou plus. Un des objets pourrait être un catalogue de tous les formats possibles de chèques, que l'on pourrait interroger pour savoir comment imprimer un chèque. Un autre objet ou un jeu d'objets pourrait être une interface générique d'impression qui connaîtrait tous les types d'imprimantes (mais rien à la comptabilité - cet objet serait susceptible d'être acheté plutôt que d'être écrit par vous-même). Et un troisième objet pourrait utiliser les services des deux autres pour accomplir la tâche. Ainsi chaque objet aurait un jeu cohésif de services à offrir. Dans une bonne conception orientée objet, chaque objet fait bien une chose, mais n'essaie pas d'en faire trop. Comme on l'a vu ici, cela permet de découvrir non seulement les objets à acheter éventuellement (l'objet interface imprimante), mais aussi ceux qui pourraient être réutilisés ailleurs (le catalogue de formats de chèques).

Traiter les objets comme des fournisseurs de services est un formidable instrument de simplification. C'est très utile non seulement pendant le processus de conception, mais aussi quand quelqu'un d'autre essaie de comprendre votre code ou de réutiliser un objet - si l'on peut voir la valeur de l'objet sur la base des services qu'il fournit, cela permet de l'adapter beaucoup plus facilement à la conception.

Il est utile de distinguer les créateurs de classes (ceux qui créent les nouveaux types de données) et les programmeurs clients(5) (les consommateurs de classes qui utilisent ces types de données dans leurs applications). Le but du programmeur client est de se constituer une boîte à outils pleine de classes réutilisables pour le développement rapide d'applications (RAD, Rapid Application Development en anglais). Le but du créateur de classes est la construction d'une classe qui n'expose que ce qui est nécessaire au programmeur client et qui conserve tout le reste caché. Pourquoi cela ? Parce que si une portion de code est cachée, le programmeur client ne pouvant pas y accéder, cela signifie que le créateur de la classe peut la modifier à volonté sans se préoccuper de l'impact que cela pourrait avoir chez les utilisateurs de sa classe. La portion cachée correspond généralement aux parties sensibles d'un objet qui pourraient facilement être corrompues par un programmeur client négligent ou mal informé. Ainsi, cacher l'implémentation réduit considérablement les bogues dans les programmes.

Le concept d'implémentation cachée ne saurait être trop recommandé. Dans n'importe quelle relation, il est important de fixer les frontières à respecter par toutes les parties impliquées. Quand on crée une bibliothèque, on établit une relation avec un programmeur client, programmeur qui assemble une application en utilisant notre bibliothèque, éventuellement pour créer une bibliothèque plus conséquente. Si tous les membres d'une classe sont accessibles par tout le monde, alors le programmeur client peut faire ce qu'il veut avec cette classe et il n'y a aucun moyen de faire respecter les règles. Même s'il est vraiment préférable que l'utilisateur de la classe ne manipule pas directement certains membres de la classe, sans contrôle d'accès, il n'y a aucun moyen de l'en empêcher. Tout est exposé à tout le monde.

La raison première du contrôle d'accès est donc d'empêcher les programmeurs clients de toucher à certaines portions auxquelles ils ne devraient pas avoir accès - parties qui sont nécessaires pour le fonctionnement interne du type de données, mais qui n'appartiennent pas à l'interface dont les utilisateurs ont besoin pour résoudre leur problème. C'est en réalité un service rendu aux utilisateurs, car ils peuvent voir facilement ce qui est important pour leurs besoins et ce qu'ils peuvent ignorer.

La deuxième raison d'être du contrôle d'accès est de permettre au concepteur de la bibliothèque de modifier les mécanismes internes de la classe sans se soucier de la manière avec laquelle cela affectera le programmeur client. Par exemple, on peut implémenter une classe particulière d'une manière simpliste afin de faciliter le développement, et se rendre compte plus tard que l'on a besoin de la réécrire afin de rendre son exécution plus rapide. Si l'interface et l'implémentation sont clairement séparées et protégées, cela peut être réalisé facilement.

Java utilise trois mots clés pour fixer les limites au sein d'une classe : public, private et protected. Leur utilisation et leur signification sont assez explicites. Ces spécificateurs d'accès déterminent qui peut utiliser les définitions qui les suivent. public signifie que l'élément qui le suit est disponible pour tout le monde. Le mot clé private, au contraire, signifie que personne ne peut y accéder, excepté le créateur de la classe à l'intérieur des méthodes de la classe. private est un mur de briques entre le créateur de la classe et le programmeur client. Quelqu'un qui tente d'accéder à un membre défini comme private obtiendra une erreur lors de la compilation. Le mot clé protected se comporte comme private, excepté qu'une classe dérivée a accès aux membres protected, mais pas aux membres private. L'héritage sera présenté plus loin.

Java dispose également d'un accès « par défaut », qui entre en jeu si aucun des spécificateurs d'accès mentionnés précédemment n'est utilisé. Cet accès est généralement appelé accès « amical » (ou « package access »), car les classes peuvent accéder aux membres des autres classes du même package, mais, en dehors du package, ces mêmes membres apparaissent comme s'ils étaient déclarés private.

Une fois qu'une classe a été créée et testée, elle devrait (idéalement) représenter une partie de code utile. Il s'avère que cette réutilisabilité n'est pas si facile à obtenir ; cela demande de l'expérience et de l'anticipation pour produire une conception objet réutilisable. Mais une fois bien conçue, cette classe ne demande qu'à être réutilisée. La réutilisation de code est l'un des plus grands avantages offerts par les langages orientés objet.

La manière la plus simple de réutiliser une classe est d'utiliser directement un objet de cette classe, mais on peut aussi placer un objet de cette classe à l'intérieur d'une nouvelle classe. On appelle cela « créer un objet membre ». La nouvelle classe peut être constituée de n'importe quel nombre d'objets d'autres types, selon la combinaison nécessaire pour que la nouvelle classe puisse réaliser ce pour quoi elle a été conçue. Parce que la nouvelle classe est composée à partir de classes existantes, ce concept est appelé composition (si la composition a lieu dynamiquement, on parle d'agrégation). On se réfère souvent à la composition comme à une relation « possède-un », comme dans « une voiture possède un moteur ».

(Ce diagramme UML indique la composition avec le losange rempli, qui indique qu'il y a un moteur dans une voiture. J'utiliserai une forme plus simple : juste une ligne, sans le losange, pour indiquer une association.) (6)

La composition s'accompagne d'une grande flexibilité : les objets membres de la nouvelle classe sont généralement privés, ce qui les rend inaccessibles aux programmeurs clients de la classe. Cela permet de modifier ces membres sans perturber le code des clients existants. On peut aussi changer les objets membres lors la phase d'exécution, pour changer dynamiquement le comportement du programme. L'héritage, décrit juste après, ne dispose pas de cette flexibilité, car le compilateur doit placer des restrictions lors de la compilation sur les classes créées avec héritage.

Parce que la notion d'héritage est très importante au sein de la programmation orientée objet, elle est trop souvent mise en avant, et le nouveau programmeur pourrait croire que l'héritage doit être utilisé partout. Cela mène à des conceptions ultras compliquées et cauchemardesques. La composition est la première approche à examiner lorsqu'on crée une nouvelle classe, car elle est plus simple et plus flexible. Le design de la classe en sera plus propre. Avec de l'expérience, les endroits où utiliser l'héritage deviendront raisonnablement évidents.

L'idée d'objet en elle-même est un outil efficace. Elle permet de fournir des données et des fonctionnalités liées entre elles par concept, afin de représenter une idée de l'espace problème plutôt que d'être forcé d'utiliser les idiomes internes de la machine. Ces concepts sont exprimés en tant qu'unités fondamentales dans le langage de programmation en utilisant le mot clef class.

Il serait toutefois dommage, après s'être donné beaucoup de mal pour créer une classe de devoir en créer une toute nouvelle qui aurait des fonctionnalités similaires. Ce serait mieux si on pouvait prendre la classe existante, la cloner, et faire des ajouts ou des modifications à ce clone. C'est ce que l'héritage permet de faire, avec la différence suivante : si la classe originale (aussi appelée classe de base, superclasse ou classe parent) est changée, le « clone » modifié (appelé classe dérivée, héritée, enfant ou sous-classe) répercutera aussi ces changements.

(La flèche dans ce diagramme UML pointe de la classe dérivée vers la classe de base. Comme vous le verrez, il y a souvent plus d'une classe dérivée.)

Un type fait plus que simplement décrire les contraintes d'un ensemble d'objets; il a aussi une relation avec d'autres types. Deux types peuvent avoir des caractéristiques et des comportements en commun, mais un type peut contenir plus de caractéristiques qu'un autre type, et peut aussi gérer plus de messages (ou les gérer différemment). L'héritage exprime cette similarité entre les types en utilisant le concept des types de base et des types dérivés. Un type de base contient tous les caractéristiques et comportements partagés par les types dérivés à partir de lui. On crée un type de base pour représenter le noyau de ses idées à propos de certains objets dans son système. À partir du type de base, on dérive d'autres types pour exprimer les différentes façons dont ce noyau peut être réalisé.

Par exemple, une machine recyclant les ordures trie les morceaux d'ordure. Le type de base est « ordure », et chaque morceau d'ordure a un poids, une valeur, etc., et peut être déchiqueté, fondu, ou décomposé. À partir de là, des types d'ordures plus spécifiques sont dérivés, qui peuvent avoir des caractéristiques additionnelles (une bouteille a une couleur), ou des comportements (une canette en aluminium peut être écrasée, un bidon d'acier est magnétique). En outre, certains comportements peuvent être différents (la valeur du papier dépend de son type et de son état). En utilisant l'héritage, on peut construire une hiérarchie de types qui exprime le problème à résoudre en termes de types.

Un second exemple est l'exemple classique des « formes », peut-être utilisé dans un système de conception assistée par ordinateur, ou un jeu de simulation. Le type de base est « forme », et chaque forme a une taille, une couleur, une position, etc. Chaque forme peut être dessinée, effacée, déplacée, colorée, etc. À partir de là, des types spécifiques de formes sont dérivés (hérités) - cercle, carré, triangle, etc. -, qui peuvent tous avoir des caractéristiques et des comportements additionnels. Certaines formes peuvent être inversées, par exemple. Certains comportements peuvent être différents, comme quand on veut calculer l'aire d'une forme. La hiérarchie de types englobe à la fois les similarités et les différences entre les formes.

La représentation de la solution dans les mêmes termes que le problème est énormément bénéfique parce que l'on n'a pas besoin de beaucoup de modèles intermédiaires pour aller d'une description du problème à une description de sa solution. Avec des objets, la hiérarchie de types est le modèle primaire, ainsi on va directement de la description du système dans le monde réel à la description du système en code. En effet, l'une des difficultés rencontrées avec la conception orientée objet est qu'il est trop simple d'aller du début à la fin. Un esprit entraîné à chercher des solutions complexes peut être désarçonné par cette simplicité.

En héritant d'un type existant, on crée un nouveau type. Ce dernier, non seulement contient tous les membres du type existant (bien que les membres privés soient cachés et inaccessibles), mais aussi, et c'est le plus important, duplique l'interface de la classe de base. Cela signifie que tous les messages que l'on peut envoyer aux objets de la classe de base peuvent également être envoyés aux objets des classes dérivées. Et puisque l'on reconnaît le type d'une classe en fonction des messages que l'on peut lui envoyer, cela signifie que la classe dérivée est du même type que la classe de base. Dans l'exemple précédent, « un cercle est une forme ». Cette équivalence de types via l'héritage est l'un des points fondamentaux pour la compréhension de la programmation orientée objet.

Comme la classe de base et la classe dérivée ont fondamentalement la même interface, il doit y avoir une implémentation allant avec cette interface. Cela signifie qu'il doit y avoir du code à exécuter quand un objet reçoit un message donné. Si l'on hérite simplement d'une classe sans rien faire d'autre, les méthodes de l'interface de la classe de base sont héritées telles quelles par la classe dérivée. Cela implique que les objets de la classe dérivée n'ont pas seulement le même type, mais aussi le même comportement, ce qui n'est pas particulièrement intéressant.

Il y a deux solutions pour différencier notre nouvelle classe dérivée de la classe de base originale. La première est plutôt franche : on ajoute simplement de nouvelles méthodes à la classe dérivée. Ces nouvelles méthodes ne font pas partie de l'interface de la classe de base. Cela signifie que la classe de base ne faisait pas assez par rapport à ce que nous voulions, donc nous avons ajouté plus de méthodes. Cette utilisation simple et primitive de l'héritage est, parfois, la solution parfaite au problème. Cependant, il faut alors vérifier que la classe de base ne nécessiterait pas l'ajout de ces mêmes nouvelles méthodes. Ce processus de découverte et d'itération de la conception se produit régulièrement dans la programmation orientée objet.

Bien que l'héritage implique parfois (spécialement en Java, où le mot clé pour l'héritage est extends) que l'on va ajouter de nouvelles méthodes à l'interface, ce n'est pas toujours le cas. La deuxième et plus importante solution pour différencier la nouvelle classe est de changer le comportement d'une méthode de la classe de base existante. Cela est appelé surcharger cette méthode.

Pour surcharger une méthode, il suffit de créer une nouvelle définition de cette méthode dans la classe dérivée. On dit « j'utilise la même interface pour cette méthode, mais je veux qu'elle fasse quelque chose de différent pour mon nouveau type ».

I-F-1. Relations est-un versus relations est-comme-un▲

La question de l'héritage soulève un certain débat : l'héritage ne devrait-il pas se contenter, uniquement, de redéfinir les méthodes de la classe parente (et ne pas définir de nouvelles méthodes absentes de cette classe) ? Cela voudrait dire que le type dérivé correspond, exactement, au type de la classe parente, du moment qu'ils partagent exactement la même interface. On pourra, donc, substituer, parfaitement, un objet de la classe dérivée à un objet de la classe parent. Ce genre de substitution pure est souvent appelé principe de substitution. Dans un sens, ce serait la conception idéale de l'héritage. On a, souvent, tendance à qualifier la relation entre la classe parent et la classe dérivée, dans ce cas de figure, de relation est-un, parce qu'on peut dire « un cercle est une forme ». Un test, pour reconnaître la relation d'héritage, serait d'essayer d'appliquer la relation est-un à des classes données et de voir si cela a un sens.

Il existe des cas où il est nécessaire d'ajouter de nouveaux éléments à l'interface du type dérivé, étendant cette interface et créant, ainsi, un nouveau type. Le nouveau type peut toujours remplacer le type parent, mais la substitution n'est pas parfaite puisque les nouvelles méthodes ne sont pas accessibles depuis le type parent.
Cette situation peut être décrite par une relation de type est-comme-un (mon terme). Le nouveau type possède l'interface de l'ancien, mais contient, aussi, d'autres méthodes, c'est pourquoi on ne peut pas vraiment dire qu'il s'agit du même type. Considérons, par exemple, un climatiseur. Supposons que votre maison est équipée pour contrôler le refroidissement de l'air ; en d'autres termes, qu'elle possède une interface permettant de contrôler ce refroidissement. Imaginons, maintenant, que le climatiseur tombe en panne et que vous décidez de le remplacer par une pompe à chaleur, qui peut, à la fois, chauffer et refroidir. La pompe à chaleur est-comme-un climatiseur, mais elle peut faire plus. Puisque le système de contrôle de votre maison est conçu, uniquement, pour contrôler le refroidissement, il ne pourra communiquer qu'avec la partie refroidissement du nouvel objet. L'interface du nouvel objet a été étendue, et le système de contrôle existant ne connaît que l'interface originale.

Bien sûr, une fois que vous aurez analysé cette conception, il apparaîtra clairement que « le système de refroidissement » de la classe parente n'est pas suffisamment général et qu'il devrait être renommé « système de contrôle de la température » afin d'inclure la possibilité de chauffage, ce qui rendra possible le principe de substitution. Cette figure représente, néanmoins, un exemple concret de conception dans le monde réel.

Quand on examine le principe de substitution, on a l'impression que cette approche (substitution pure) est la seule manière de concevoir l'héritage, et, en fait, c'est parfait si la conception s'y prête. Mais vous vous apercevrez que, parfois, il est tout aussi évident qu'il faut ajouter de nouvelles méthodes à l'interface d'une classe dérivée. En regardant de plus près la question, les deux cas devraient être assez évidents.

Quand on a affaire à des hiérarchies de types, on veut souvent traiter un objet non comme le type spécifique qu'il est, mais plutôt comme son type de base. Cela permet d'écrire du code qui ne dépend pas de types spécifiques. Dans l'exemple des formes, les méthodes manipulent des formes génériques sans égard au fait que ce soient des cercles, des carrés, des triangles ou toute autre forme non encore définie. Toutes les formes peuvent être dessinées, supprimées et déplacées, aussi ces méthodes envoient-elles simplement un message à un objet forme ; elles ne s'occupent de savoir comment l'objet réagit au message.

Un tel code reste inchangé lors de l'ajout de nouveaux types, et l'ajout de nouveaux types est la façon la plus courante d'étendre un programme orienté objet afin de gérer de nouvelles situations. Par exemple, on peut dériver un nouveau sous-type de forme appelé pentagone sans modifier les méthodes qui n'opèrent que sur les formes génériques. Cette possibilité d'étendre facilement la conception en dérivant de nouveaux sous-types est l'une des techniques fondamentales d'encapsulation de modifications. Cela améliore grandement la conception tout en réduisant le coût de maintenance du logiciel.

Néanmoins, il y a un problème quand on tente de traiter des objets de type dérivé comme leurs types de base génériques (des cercles comme des formes, des bicyclettes comme des véhicules, des cormorans comme des oiseaux, etc.). Si une méthode est sur le point de dire à une forme générique de se dessiner elle-même, ou à un véhicule générique de se diriger vers un endroit, ou encore à un oiseau générique de se déplacer, le compilateur ne peut pas savoir à la compilation quelle partie précise du code sera exécutée. C'est justement de cela qu'il s'agit - quand le message est envoyé, le programmeur ne veut pas savoir quelle partie du code sera exécutée ; la méthode draw (dessiner) peut être appliquée de la même façon à un cercle, un carré ou un triangle, et l'objet exécutera le code approprié selon son type spécifique. Quand on ne sait pas quelle partie de code sera exécutée, alors on ajoute un nouveau sous-type ; le code qu'il exécutera pourra être différent sans que l'on ait besoin de modifier l'appel de la méthode. Le compilateur ne sait donc pas précisément quelle partie du code sera exécutée, que fait-il alors ? Par exemple, dans le diagramme suivant l'objet BirdController (ContrôleurD'Oiseau) opère uniquement sur des objets génériques Bird (Oiseau) et ne connaît pas leur type exact. C'est parfait du point de vue de BirdController, car il n'a pas besoin d'intégrer un code spécial pour déterminer le type exact de l'objet Bird avec lequel il travaille ou le fonctionnement exact de cet objet. Comment se fait-il donc que lors de l'appel à la méthode move( ) (seDéplacer), le bon fonctionnement se produit, alors même que l'on ignore le type spécifique de l'objet Bird (c'est-à-dire que l'Oie court, vole ou nage et que le Pingouin court ou nage) ?

La réponse tient dans la première distorsion de la programmation orientée objet : le compilateur ne peut faire un appel de fonction dans le sens traditionnel. L'appel de fonction généré par un compilateur non OOP est appelé préassociation. C'est un terme que vous n'avez peut-être jamais entendu auparavant, car vous n'avez jamais envisagé qu'un appel de fonction puisse se faire d'une autre manière. Cela signifie que le compilateur génère un appel à un nom de fonction spécifique et que l'éditeur de liens résout cet appel à l'adresse absolue du code à exécuter. En OOP, le programme ne peut déterminer l'adresse du code avant l'exécution, il faut donc utiliser une autre méthode lors de l'envoi du message à un objet générique.

Pour résoudre le problème, les langages orientés objet utilisent le concept d'association tardive. Quand on envoie un message à un objet, le code appelé n'est pas déterminé avant l'exécution. Le compilateur s'assure que la méthode existe et effectue des vérifications de types sur les arguments et sur la valeur retournée (un langage dans lequel ceci n'est pas fait est appelé langage faiblement typé), mais il ne connaît pas le code exact à exécuter.

Pour effectuer l'association tardive, Java utilise une partie de code spéciale au lieu de l'appel absolu. Ce code calcule l'adresse du corps de la méthode, en utilisant les informations stockées dans l'objet (ce processus est couvert en détail au chapitre 7). Ainsi, chaque objet peut se comporter différemment en fonction du contenu de cette partie de code spéciale. Quand on envoie un message à un objet, l'objet arrive en fait à comprendre ce qu'il doit faire avec le message.

Dans certains langages, on doit déclarer explicitement que l'on veut qu'une méthode possède la flexibilité des propriétés d'association tardive (C++ utilise le mot-clé virtual pour ce faire). Par défaut, les méthodes ne sont pas associées dynamiquement dans ces langages. Dans Java, l'association est dynamique par défaut, on n'a donc pas besoin de se souvenir d'ajouter un mot-clé quelconque pour bénéficier du polymorphisme.

Examinons l'exemple Shape (Forme). La famille des classes (toutes basées sur la même interface uniforme) a été représentée par un diagramme plus haut dans ce chapitre. Pour démontrer le polymorphisme, on veut écrire un bout de code unique qui ignore les détails spécifiques des types et dialogue uniquement avec la classe de base. Ce code est découplé de toute information spécifique au type ; il est donc plus simple à écrire et plus facile à comprendre. De plus, si un nouveau type - un Hexagone par exemple - est ajouté par héritage, le code écrit fonctionnera tout aussi bien pour le nouveau type de Forme que pour les types déjà existants. Ainsi, le programme est extensible.

Si l'on écrit une méthode en Java (ainsi que vous apprendrez à le faire bientôt) :

void doStuff(Shape s) {
    s.erase();
    // ...
    s.draw();
}

cette méthode dialogue avec tout objet Shape (Forme). Elle est donc indépendante du type spécifique d'objet dessiné ou effacé. Si une autre partie du programme utilise la méthode doStuff( )(faireQuelqueChose) :

Circle c = new Circle();
Triangle t = new Triangle();
Line l = new Line();
doStuff(c);
doStuff(t);
doStuff(l);

les appels à doStuff( ) fonctionnent automatiquement de façon correcte, quel que soit le type exact de l'objet.

C'est une particularité assez étonnante. Examinons la ligne :

doStuff(c);

Ici un objet Circle (Cercle) est passé à une méthode qui attend une Forme. Comme un Cercleest une Forme, il peut être traité comme tel par doStuff( ). C'est-à-dire que tout message que doStuff( ) peut envoyer à une Forme est acceptable par un Cercle. Il est donc raisonnable et logique de le faire.

Le processus qui consiste à traiter un type dérivé comme son type de base est appelé transtypage ascendant. Le mot transtypage est utilisé dans le sens de couler dans un moule et le mot ascendant vient de la façon dont le diagramme d'héritage est disposé, avec le type de base en haut et les classes dérivées qui se déploient en éventail vers le bas. Ainsi transtyper vers un type de base, c'est remonter le diagramme d'héritage, d'où le terme : « transtypage ascendant ».

Un programme orienté objet contient quelque part un transtypage ascendant quelconque, car c'est la façon dont on se dégage de l'obligation de savoir avec quel type exact l'on travaille. Observez le code de doStuff( ) :

s.erase();
// ...
s.draw();

Notez qu'il ne dit pas « Si vous êtes un Cercle, faites ceci, si vous êtes un Carré, faites cela, etc. ». Si vous écrivez ce genre de code, qui teste tous les types possibles qu'une Forme peut prendre, c'est compliqué et vous devrez le changer chaque fois que vous ajouterez un nouveau type de Forme. Ici, vous dites juste « Vous êtes une forme, je sais que vous pouvez vous effacer (erase) et vous dessiner (draw), faites-le et occupez-vous des détails correctement ».

Ce qui est étonnant dans le code de doStuff( ), c'est que l'action correcte est produite, on ne sait trop comment. L'appel à draw( ) (se dessiner) pour un Cercle fait s'exécuter un code différent de celui exécuté lors de l'appel à draw( ) pour un Carré ou pour une Ligne, mais quand le message draw( ) est envoyé à une Forme anonyme, l'action correcte est exécutée sur la base du type réel de la Forme. C'est étonnant, car, comme mentionné précédemment, quand le compilateur Java compile le code de doStuff( ), il ne peut pas savoir exactement à quel type il aura à faire. On s'attend donc, normalement, à ce qu'il finisse par appeler les versions de erase( ) (effacer) et de draw( ) (dessiner) de la classe de base Shape (Forme), et non celles de la classe spécifique Circle (Cercle), Square (Carré) ou Line (Ligne). Et pourtant tout se passe correctement grâce au polymorphisme. Le compilateur et le système d'exécution gèrent les détails ; tout ce que vous devez savoir pour l'instant est que ceci se produit, et, ce qui est encore plus important, comment concevoir votre programme en en tenant compte. Quand vous enverrez un message à un objet, l'objet fera ce qu'il doit, même lors d'un transtypage ascendant.

I-G-1. Classes mères abstraites et interfaces▲

Techniquement, la POO n'est rien d'autre que du typage d'objet abstrait, de l'héritage et du polymorphisme, mais d'autres problèmes peuvent être au moins aussi importants. Cette section va couvrir ces problèmes.

Un des plus importants facteurs des objets est la façon dont ils sont créés et détruits. Où sont les données d'un objet et comment son cycle de vie est-il contrôlé ? Il y a différentes philosophies en œuvre ici. C++ considère que le contrôle de l'efficacité est le point le plus important, aussi donne-t-il le choix au programmeur. Pour une vitesse d'exécution maximum, le stockage et le cycle de vie peuvent être déterminés lorsque le programme est en court d'écriture, en plaçant les objets sur la pile (ceux-ci sont parfois appelés variables automatiques ou variables de portée) ou dans la zone de stockage statique. Ceci place la priorité sur la vitesse de stockage et de libération, et leur contrôle peut être très rentable dans quelques situations. Cependant, vous sacrifiez la flexibilité, car vous devez connaître exactement le nombre exact, le cycle de vie et le type des objets lorsque vous êtes en train d'écrire le programme. Si vous essayez de résoudre un problème plus général comme de la conception assistée par ordinateur, une gestion d'entrepôt ou du contrôle de trafic aérien, cela est trop restrictif.

La seconde approche consiste à créer les objets dynamiquement dans un pool de mémoire appelé le tas. Dans cette approche, vous ne connaissez pas jusqu'à l'exécution de combien d'objets vous avez besoin, quel est leur cycle de vie ou quel est le type exact. Tout cela est déterminé au moment où le programme est exécuté. Si vous avez besoin d'un nouvel objet, vous le fabriquez simplement dans le tas au moment où vous en avez besoin. Comme le stockage est géré dynamiquement, à l'exécution, le temps requis pour allouer le stockage sur le tas peut être notablement plus long que le temps pour créer le stockage sur la pile. (Créer du stockage sur la pile est souvent une simple instruction en assembleur pour déplacer le pointeur de pile vers le bas et une autre pour le remettre en place. Le temps pour créer le stockage sur le tas dépend de la conception du mécanisme de stockage.) L'approche dynamique fait souvent la supposition logique que les objets tendent à être compliqués, aussi la charge supplémentaire pour trouver et libérer le stockage n'aura pas un impact important sur la création de l'objet. De plus, une plus grande flexibilité est essentielle pour résoudre des problèmes de programmation d'ordre général.

Java utilise la seconde approche exclusivement. (7) Chaque fois que vous créez un objet, vous utilisez le mot clé new pour construire une instance dynamique de l'objet.

Il y a un autre problème, cependant, et il s'agit du cycle de vie d'un objet. Avec des langages qui autorisent les objets à être créés sur la pile, le compilateur détermine combien de temps l'objet reste et peut automatiquement le détruire. Cependant, si vous le créez dans le tas, le compilateur n'a aucune connaissance de son temps de vie. Dans un langage comme C++, vous devez déterminer par programmation quand détruire l'objet, ce qui peut conduire à des fuites de mémoire si vous ne le faites pas correctement (et cela est un problème commun dans les programmes C++). Java fournit une fonction appelée un ramasse-miettes qui découvre automatiquement quand un objet n'est plus utilisé et le détruit. Un ramasse-miettes est bien plus pratique, car il réduit le nombre de problèmes que vous devez traquer et le code que vous devez écrire. Bien plus important, le ramasse-miettes fournit un plus grand niveau d'assurance contre les problèmes insidieux de fuite de mémoire (lesquels ont mis sur les rotules de nombreux projets C++).

I-H-1. Collections et itérateurs▲

I-H-2. La hiérarchie à racine unique▲

I-H-3. Transtypage descendant vs. modèles/génériques▲

I-H-4. Assurer un nettoyage approprié▲

I-H-5. Ramasses-miettes vs. efficacité et flexibilité▲

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 programmation, 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 orientés objet une exception soit normalement représentée par un objet. Le traitement des exceptions existait avant les langages orientés objet.

Un concept fondamental dans la programmation informatique est l'idée de la prise en charge de plus d'une tâche à la fois. Beaucoup de problèmes de programmation exigent que le programme puisse arrêter ce qu'il fait, s'occupe d'un autre problème, puis retourne au processus principal. La solution a été approchée de beaucoup de manières. Au commencement, les programmeurs, avec la connaissance des couches de bas niveau de la machine, ont écrit des routines de service d'interruption, et la suspension du processus principal était lancée par une interruption provenant du matériel. Bien que cela fonctionne, ce travail était fastidieux et non portable, déplacer un programme vers un nouveau type de machine étant lent et cher.

Parfois, les interruptions sont nécessaires pour manipuler des tâches critiques, mais il y a un grand nombre de problèmes dans lesquels vous essayez simplement de diviser le problème en morceaux fonctionnant séparément de sorte que le programme entier puisse mieux réagir. Dans un programme, ces morceaux fonctionnant séparément s'appellent les processus (threads en anglais), et le concept général s'appelle concurrence ou environnement multiprocessus(multithreading en anglais). Un exemple commun de multithreading est l'interface utilisateur. En employant des threads, un utilisateur peut appuyer sur un bouton et obtenir une réponse rapide, plutôt que devoir attendre jusqu'à ce que le programme finisse sa tâche en cours.

D'habitude, les threads sont juste une manière d'assigner le temps d'exécution d'un processeur unique. Mais si le système d'exploitation supporte plusieurs processeurs, chaque thread peut être assigné à un processeur différent et tous peuvent fonctionner réellement en parallèle. Une des caractéristiques commodes du multithreading, au niveau de la programmation, est que le programmeur n'a pas besoin de s'inquiéter de savoir s'il y a un seul ou plusieurs processeurs. Le programme est divisé logiquement en threads et si la machine possède plus d'un processeur, le programme s'exécute plus rapidement, sans ajustement particulier.

Tout ceci fait penser que l'utilisation des threads est plutôt simple. Il y a une limitation : les ressources partagées. Si vous avez plus d'un thread en exécution tentant d'accéder à la même ressource, vous avez un problème. Par exemple, deux processus ne peuvent pas simultanément envoyer de l'information à une imprimante. Pour résoudre le problème, les ressources qui peuvent être partagées, comme l'imprimante, doivent être verrouillées tant qu'elles sont employées. Ainsi un thread verrouille l'accès à une ressource, accomplit sa tâche, puis libère le verrou de sorte que quelqu'un d'autre puisse employer la ressource.

La gestion des threads Java est incluse dans le langage, ce qui rend un sujet compliqué beaucoup plus simple. Le threading est supporté au niveau objet, ainsi un thread est représenté par un objet. Java fournit également un verrouillage limité de ressources. Il peut verrouiller la mémoire de n'importe quel genre d'objet (qui est, après tout, une sorte de ressource partagée) de sorte que seulement un thread puisse l'employer à la fois. Ceci est accompli avec le mot-clé synchronized. D'autres types de ressources doivent être verrouillés explicitement par le programmeur, typiquement en créant un objet pour représenter le verrou que tous les threads doivent vérifier avant d'accéder à cette ressource.

Lorsque vous créez un objet, celui-ci existe aussi longtemps que vous en aurez besoin, mais cette existence cesse une fois le programme terminé. Même si cela a un sens à première vue, il peut y avoir des situations où il serait extrêmement utile qu'un objet puisse exister avec ses informations en dehors de l'exécution d'un programme. Ainsi, à la prochaine exécution du programme, l'objet serait toujours là et contiendrait les mêmes informations que lors de la précédente exécution du programme. Bien sûr, vous pouvez obtenir le même résultat en inscrivant les informations dans un fichier ou une base de données, mais pour préserver l'aspect purement objet, il serait plus convenable de pouvoir déclarer un objet persistant sans se préoccuper des détails.

Java fournit un support pour une « persistance légère », ce qui veut dire que vous pouvez, facilement, stocker des objets sur disque et les récupérer plus tard. La raison expliquant « légère » est que vous êtes toujours forcé de faire des appels explicites pour le stockage et la récupération. La persistance légère peut être implémentée à travers, à la fois, la serialization d'objet (voir chapitre 12), et Java Data Objects (JDO, voir Thinking in Enterprise Java).

Si Java n'est, en fait, qu'un autre langage de programmation, il est légitime de se demander pourquoi il est tellement important et pourquoi il est présenté comme une étape révolutionnaire de la programmation en informatique. La réponse n'est pas évidente à trouver du point de vue traditionnel de la programmation. Bien que Java soit très utile dans la résolution des problèmes traditionnels et autonomes, il est aussi important parce qu'il va résoudre les problèmes de programmation du Web.

I-L-1. Qu'est-ce que le Web ?▲

I-L-2. Client-side programming▲

I-L-3. Programmation côté serveur▲

I-L-4. Applications▲

La raison pour laquelle Java est si populaire est que son objectif est de résoudre beaucoup de problèmes auxquels les programmeurs font face aujourd'hui. Un but essentiel de Java est d'améliorer la productivité. Des gains de productivité peuvent être obtenus de différentes manières, mais le langage a été conçu pour être une réelle amélioration par rapport à ses prédécesseurs, et pour apporter une aide significative aux programmeurs.

I-M-1. Les systèmes sont plus faciles à décrire et comprendre▲

I-M-2. Puissance maximale grâce aux bibliothèques▲

I-M-3. Traitement des erreurs▲

I-M-4. La programmation à grande échelle▲

Java ressemble beaucoup au C++, aussi, naturellement, il semblerait que C++ sera remplacé par Java. Mais je commence à remettre en question cette logique. Tout d'abord, C++ a encore des fonctionnalités que Java n'a pas, et bien qu'il y ait eu beaucoup de promesses au sujet de Java qui deviendrait un jour aussi rapide ou même plus que le C++, nous avons vu des améliorations régulières, mais aucune percée spectaculaire. En outre, il semble qu'il y ait un intérêt continu pour le C++, aussi je ne pense pas que ce langage ne disparaisse de si tôt. Les langages semblent traîner.

Je commence à penser que la force de Java repose dans un domaine légèrement différent de celui du C++, qui est un langage qui n'essaie pas de rentrer dans un moule. Certainement, il a été adapté dans un nombre de directions pour résoudre des problèmes particuliers. Certains outils C++ combinent des bibliothèques, des modèles de composants et des outils de génération de code pour résoudre le problème du développement d'applications graphiques (pour Windows de Microsoft). Mais qu'utilisent la vaste majorité de développeurs Windows ? Visual Basic de Microsoft (VB). Ceci en dépit du fait que VB produit le type de code qui devient ingérable quand le programme fait seulement quelques pages de long (et la syntaxe qui peut être franchement mystifiante). Aussi réussi et populaire que soit VB, ce n'est pas un très bon exemple de conception de langage. Il serait agréable d'avoir la simplicité et la puissance de VB sans le code ingérable qui en résulte. Et c'est là où je pense que Java brillera : le « prochain VB (9) ». Vous pouvez ou non frissonner en entendant cela, mais pensez-y : tant de choses en Java sont prévues afin de faciliter pour le programmeur la résolution de problèmes de niveau applicatif comme le réseau et les interfaces utilisateur hétérogènes, mais il a une conception de langage qui permet la création de morceaux de code très larges et flexibles. Ajoutez à cela le fait que les vérifications de type et la gestion des erreurs en Java sont une grande amélioration par rapport à la plupart des langages et vous avez les ingrédients d'un saut significatif dans la productivité de programmation.

Si vous développez tout votre code principalement à partir de zéro, alors la simplicité de Java par rapport au C++ réduira significativement votre durée de développement -L'évidence anecdotique (les histoires des équipes C++ à qui j'ai parlé qui ont basculé à Java) suggère un doublement de la vitesse de développement par rapport à C++. Si la performance de Java n'importe pas ou si vous pouvez d'une façon ou d'une autre la compenser, les purs problèmes de délai de réalisation rendent difficile de choisir C++ plutôt que Java.

La plus grande question est la performance. Java interprété a été lent, même 20 à 50 fois plus lent que le C pour les interpréteurs Java d'origine. Ceci a été grandement amélioré avec le temps (particulièrement avec les versions les plus récentes de Java, mais cela reste toujours une quantité importante. L'essentiel pour les ordinateurs c'est la vitesse ; si ce n'était pas significativement plus rapide de faire quelque chose sur un ordinateur, vous le feriez à la main (j'ai même entendu suggérer que vous débutiez avec Java, pour gagner le court temps de développement, ensuite utiliser un outil et des bibliothèques de support pour traduire votre code en C++, si vous avez besoin d'une vitesse d'exécution plus grande).

La clé pour rendre Java faisable pour de nombreux projets de développement est l'apparition d'améliorations de la vitesse telles que compilateurs nommés « Just-in-time » (JIT), la technologie « hotspot » de Sun, et même les compilateurs de code natif. Bien sûr, les compilateurs de code natif élimineront l'exécution multiplateforme si appréciée pour les programmes compilés, mais ils apporteront également la vitesse de l'exécutable proche de celle du C et du C++. Et compiler, pour plusieurs plateformes, un programme en Java devrait être beaucoup plus facile que de le faire en C ou en C++ (en théorie, vous avez juste à recompiler, mais cette promesse a déjà été faite pour d'autres langages).

Ce chapitre tente de vous donner un aperçu des sujets couverts par la programmation orientée objet et Java, y compris pourquoi la POO est différente, et particulièrement pourquoi Java est différent.

La POO et Java ne sont pas forcément destinés à tout le monde. Il est important d'évaluer vos propres besoins et décider si Java satisfera au mieux ces besoins, ou si un autre système de programmation ne vous conviendrait pas mieux (y compris celui que vous utilisez actuellement). Si vous savez que vos besoins seront très spécialisés pour le futur et si vous avez des contraintes spécifiques qui ne peuvent pas être satisfaites par Java, alors vous vous devez d'étudier les alternatives (en particulier, je recommande de regarder dans la direction de Python ; voir www.Python.org). Même si vous choisissez finalement Java comme langage, vous comprendrez au moins quelles étaient les options et vous aurez une vision claire de pourquoi vous avez pris cette direction.

Vous savez à quoi ressemble un programme procédural : des définitions de données et des appels de fonction. Pour trouver le sens d'un tel programme, vous devez travailler un peu, cherchant à travers les appels de fonction et des concepts de bas niveau pour créer un modèle dans votre esprit. C'est la raison pour laquelle nous avons besoin de représentations intermédiaires quand on conçoit des programmes procéduraux - par eux-mêmes, ces programmes tendent à être confus parce que les termes de l'expression sont plus orientés vers la machine que vers le problème que vous résolvez.

Parce que Java introduit de nombreux nouveaux concepts au-dessus de ceux que vous trouvez dans un langage procédural, votre supposition naturelle pourrait être que la fonction main( ) dans un programme Java sera bien plus compliquée que pour le programme C équivalent. Ici, vous serez agréablement surpris : un programme Java bien écrit est généralement beaucoup plus simple et plus facile à comprendre le programme C équivalent. Ce que vous verrez est les définitions des objets qui représentent des concepts de l'espace de votre problème (plutôt que des préoccupations de la représentation informatique) et des messages envoyés à ces objets pour représenter les activités dans cet espace. L'un des plaisirs de la POO est qu'avec un programme bien conçu, il est facile de comprendre le code en le lisant. De plus, il y a généralement beaucoup moins de code, car beaucoup de vos problèmes seront résolus en réutilisant du code de bibliothèque existant.