 |
|
1) Introduction sur les « objets » |
|
|
|
|
| Texte original |
|
Traducteur :
Jérome Quelin |
|
|
|
|
|
Ce chapitre contient
8 pages
1
2
3
4
5
6
7
8
|
|
|
|
|
|
|
|
|
|
|
|
22.06.2001 - version 5.8 :
- Ajout des tags de séparation de pages pour le site (Armel).
28.04.2001 - version 5.7 :
- Remise en forme du code html [Armel avec HTML-Kit],
balises font, a...
04.08.2000 - version 5.6 :
- Corrections apportées par Daniel Le Berre
26.06.2000 - version 5.5 :
- Insertion du journal de log.
18.06.2000 - version 5.4 :
- Modification des tags {url: http://www.blahblah.com} en www.blahblah.com.
- "langage de scripting" modifié en "langage de script".
- Modification des guillemets "" en «».
06.06.2000 - version 5.3 :
- Corrections apportées par Philippe Boîte.
05.06.2000 - version 5.2 :
- Corrections apportées par Jean-Pierre Vidal.
02.06.2000 - version 5.1 :
- Première publication sur eGroups.
Traducteur :
- Jérome QUELIN
Texte original :
- Thinking in Java, 2nd edition, Revision 10
© 2000 by Bruce ECKEL
|
|
|
|
1: Introduction
to Objects
|
|
1) Introduction sur les Objets
|
|
|
|
The genesis of the computer
revolution was in a machine. The genesis of our programming languages thus tends
to look like that machine.
|
|
La révolution informatique a pris naissance dans une machine. Nos
langages de programmation ont donc tendance à ressembler à cette machine.
|
|
|
|
But computers are not so much machines as
they are mind amplification tools (“bicycles for the mind,” as Steve
Jobs is fond of saying) and a different kind of expressive medium. As a result,
the tools are beginning to look less like machines and more like parts of our
minds, and also like other forms of expression such as writing, painting,
sculpture, animation, and filmmaking. Object-oriented programming (OOP) is part
of this movement toward using the computer as an expressive
medium.
|
|
Mais les ordinateurs ne sont pas tant des machines que des outils au
service de l'esprit (« des vélos pour le cerveau », comme aime à le répéter Steve Jobs)
et un nouveau moyen d'expression. Ainsi, ces outils commencent à moins ressembler à des machines et
plus à des parties de notre cerveau ou d'autres formes d'expressions telles que l'écriture, la
peinture, la sculpture ou la réalisation de films. La Programmation Orientée Objet (POO) fait
partie de ce mouvement qui utilise l'ordinateur en tant que moyen d'expression.
|
|
|
|
This chapter will introduce you to the
basic
concepts of OOP, including an overview of development methods. This chapter, and
this book, assume that you have had experience in a
procedural programming language, although not necessarily C. If you think you
need more preparation in programming and the syntax of C before tackling this
book, you should work through the Thinking in C: Foundations for C++ and
Java training CD ROM, bound in with this book and also available at
www.BruceEckel.com.
|
|
Ce chapitre présente les concepts de base de la POO, y compris
quelques méthodes de développement. Ce chapitre et ce livre présupposent que vous avez déjà
expérimenté avec un langage de programmation procédural, bien que celui-ci ne soit pas forcément le
C. Si vous pensez que vous avez besoin de plus de pratique dans la programmation et / ou la syntaxe
du C avant de commencer ce livre, vous devriez explorer le CD ROM fourni avec le livre,
Thinking in C: Foundations for C++ and Java, aussi disponible sur
www.BruceEckel.com.
|
|
|
|
This chapter is background and
supplementary material. Many people do not feel comfortable wading into
object-oriented programming without understanding the big picture first. Thus,
there are many concepts that are introduced here to give you a solid overview of
OOP. However, many other people don’t get the big picture concepts until
they’ve seen some of the mechanics first; these people may become bogged
down and lost without some code to get their hands on. If you’re part of
this latter group and are eager to get to the specifics of the language, feel
free to jump past this chapter—skipping it at this point will not prevent
you from writing programs or learning the language. However, you will want to
come back here eventually to fill in your knowledge so you can understand why
objects are important and how to design with
them.
|
|
Ce chapitre tient plus de la culture générale. Beaucoup de personnes ne
veulent pas se lancer dans la programmation orientée objet sans en comprendre d'abord les tenants
et les aboutissants. C'est pourquoi nous allons introduire ici de nombreux concepts afin de vous
donner un solide aperçu de la POO. Au contraire, certaines personnes ne saisissent les concepts
généraux qu'après en avoir vu quelques mécanismes mis en oeuvre ; ces gens-là se sentent
perdus s'ils n'ont pas un bout de code à se mettre sous la dent. Si vous faites partie de cette
catégorie de personnes et êtes impatients d'attaquer les spécificités du langage, vous pouvez
sauter ce chapitre - cela ne vous gênera pas pour l'écriture de programme ou l'apprentissage du
langage. Mais vous voudrez peut-être y revenir plus tard pour approfondir vos connaissances sur les
objets, les comprendre et assimiler la conception objet.
|
|
|
|
The progress of abstraction
|
|
Les bienfaits de l'abstraction
|
|
|
|
All programming languages provide
abstractions. It can be argued that the complexity of the problems you’re
able to solve is directly related to the kind and quality of
abstraction. By “kind” I mean, “What is
it that you are abstracting?” Assembly language is a small abstraction of
the underlying machine. Many so-called “imperative” languages that
followed (such as Fortran, BASIC, and C) were abstractions of assembly language.
These languages are big improvements over assembly language, but their primary
abstraction still requires you to think in terms of the structure of the
computer rather than the structure of the problem you are trying to solve. The
programmer must establish the association between the machine model (in the
“solution space,” which
is the place where you’re modeling that problem, such as a computer) and
the model of the problem that is actually being solved (in the
“problem space,” which
is the place where the problem exists). The effort required to perform this
mapping, and the fact that it is extrinsic to the programming language, produces
programs that are difficult to write and expensive to maintain, and as a side
effect created the entire “programming methods”
industry.
|
|
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 qu'à la 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 ».
|
|
|
|
The alternative to modeling the machine
is to model the problem you’re trying to solve. Early languages such as
LISP and APL chose particular views of the world (“All problems are
ultimately lists” or “All problems are algorithmic,”
respectively). PROLOG casts all problems into chains of decisions. Languages
have been created for constraint-based programming and for programming
exclusively by manipulating graphical symbols. (The latter proved to be too
restrictive.) Each of these approaches is a good solution to the particular
class of problem they’re designed to solve, but when you step outside of
that domain they become awkward.
|
|
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.
|
|
|
|
The object-oriented approach goes a step
further by providing tools for the programmer to represent elements in the
problem space. This representation is general enough that the programmer is not
constrained to any particular type of problem. We refer to the elements in the
problem space and their representations in the solution space
as “objects.” (Of course, you will also need
other objects that don’t have problem-space analogs.) The idea is that the
program is allowed to adapt itself to the lingo of the problem by adding new
types of objects, so when you read the code describing the solution,
you’re reading words that also express the problem. This is a more
flexible and powerful language abstraction than what we’ve had before.
Thus, OOP allows you to describe the problem in terms of the problem, rather
than in terms of the computer where the solution will run. There’s still a
connection back to the computer, though. Each object looks quite a bit like a
little computer; it has a state, and it has operations that you can ask it to
perform. However, this doesn’t seem like such a bad analogy to objects in
the real world—they all have characteristics and behaviors.
|
|
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 ». (Bien sûr, on aura aussi besoin d'autres objets qui n'ont pas leur analogue
dans l'espace problème). L'idée est que le programme est autorisé à s'adapter à l'esprit du
problème en ajoutant de nouveaux types d'objet, 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. Ainsi, la POO permet de décrire le
problème avec les termes mêmes du problème plutôt qu'avec les termes de la machine où la solution
sera mise en oeuvre. Il y a tout de même une connexion avec l'ordinateur, bien entendu. Chaque
objet ressemble à un mini-ordinateur ; il a un état, et il a à sa disposition des opérations
qu'on peut lui demander d'exécuter. Cependant, là encore on retrouve une analogie avec les objets
du monde réel - ils ont tous des caractéristiques et des comportements.
|
|
|
|
Some language designers have decided that
object-oriented programming by itself is not adequate to easily solve all
programming problems, and advocate the combination of various approaches into
multiparadigm programming
languages.[2]
|
|
Des concepteurs de langage ont décrété que la programmation orientée objet
en elle-même n'était pas adéquate pour résoudre facilement tous les problèmes de programmation, et
recommandent la combinaison d'approches variées dans des langages de programmation
multiparadigmes.[2]
|
|
|
|
Alan Kay summarized five
basic characteristics of Smalltalk,
the first successful object-oriented language and one of the languages upon
which Java is based. These characteristics represent a pure approach to
object-oriented
programming:
|
|
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 :
|
|
|
|
- Everything is an
object. Think of an object as a fancy variable;
it stores data, but you can “make requests” to that object, asking
it to perform operations on itself. In theory, you can take any conceptual
component in the problem you’re trying to solve (dogs, buildings,
services, etc.) and represent it as an object in your
program.
- A program is a bunch of objects
telling each other what to do by sending
messages. To make a request of an object, you
“send a message” to that object. More concretely, you can think of a
message as a request to call a function that belongs to a particular
object.
- Each object has its own memory made
up of other objects. Put another way, you create
a new kind of object by making a package containing existing objects. Thus, you
can build complexity in a program while hiding it behind the simplicity of
objects.
- Every object has a
type. Using the parlance, each object is an
instance of a class, in which “class” is synonymous
with “type.” The most important distinguishing characteristic of a
class is “What messages can you send to
it?”
- All objects of a particular type
can receive the same messages. This is actually
a loaded statement, as you will see later. Because an object of type
“circle” is also an object of type “shape,” a circle is
guaranteed to accept shape messages. This means you can write code that talks to
shapes and automatically handle anything that fits the description of a shape.
This substitutability is one of the most powerful concepts in
OOP.
|
|
- Toute chose est un objet. Il faut penser à un objet comme
à une variable améliorée : il stocke des données, mais on peut « effectuer des
requêtes » sur cet objet, lui demander de faire 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, etc...) et le représenter en tant qu'objet dans le
programme.
- Un programme est un ensemble d'objets se disant les uns aux autres
quoi faire en s'envoyant des messages. Pour qu'un objet effectue une requête, on
« envoie un message » à cet objet. Plus concrètement, on peut penser à un message comme à
un appel de fonction appartenant à 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 oeuvre.
- Chaque objet est d'un type précis. Dans le jargon de la
POO, chaque objet est une instance d'une classe, où « 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 le même
message. C'est une caractéristique lourde de signification, comme vous le verrez plus
tard. Parce qu'un objet de type « cercle » est aussi un objet de type « forme géométrique
», un cercle se doit d'accepter les messages destinés aux formes géométriques. Cela veut dire qu'on
peut écrire du code parlant aux formes géométriques qui sera accepté par tout ce qui correspond à
la description d'une forme géométrique. Cette substituabilité est l'un des concepts les
plus puissants de la programmation orientée objet.
|
|
|
|
An object has an interface
|
|
Un objet dispose d'une interface
|
|
|
|
Aristotle was probably the first to begin
a careful study of the concept of type; he spoke of “the class of
fishes and the class of birds.” The idea that all objects, while being
unique, are also part of a class of objects that have characteristics and
behaviors in common was used directly in the first object-oriented language,
Simula-67, with its fundamental keyword class that introduces a new type
into a program.
|
|
Aristote fut probablement le premier à commencer une étude approfondie du
concept de type ; il parle de « la classe des poissons et la classe des oiseaux ».
L'idée que tous les objets, tout en étant uniques, appartiennent à 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, avec son mot clef fondamental class qui introduit un
nouveau type dans un programme.
|
|
|
|
Simula,
as its name implies, was created for developing simulations such as the classic
“bank teller problem.” In this, you have a bunch of tellers,
customers, accounts, transactions, and units of money—a lot of
“objects.” Objects that are identical except for their state during
a program’s execution are grouped together into “classes of
objects” and that’s where the
keyword class came from.
Creating abstract data types (classes) is a fundamental concept in
object-oriented programming. Abstract data types work almost exactly like
built-in types: You can create variables of a type (called objects or
instances in object-oriented parlance) and manipulate those variables
(called sending messages or
requests; you send a message and the object figures
out what to do with it). The members (elements) of each class share some
commonality: every account has a balance, every teller can accept a deposit,
etc. At the same time, each member has its own state, each account has a
different balance, each teller has a name. Thus, the tellers, customers,
accounts, transactions, etc., can each be represented with a unique entity in
the computer program. This entity is the object, and each object belongs to a
particular class that defines its characteristics and
behaviors.
|
|
Simula, comme son nom l'indique, a été conçu pour développer
des simulations telles qu'un guichet de banque. Dans celle-ci, vous avez un ensemble de
guichetiers, de clients, de comptes, de transactions et de devises - un tas « d'objets ».
Des objets semblables, leur état durant l'exécution du programme mis à part, sont groupés ensemble
en tant que « classes d'objets » et c'est de là que vient le mot clef
class. Créer des types de données abstraits (des classes) est un concept
fondamental dans la programmation orientée objet. On utilise les types de données abstraits
exactement de la même manière que les types de données prédéfinis. On peut créer des variables d'un
type particulier (appelés objets ou instances dans le jargon OO) et manipuler ces
variables (ce qu'on appelle envoyer des messages ou des requêtes ;
on envoie un message et l'objet se débrouille pour le traiter). Les membres (éléments) d'une même
classe partagent des caractéristiques communes : chaque compte dispose d'un solde, chaque
guichetier peut accepter un dépôt, etc... Cependant, chaque élément a son propre état : chaque
compte a un solde différent, chaque guichetier a un nom. Ainsi, les guichetiers, clients, comptes,
transactions, etc... peuvent tous être représentés par la même entité au sein du programme. Cette
entité est l'objet, et chaque objet appartient à une classe particulière qui définit ses
caractéristiques et ses comportements.
|
|
|
|
So, although what we really do in
object-oriented programming is create new data types, virtually all
object-oriented programming languages use the “class” keyword. When
you see the word “type” think “class” and vice
versa[3].
|
|
Donc, comme la programmation orientée objet consiste en la création de
nouveaux types de données, quasiment tous les langages orientés objet utilisent le mot clef
« class ». Quand vous voyez le mot « type » pensez « classe » et
inversement [3].
|
|
|
|
Since a class describes a set of objects
that have identical characteristics (data elements) and behaviors
(functionality), a class is really a
data type because a floating point
number, for example, also has a set of characteristics and behaviors. The
difference is that a programmer defines a class to fit a problem rather than
being forced to use an existing data type that was designed to represent a unit
of storage in a machine. You extend the programming language by adding new data
types specific to your needs. The programming system welcomes the new classes
and gives them all the care and type-checking that it gives to built-in
types.
|
|
Comme une classe décrit un ensemble d'objets partageant des
caractéristiques communes (données) et des comportements (fonctionnalités), une classe est
réellement un type de données. En effet, un nombre en virgule flottante par exemple, dispose d'un
ensemble de caractéristiques et de comportements. La différence est qu'un programmeur définit une
classe pour représenter un problème au lieu d'être forcé d'utiliser un type de données conçu pour
représenter une unité de stockage de l'ordinateur. Le langage de programmation est étendu en
ajoutant de nouveaux types de données spécifiques à nos besoins. Le système de programmation
accepte la nouvelle classe et lui donne toute l'attention et le contrôle de type qu'il fournit aux
types prédéfinis.
|
|
|
|
The object-oriented approach is not
limited to building simulations. Whether or not you agree that any program is a
simulation of the system you’re designing, the use of OOP techniques can
easily reduce a large set of problems to a simple solution.
|
|
L'approche orientée objet n'est pas limitée aux simulations. Que vous
pensiez ou non que tout programme n'est qu'une simulation du système qu'on représente,
l'utilisation des techniques de la POO peut facilement réduire un ensemble de problèmes à une
solution simple.
|
|
|
|
Once a class is established, you can make
as many objects of that class as you like, and then manipulate those objects as
if they are the elements that exist in the problem you are trying to solve.
Indeed, one of the challenges of object-oriented programming is to create a
one-to-one mapping between the elements in the problem space and objects in the
solution space.
|
|
Une fois qu'une classe est créée, on peut créer autant d'objets de cette
classe qu'on veut et les manipuler comme s'ils étaient les éléments du problème qu'on tente de
résoudre. En fait, l'une des difficultés de la programmation orientée objet est de créer une
association un-à-un entre les éléments de l'espace problème et les éléments de l'espace
solution.
|
|
|
|
But how do you get an object to do useful
work for you? There must be a way to make a request of the object so that it
will do something, such as complete a transaction, draw something on the screen,
or turn on a switch. And each object can satisfy only certain requests. The
requests you can make of an object are defined by its interface, and the
type is what determines the interface. A simple example might be a
representation of a light bulb:
|
|
Mais comment utiliser un objet ? Il faut pouvoir lui demander
d'exécuter une requête, telle que terminer une transaction, dessiner quelque chose à l'écran, ou
allumer un interrupteur. Et chaque objet ne peut traiter que certaines requêtes. Les requêtes qu'un
objet est capable de traiter sont définies par son interface, et son type est ce qui
détermine son interface. Prenons l'exemple d'une ampoule électrique :
|
|
|
|
|
|
|
|
|
|
|
Light lt = new Light();
lt.on();
|
|
Ampoule amp = new Ampoule();
amp.allumer();
|
|
|
|
The interface establishes what
requests you can make for a particular object. However, there must be code
somewhere to satisfy that request. This, along with the hidden data, comprises
the implementation. From a procedural programming
standpoint, it’s not that complicated. A type has a function associated
with each possible request, and when you make a particular request to an object,
that function is called. This process is usually summarized by saying that you
“send a message” (make a request) to an object, and the object
figures out what to do with that message (it executes code).
|
|
L'interface précise quelles opérations on peut effectuer sur un
objet particulier. Cependant, il doit exister du code quelque part pour satisfaire cette requête.
Ceci, avec les données cachées, constitue l'implémentation. Du point de vue de la
programmation procédurale, ce n'est pas si compliqué. Un type dispose d'une fonction associée à
chaque requête possible, et quand on effectue une requête particulière sur un objet, cette fonction
est appelée. Ce mécanisme est souvent résumé en disant qu'on « envoie un message » (fait une
requête) à un objet, et l'objet se débrouille pour l'interpréter (il exécute le code
associé).
|
|
|
|
Here, the name of the type/class is
Light, the name of this particular Light object is lt,
and the requests that you can make of a Light object are to turn it
on, turn it off, make it brighter, or make it dimmer. You create a Light
object by defining a “reference” (lt) for that object and
calling new to request a new object of that type. To send a message to
the object, you state the name of the object and connect it to the message
request with a period (dot). From the standpoint of the user of a predefined
class, that’s pretty much all there is to programming with
objects.
|
|
Ici, le nom du type / de la classe est Ampoule, le nom de
l'objet Ampoule créé est amp, et on peut demander à un objet
Ampoule de s'allumer, de s'éteindre, d'intensifier ou de diminuer sa luminosité.
Un objet Ampoule est créé en définissant une « référence »
(amp) pour cet objet et en appelant new pour créer un nouvel
objet de ce type. Pour envoyer un message à cet objet, il suffit de spécifier le nom de l'objet
suivi de la requête avec un point entre les deux. Du point de vue de l'utilisateur d'une classe
prédéfinie, c'est tout ce qu'il est besoin de savoir pour programmer avec des objets.
|
|
|
|
The diagram shown above follows the
format of the Unified Modeling
Language (UML). Each class is represented by a box, with the type name in
the top portion of the box, any data members that you care to describe in the
middle portion of the box, and the
member functions (the
functions that belong to this object, which receive any messages you send to
that object) in the bottom portion of the box. Often, only the name of the class
and the public member functions are shown in UML design diagrams, and so the
middle portion is not shown. If you’re interested only in the class name,
then the bottom portion doesn’t need to be shown,
either.
|
|
L'illustration ci-dessus reprend le formalisme UML (Unified Modeling
Language). Chaque classe est représentée par une boîte, avec le nom du type dans la partie
supérieure, les données membres qu'on décide de décrire dans la partie du milieu et
les fonctions membres (les fonctions appartenant à cet objet qui reçoivent les
messages envoyées à cet objet) dans la partie du bas de la boîte. Souvent on ne montre dans les
diagrammes UML que le nom de la classe et les fonctions publiques, et la partie du milieu n'existe
donc pas. Si seul le nom de la classe nous intéresse, alors la portion du bas n'a pas besoin d'être
montrée non plus.
|
|
|
|
The hidden implementation
|
|
L'implémentation cachée
|
|
|
|
It is helpful to break up the playing
field into class creators (those who create new
data types) and client
programmers[4]
(the class consumers who use the data types in their applications). The goal of
the client programmer is to collect a toolbox full of classes to use for rapid
application development. The goal of the class creator is to build a class that
exposes only what’s necessary to the client programmer and keeps
everything else hidden. Why? Because if it’s hidden, the client programmer
can’t use it, which means that the class creator can change the hidden
portion at will without worrying about the impact to anyone else. The hidden
portion usually represents the tender insides of an object that could easily be
corrupted by a careless or uninformed client programmer, so hiding the
implementation reduces program bugs. The concept of
implementation hiding cannot be
overemphasized.
|
|
Il est plus facile de diviser les personnes en créateurs de
classe (ceux qui créent les nouveaux types de données) et programmeurs
clients [4] (ceux qui utilisent ces
types de données dans leurs applications). Le but des programmeurs clients est de se monter une
boîte à outils pleine de classes réutilisables pour le développement rapide d'applications (RAD,
Rapid Application Development en anglais). Les créateurs de classes, eux, se focalisent sur la
construction d'une classe qui n'expose que le nécessaire aux programmeurs clients et cache tout le
reste. Pourquoi cela ? Parce que si c'est caché, le programmeur client ne peut l'utiliser, et
le créateur de la classe peut changer la portion cachée comme il l'entend sans se préoccuper de
l'impact que cela pourrait avoir chez les utilisateurs de sa classe. La portion cachée correspond
en général aux données de l'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
bugs.
|
|
|
|
In any relationship it’s important
to have boundaries that are respected by all parties involved. When you create a
library, you establish a relationship with the client programmer, who is
also a programmer, but one who is putting together an application by using your
library, possibly to build a bigger library.
|
|
Le concept d'implémentation cachée ne saurait être trop loué :
dans chaque relation il est important de fixer des frontières respectées par toutes les parties
concernées. Quand on crée une bibliothèque, on établit une relation avec un programmeur client,
programmeur qui crée une application (ou une bibliothèque plus conséquente) en utilisant
notre bibliothèque.
|
|
|
|
If all the members of a class are
available to everyone, then the client programmer can do anything with that
class and there’s no way to enforce rules. Even though you might really
prefer that the client programmer not directly manipulate some of the members of
your class, without access control there’s no way to prevent it.
Everything’s naked to the world.
|
|
Si tous les membres d'une classe sont accessibles pour 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 certaines 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'empêcher : tout est exposé à tout le monde.
|
|
|
|
So the first reason for access control is
to keep client programmers’ hands off portions they shouldn’t
touch—parts that are necessary for the internal machinations of the data
type but not part of the interface that users need in order to solve their
particular problems. This is actually a service to users because they can easily
see what’s important to them and what they can ignore.
|
|
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 - les parties
qui sont nécessaires pour les manipulations internes du type de données mais 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.
|
|
|
|
The second reason for access control is
to allow the library designer to change the internal workings of the class
without worrying about how it will affect the client programmer. For example,
you might implement a particular class in a simple fashion to ease development,
and then later discover that you need to rewrite it in order to make it run
faster. If the interface and implementation are clearly separated and protected,
you can accomplish this
easily.
|
|
La deuxième raison d'être du contrôle d'accès est de permettre au
concepteur de la bibliothèque de changer le fonctionnement interne de la classe sans se soucier des
effets que cela peut avoir sur les programmeurs clients. Par exemple, on peut implémenter une
classe particulière d'une manière simpliste afin d'accélérer le développement, et se rendre compte
plus tard qu'on a besoin de la réécrire afin de gagner en performances. Si l'interface et
l'implémentation sont clairement séparées et protégées, cela peut être réalisé
facilement.
|
|
|
|
Java uses three explicit keywords to set
the boundaries in a class: public, private, and protected.
Their use and meaning are quite straightforward. These access specifiers
determine who
can use the definitions that follow. public means
the following definitions are available to everyone. The private
keyword, on the other hand, means that no one can access
those definitions except you, the creator of the type, inside member functions
of that type. private is a brick wall between you and the client
programmer. If someone tries to access a private member, they’ll
get a compile-time error. protected acts like
private, with the exception that an inheriting class has access to
protected members, but not private members. Inheritance will be
introduced shortly.
|
|
Java utilise trois mots clefs pour fixer des limites au sein d'une
classe : public, private et protected. Leur
signification et leur utilisation est relativement explicite. Ces spécificateurs
d'accès déterminent qui peut utiliser les définitions qui
suivent. public veut dire que les définitions suivantes sont disponibles pour
tout le monde. Le mot clef private, au contraire, veut dire que personne, le
créateur de la classe et les fonctions internes de ce type mis à part, ne peut accéder à ces
définitions. private est un mur de briques entre le créateur de la classe et le
programmeur client. Si quelqu'un tente d'accéder à un membre défini comme private,
ils récupèreront une erreur lors de la compilation. protected se comporte
comme private, en moins restrictif : une classe dérivée a accès aux membres
protected, mais pas aux membres private. L'héritage sera
introduit bientôt.
|
|
|
|
Java also has a “default”
access, which comes into play if you don’t use one of the aforementioned
specifiers. This is sometimes called “friendly” access because
classes can access the friendly members of other classes in the same package,
but outside of the package those same friendly members appear to be
private.
|
|
Java dispose enfin d'un accès « par défaut », utilisé si aucun de
ces spécificateurs n'est mentionné. Cet accès est souvent appelé accès « amical » car les
classes peuvent accéder aux membres amicaux des autres classes du même package, mais en dehors du
package ces mêmes membres amicaux se comportent comme des attributs
private.
|
|
|
|
Reusing the implementation
|
|
Réutilisation de l'implémentation
|
|
|
|
Once a class has been created and tested,
it should (ideally) represent a useful unit of code. It turns out that this
reusability is not nearly so easy to achieve as many would
hope; it takes experience and insight to produce a good design. But once you
have such a design, it begs to be reused. Code reuse is one of the greatest
advantages that object-oriented programming languages provide.
|
|
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 aussi
facile à obtenir que cela ; cela demande de l'expérience et de l'anticipation pour produire un
bon design. 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 que les langages orientés objets
fournissent.
|
|
|
|
The simplest way to reuse a class is to
just use an object of that class directly, but you can also place an object of
that class inside a new class. We call this “creating a
member object.” Your new class
can be made up of any number and type of other objects, in any combination that
you need to achieve the functionality desired in your new class. Because you are
composing a new class from existing classes, this concept is called
composition (or more generally,
aggregation). Composition is often referred to as a
“has-a” relationship, as in “a car has
an engine.”
|
|
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 (ou, plus généralement, agrégation). On
se réfère souvent à la composition comme à une relation « possède-un », comme dans
« une voiture possède un moteur ».
|
|
|
|
|
|
|
|
|
|
(The above UML
diagram indicates composition with the filled diamond, which states there is one
car. I will typically use a simpler form: just a line, without the diamond, to
indicate an
association.[5])
|
|
(Le diagramme UML ci-dessus 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 [5].)
|
|
|
|
Composition comes with a great deal of
flexibility. The member objects of your new class are usually private, making
them inaccessible to the client programmers who are using the class. This allows
you to change those members without disturbing existing client code. You can
also change the member objects at run-time, to dynamically change the behavior
of your program. Inheritance, which is described next, does not have this
flexibility since the compiler must place compile-time restrictions on classes
created with inheritance.
|
|
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.
|
|
|
|
Because inheritance is so important in
object-oriented programming it is often highly emphasized, and the new
programmer can get the idea that inheritance should be used everywhere. This can
result in awkward and overly complicated designs. Instead, you should first look
to composition when creating new classes, since it is simpler and more flexible.
If you take this approach, your designs will be cleaner. Once you’ve had
some experience, it will be reasonably obvious when you need
inheritance.
|
|
Parce que la notion d'héritage est très importante au sein de la
programmation orientée objet, elle est trop souvent martelée, et le nouveau programmeur pourrait
croire que l'héritage doit être utilisé partout. Cela mène à des conceptions ultra 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.
|
|
|
|
Inheritance:
reusing the interface
|
|
Héritage : réutilisation de l'interface
|
|
|
|
By itself, the idea of an object is a
convenient tool. It allows you to package data and functionality together by
concept, so you can represent an appropriate problem-space idea rather
than being forced to use the idioms of the underlying machine. These concepts
are expressed as fundamental units in the programming language by using the
class
keyword.
|
|
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é fondamentale dans le langage de programmation en utilisant
le mot clef class.
|
|
|
|
It seems a pity, however, to go to all
the trouble to create a class and then be forced to create a brand new one that
might have similar functionality. It’s nicer if we can take the existing
class, clone it, and then make additions and modifications to the clone. This is
effectively what you get with inheritance, with the
exception that if the original class (called the base or super or
parent class) is changed, the modified “clone” (called the
derived or inherited or sub or child class)
also reflects those changes.
|
|
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
restriction 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 sousclasse) répercutera
aussi ces changements.
|
|
|
|
|
|
|
|
|
|
(The arrow in the above UML diagram
points from the derived class to the base class. As you will see, there can be
more than one derived class.)
|
|
(La flèche dans le diagramme UML ci-dessus pointe de la classe dérivée vers
la classe de base. Comme vous le verrez, il peut y avoir plus d'une classe dérivée.)
|
|
|
|
|
|
|
|
|
|
|
|
|
