Ce cours introduit la programmation orientée objet (encapsulation, abstration, héritage, polymorphisme) en l'illustrant en langage Java. Il présuppose connues les bases de la programmation (variables, types, boucles, fonctions, ...). Il est conçu comme la suite du cours « Initiation à la programmation (en Java) ». Comme son prédécesseur, ce cours s'appuie sur de nombreux éléments pédagogiques : vidéos sous-titrées, quizz dans et hors vidéos, exercices, devoirs notés automatiquement, notes de cours.
Encapsulation et abstraction : étude de cas
Loading...
來自 École Polytechnique Fédérale de Lausanne 的課程
Introduction à la programmation orientée objet (en Java)
146 個評分
École Polytechnique Fédérale de Lausanne
146 個評分
從本節課中
Introduction à la Programmation Orientée Objet
Cette semaine vous accueille dans le cours et vous présente les premiers concepts de base de la programmation dite « orientée objet ».
與講師見面
Jamila SamDr
School of Computer and Communication Sciences
Jean-Cédric ChappelierDr.
School of Computer and Communication Sciences
A well thought-out user interface of a class is key to a good design
of an object-oriented program.
Indeed, a poorly-designed interface that gives the user too much access
to implementation details can be just as risky as leaving data members public.
In this video we will compare two possible interfaces for a class.
In the first interface, the functionalities are too low-level
and reveal to the outside user
implementation details of the class.
While in the second interface,
only indispensable functionalities are provided.
We will see, of course, that the second option
is much better than the first one.
So we want to program a class that allows us to play
a game of tic-tac-toe. (TN: "jeu du morpion" means "tic-tac-toe")
As a reminder, it is a game for two players played on a 3 by 3 grid,
with the first player placing Os while the other player playing Xs.
The 2 players take turns and try to
get three of their pieces in a row
either across, diagonally, or vertically.
In this first version of the class "JeuMorpion",
the programmer has a minimalist vision of what
functionalities he offers to the outside world.
When he designed the class, he looked at what characteristics it had,
so he said to himself that logically he needed a grid,
then for the class functionalities, he provides the external user
a public initialization method to be
able to start with an empty grid in order to start playing.
He also provides a function
that gives access to the grid in order to place tokens
on it from outside the class,
such as red Os and blue Xs.
Let's examine more closely how the programmer
implemented this class JeuMorpion
and how he represented for example the grid.
Here, we see that he uses a one-dimensional array.
This is a possible, but perhaps not a very conventional choice.
So in this modelization, a grid is actually an object
with a reference
to a one-dimensional array.
So here, imagine for example
that we use the first 3 positions of the array for the first line,
the next 3, for the second line,
and the last 3 positions for the last line of the grid.
The method to initialize the grid
creates an array with the default
values being zeros in each slot.
So everywhere we have zeros.
The class programmer made the effort to declare the
data member "grille" private, as he should have, which means that the
external user of the class cannot directly access this field.
So if outside the class,
we declare an instance of JeuMorpion called "jeu", we will not be able
to directly access the grid with this notation.
However, he provides the method getGrille,
because the user needs to interact with this grid
in order to fill it.
For example, the user can declare
a one-dimensional array that will be the grid
he will play on,
and assign it
what is returned by getGrille, that is, a reference to
the array representing the tic-tac-toe grid.
We will see that through mechanism,
the user will be able to do manipulations
that are unwanted.
So want can the user do?
So like we said before,
he can declare and use a variable of type JeuMorpion,
and he will then use available functionalities
to manipulate this variable jeu.
Imagine that he wants
to place an O on a particular box.
One of the first things he will do
is to decide what conventions he will use to fill the grid.
For example, for him, 1 means that there is an O in that box,
and 2 means that an X is in that position, with
0 meaning the slot is empty.
If the user wants to put an O in the first position of the grid,
he will have to access the variable "grille"
through the method getGrille
and use this reference to the grid to put the right value.
So he has to know that getGrille give him access to the grid
as implemented in the class JeuMorpion,
and that the first 3 positions represent the first line of the grid
and following his conventions, he will place an O in the right place by
putting the value 1 in the first position of the array.
So the idea is we access the grid,
and we assign the value 1 to the first position.
By using these functionalities and accessing the grid,
indirectly through a method,
the user can perfectly achieve
a playable game of tic-tac-toe.
But it is his job to enforce the game's rules,
take turns with another player,
and to place the tokens at the right locations.
So if he is careful enough,
he will be able to play a real game of tic-tac-toe.
However, if we examine this setup more carefully,
we will see that this approach is fundamentally flawed.
For example the user of this class JeuMorpion
cannot use it at all without knowing the class's internal
implementation details.
He has to know under what form and with what conventions
the representation of the grid is stored, for in this case a 1D integer array with
each 3 positions representing a line.
He will also have to adopt some arbitrary conventions of his own
such as that "1" represents an "O", and "2" an "X".
The user has to know meticulous implementation details.
Furthermore, the resulting code
of the class "JeuMorpion" is completely opaque.
This line is incomprehensible like this
to anyone who reads it.
What does an "0" mean? What does a "1" mean?
This line can only be understood by looking
inside the class "JeuMorpion".
And what will happen if the class programmer
decides to change his implementation choices?
If he uses a 2-dimensional array
instead of a 1-dimensional array
(which was granted not very intuitive),
this line of code would have to be rewritten like this.
So the class user
would also have to modify his code to concord with that of the class JeuMorpion
and if he had written many similar lines,
well then he would have to revise all of them.
Lastly, a very important and serious point: the class programmer
provides an access to the
reference of the grid.
Which means that by using this functionality,
it is possible for the user
to access the reference of grille which allows him
to access the array itself and modify its contents however he wishes.
So even if the class programmer took the precaution to
declare the data member grille private,
which prevents this type of manipulation,
the exact same thing can be done, in a more indirect manner,
through the method getGrille that he chose to provide.
So accessing grille through the method getGrille
comes to the same thing as leaving grille public.
More generally, when a data member is an object,
like grille in this case,
providing an access to the object's reference via a getter
just as in this case,
comes to exactly the same thing as giving direct, public access to the data member,
because the object can be manipulated through the given reference
This unanticipated access given through the reference
to the grid can result in all kinds of disasterous consequences.
For example, the user can inadvertently enter the wrong
index for the grid and do this kind of thing.
At this point, the program would stop abruptly
and send back an error message relatively hard to decrypt.
This access can through the reference also allows the user
to enter all sorts of ficticious values in the grid.
Such as instead of putting a 1,
he puts 42 or another value,
which he can do because the value is verified intermediately.
So imagine that the user also programs
a method getJoueurGagnant that goes through the grid
to determine if there is a winner with 3 pieces in a row.
This method getJoueurGagnant expects the values 0, 1, and 2 in the grid,
and if it finds a value 42, it will not know what to do
and will behave incorrectly.
Last of all, if the user desires to cheat,
and replace an O with an X,
(a move that is normally forbidden, because once a token is placed,
it cannot be replaced),
here, again, with the access to grille via the reference,
nothing stops him from doing this dishonest move.
So all this shows that the methods provided by the programmer,
namely getGrille,
allow an uncontrollable access to the implementation details.
All these manipulations can be done without any of them
being validated, which manifests the bad class design.
To properly encapsulate the class JeuMorpion,
it is imperative that the class's implementation choices are not
revealed in the user interface provided for the user.
Furthermore, internal implementation choices
such as
how to represent the grid,
or how to modelize tokens on the grid,
are the responsibility of the class designer and programmer,
and not the user.
We will now move on to
the 2nd version that is
a bit more refined than the last version.
So to properly program this class,
several decisions need to be made in implementing the grid.
Here we choose to implement it a bit more explicitly
than in the last version
with a 2-dimensional array which is closer
to the real tic-tac-toe grid.
We have to decide how to encode the data
to place the pieces on the grid,
and here it is best to always clarify the choices we make.
For example, this can be
done by introducing a certain number of constants
with explicit names, so that the meaning of the different
numbers in the array is clear.
Next, instead of, as in the last version,
relying on the default values of the array
to initialize the grid,
here, we make the initialization as clear-cut as possible,
like this.
So in reading this code,
it is obvious that we are filling the tic-tac-toe grid
with empty boxes. (TN: "vide" means "empty")
Next, the idea is to provide the users of this class
with only 2 well-chosen methods
that allow the player to interact with the grid, without
however, knowing how it is implemented.
For example, we can provide "placerRond" (= place an "O") and specify that the user has
give the line and column
which is intuitive.
Then internally we implement
how to place an O at a given line and column on the grid.
In the same way, we can provide the public method
placerCroix (= place an "X") that allows the user to place a cross
simply by specifying
the proper line and column.
Placing a piece on a certain line and column is done
with the exact same process whether the token is an X or an O,
so it is intuitive to
modularize the procedure by having a method placerCoup (= place a token)
whose job it is to place the piece on a certain line and column.
The methods placerRond and placerCroix are sufficient
to place the tokens on the grid.
Consequently, it is unnecessary to
provide an access to placerCoup like getGrille in the first version.
Placing tokens can be done with
these 2 methods alone, which constitute the interface.
This means that the method placerCoup can be declared
private because
it simply helps the other methods in their tasks
and is not a functionality itself that is
provided to the user.
Because it is the class user who will give the line and column
where he wants to place his token,
it is necessary, in order for the class to be robust in the case of an error
to anticipate invalid moves that do not correspond to
a position on the grid.
So typically, if the line's index is negative
or greater than or equal to the grid's size,
than a message should be sent back.
So anticipating and managing these errors makes the code more robust.
Once the line and column provided by the user
are validated,
we still have to verify
that the line and column is really empty.
Indeed, in tic-tac-toe,
you are not allowed to place a token on a box
that is already occupied. If this is the case, then this
error also needs to be signaled.
placerCoup returns a boolean to indicate whether or not
a move was placed on the requested square.
The methods placerRond and placerCroix will use this boolean
returned by placerCoup and to return it
to the user to indicate if the token was placed
or not.
Let's see the repercussions of these modifications
for the user.
As before,
a programmer uses the class JeuMorpion
is to declare a variable of this type and initialize
it with the method provided
but most importantly to place a token. And to do this
he will be able to very explicitly use functionalities
like placerRond which require no knowledge
on his part of how the data is encoded internally.
So if I want to place an O, I indicate that I place an O
on the grid on the line 0 and column 0
and I will be notified if the O was successfully
placed or not.
Placing an X on the grid
would proceed in the same manner.
This 2nd version of JeuMorpion
is much more robust and explicit
but still requires that a certain number of
conventions be used.
For example here, we impose that the user of this method
respects a certain enumeration system
for the lines and columns.
We could have of course chosen a different system than this one.
So these conventions have to
explicitly be documented in the user interface.
Nevertheless, this 2nd version of the class
has many advantages compared to the 1st version.
Firstly, it verifies the data.
For instance, it is impossible in this version
to put an invalid number in the array.
And how is this?
Well, because the user of JeuMorpion
doesn't even know that an empty slot is encoded with a 0,
and that 1 and 2 represent Os and Xs.
So he simply uses the methods placerRond or placerCroix
and it's the internal implementation details that
take care of assigning the right values.
Secondly, it is impossible for the external user
to place a piece on an occupied square of the grid.
We saw in the definition of placerCoup that this method
verified that the square was indeed empty before placing a new token.
Another important advantage,
which is key to a well-designed object-oriented program,
is what is called separation of concerns:
the user of the class JeuMorpions does not need to know how
the grid is internally represented and implemented or how
a token is placed on the grid.
He only needs to concern himself with the game's logic,
and how he will place Os and Xs.
Yet another advantage is that this code is comprehensible, even
to someone without a programming background.
If, I write "jeu.placerRond(0,0)"
I don't need much explanation
to know what this expression means.
This wasn't the case in the last version where placing a piece
necessitated very cryptic expressions
like this.
Compare the two.
Do you see that this first expression
is much more clear and explicit?
And a last advantage is that all errors are
accounted for, and in these situations
a comprehensible message will be returned.
In the first version, when for example, we tried
to place a token outside of the grid, the execution of the program
was interrupted abruptly,
and a incomprehensible message was sent back.
So now it is possible with the error message for the user
to know what exactly he did wrong.
This closes our case study
of a game of tic-tac-toe.
This example demonstrated the importance of encapsulation,
how it is necessary to hide the implementation details,
and to only provide methods absolutely indespensable to the user
which do not give any openings for the user
to modify or change the implementation details.
