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.
Introduction
Loading...
Do curso por École Polytechnique Fédérale de Lausanne
Introduction à la programmation orientée objet (en Java)
148 classificações
École Polytechnique Fédérale de Lausanne
148 classificações
Na lição
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 ».
Conheça os instrutores
Jamila SamDr
School of Computer and Communication Sciences
Jean-Cédric ChappelierDr.
School of Computer and Communication Sciences
We will consider in this lesson
a very important aspect of programming:
object-oriented programming (OOP).
OOP is a programming paradigm or a certain style of programming
that is used in several programming
languages besides Java,
which will give a certain number
of useful features to your programs
in terms of maintenance and modularity.
At this stage of the course, you should know
the fundamental aspects
of basic programming.
For example, you know how to write code to process data
using control structures,
such as conditional loops,
You also know how to structure data
using arrays,
and, most importantly, you know how to modularize your programs
using the paramount notion of functions.
These basic tools allow you to code in a
a certain style of programming,
called procedural or imperative programming,
in which data and data processing
appear separately in the program.
But the two entities interact:
the data processing works with the data,
which influence in turn the data processing.
But the two entities appear separately.
For example, the data processing can be
represented with functions,
and the data and functions can then be linked
by the passing of arguments.
The data is expressed
by distinct entities, for example variables.
One of the fundamental particularities of OOP
is the possibility to bundle together functions and data
into one same entity.
Let's consider a concrete example.
Imagine that we would like to write a program
that works with the notion of rectangle.
A rectangle is defined by its width, and its height.
And I want to manipulate different rectangles
to calculate their area.
In procedural programming, I would proceed like this:
I declare a variable "largeur" (TN: "largeur" means "width"),
that I assign it a certain value.
And, a variable for the height,
that I would also initialize at a certain value.
Next, I could calculate the area of the rectangle
by passing its width and height to a function surface (TN : means "area"),
that would do the right calculation.
We see here
that the data and the processing of the data
are separated distinctly.
The variables allow me to represent and store my data.
And the surface function allows me to process the data.
These two entities are separated in the program.
But they are linked by the passing of arguments.
The important objection that we could make for this program,
is the lack of a semantic link
between the two entities.
For example, the semantic link between the width and height,
which are in fact the width and height of a rectangle,
is not very clear.
If I don't speak the language, I don't understand
what "largeur" and "hauteur" mean,
it would be very hard for me to see that these two data are linked
because they both refer to a rectangle.
In the same way, the semantic link between the data and functions
is hard to see.
For example, imagine that I call my function, my method
"produit" which is not very explicit, (TN: "produit" means "product")
and that I am even less explicit
in the names I choose for the arguments,
so it is very difficult to see
that I am calculating an area.
So, save for this little explanation,
the semantic link that exists between the data and the functions,
is relatively obscure in this program.
Yet this link does conceptually exist.
It is indeed the notion of rectangle that I want to manipulate
through its characteristics width and height.
And it is indeed the surface of this rectangle that I want to calculate.
So the fact of consolidating into one unit, a rectangle,
the characteristics of the rectangle,
that is its width and height ,
as well as the functions associated with it,
will allow me to establish an explicit link between these different entities.
This idea is fundamental
to object-oriented programming.
What you should know
is that OOP enables a set of
new functionalities, globally giving more
robustness, modularity, and readability to your programs.
All this allows for a better maintainability
and robustness with regard to changes to the program.
If it needs to be modified or expanded one day
we would not want to have to rewrite the whole code,
because of errors in the manipulation of data
for example.
Indeed, today most applications
are never developed from zero,
but consist of adding onto or maintaining existing code.
And it is important to be able to do this at the lowest cost.
We will see that the fundamental properties of OOP,
that is, more robustness, modularity, and readability
further this exact purpose.
OOP offers, in fact, four principal concepts:
encapsulation, abstraction, inheritance, and polymorphism
that allow for better organisation of programs
in regards to robustness, readability, modularity, and maintainability,
as I said before.
These central concepts are not exclusive to one programming language,
but are central ideas of object- oriented languages in general.
In this episode, we will
consider defining encapsulation and abstraction.
We will examine in the next episodes,
the fundamental notions of inheritance and polymorphism.
Encapsulation is consolidating
into one unit or object
the data and the functions that that work on the data.
Typically, as in the example of the rectangle,
we will regroup into one unique entitity,
the width and height that characterize the virtual rectangle
and the function that calculates its area.
In jargon, we will speak of the data as
member variables, or data members
and the functions as methods.
So in OOP,
we will be able to define new data types,
with the concept of classes.
as we will see later.
These data types can be
used to work with data
whose types are more abstract, like rectangles.
These data will be objects that will
cohabit and interact in the program.
An object-oriented program will typically work with
objects that are characterized by their members: data members and methods.
Let's examine now the concept of abstraction.
Let's say I want to write a program that manipulates
several rectangles
instead of just one.
So in a procedural approach, I would have to declare
as many widths and heights as I have rectangles.
So like this for the first rectangle.
And I would have to do exactly the same thing
for the second rectangle.
This is rather tedious!
In the case that I have 3-dimensional rectangles
that have not only a height and width,
but also a a depth,
so I would have 6 variables
to initialize!
For the area calculation for each rectangle,
I would have to invoke the area method,
and each time pass the correct arguments.
We can imagine that this quickly becomes tireseome!
This can also be a source of errors. Imagine that I mess up,
and that I calculate the area with hauteur1 and largeur2.
I loose coherence,
and don't get the right values for the area of each rectangle.
This mechanism, the encapsulation process,
results in that I manipulate
rectangles that are
all clones if the same generic representation of a rectangle,
with a width and height,
and I have a area method that applies to all of them.
As a result, I can work with higher-level data, the more abstract notion
of a rectangle.
Encapsulation will allow me to consolidate
into this virtual rectangle
everything needed to modelize it.
As a result, I will be able to work with
more abstract entities,
a first rectangle, and a second rectangle,
both of them are of type Rectangle.
And I will invoke calculations of area on these rectangles.
We will see that in object-oriented, I anticipate a little,
I calculate the area of the first rectangle.
Later on we will see all this
explicitly in more detail.
As a result, my program will focus on the important elements.
Therefore I am no longer preoccupied with the fact
that a rectangle has a width and a height,
but I can concentrate on the essential aspects:
The fact of working with a rectangle, and calculating the area of this rectangle.
So when I use a rectangle, I can only see
what we call in object-oriented jargon,
its user interface, that is, what it can do, its
functions that allow me to manipulate the rectangle,
like in our case, the calculation of the area.
Let us compare this with an everyday situation.
When you drive your car,
you normally only need to know
the user interface.
You need to know the steering wheel, the throttle,
and the brake pedal, but you never need to know
how the motor was built.
So to drive your car,
you only need to know the user interface.
This applies to OOP as well.
To use a new type of object, a new class,
you only need to know the user interface,
that is provided by the programmer of the class.
The rest is internal implementation details that you do not need to know.
So you can look at the object from two perspectives:
from an external level, which is useful for the programmer-user,
which uses the notion of rectangle in a program.
From now in a program the type Rectangle exists.
I can declare variables of type Rectangle,
and initialize them appropriately.
Next, that which interests me as a programmer-user,
are the useful functions that come with the class: the calculation of area.
So this external view is the perspective that interests the programmer-user
and that uses the type Rectangle
The second perspective is the internal. The programmer of the new type,
the Rectangle type, had to deal with all the details of implementation.
That is, that a rectangle has a length and width.
He had to define explicitly how the area is calculated.
This constitutes the implementation
at an internal level, which not necessarily useful
for the user of this type.
So in object-oriented programming, we do not only have the possibility to regroup
into one same entity the data and functions,
but we can also define levels of visibility.
The person who programs the type Rectangle,
specifically the class Rectangle,
will be able to say : " This is an implementation detail
that will not be accessible to external users."
and "This is a function that we want to provide for the external user
and therefore will be accessible to this user."
Everything accessible to the user and, therefore, visible
constitutes what is called the user interface
of the class of the type in question.
Here, in our class Rectangle, for the new type Rectangle
we have defined as user interface
the calculation of the surface, the rest constituting the
implementation details that are inaccessible to the user of the type Rectangle.
Here we have the key that gives
the program more robustness if they changes are made to them.
Usually, when you change car
even if the motor technology is different,
the interface is more or less the same.
You will still be able to drive,
even if the internal details of implementation of your car
have changed.
So you only see your car as an abstract object.
You only see that
which you use to drive,
namely, the steering wheel, the throttle, the break peddle.
In summary, encapsulation,
is consolidating into one same entity
the data and functions that characterize it.
And it is also the fact of concealing the implementation details,
and defining a user interface of the class
with the encapsulation mechanism,
that will result in abstraction,
and an abstract perspective of the object.
We will only what the object has to offer in its user interface,
and what manipulations are possible.
So concretely the class programmer will decide
on the existence of a new type,
and will have to address the implementation details.
He will have to decide what is visible to the outside world,
what can and cannot be used.
The class user, on his side, uses
the new data type.
But he will have to use it through the interface.
That is to say, its visible methods
in most cases.
He will not have access to the internal details.
The user interface is typically, that which will enable
a link to be established between the program developer and the user.
And in a very specific way
this interface will be able to be completely described by the labels
of the methods available to the user.
So one of the principal advantages of abstracting and encapsulating
is to give better visiblity and coherence of the program.
Compare a procedural approach where I manipulate very low-level data,
with the object-oriented approach
which you will soon be able to code yourself.
here I expressly manipulate a rectangle,
as opposed to here, where
this notion isn't clear.
I establish the semantic link between the rectangle and the area,
while here, this link is established very indirectly.
So, the first advantage is more clarity, better coherence.
Also, in this case, because the class user
can only use the notion of rectangle
through the user interface
provided by the class programmer,
it is possible for the class programmer
to modify the class implementation
without impacting the user.
If the class programmer
decides to change how he first implemented Rectangle,
that represented the height and width
with two doubles,
and decides to use instead
an array,
then he simply needs to adapt the method to calculate the area
to this new data structure, and the user
will not be affected at all.
Separating in two, the internal level:
the implementation details, and the external user interface
assures more rigorous usage framework.
Any modification to the internal structure
are invisible externally.
A rule generally respected
by most object-oriented programmers follows from this.
Data members require technical choices to be made
so that they can be used in the implementation,
like choosing their type.
They will therefore be considered in most cases as implementation details,
and will not be accessible
from outside the class.
In summary, in order to define a new type of object
with a class, we will have to define its characteristic attributes or data members
as well as the methods that go with it.
And we will have to determine concretely what will be visible
in the user interface
and what is not: the implemenation details.
So once we have decided what to hide,
the external user will only have an abstract view
of this object
through the user interface,
and will only see that with a rectangle, you can calculate its area.
And if I want to follow good OOP rules,
I will consider that the data members are also implementation details,
like I said before.
Thus the interface will be limited to a certain number of well-chosen methods.
The external user's vision of the object
will be restricted to the user interface.
What to remember from today's episode:
abstraction results in what is called a class,
which allows me to define a category of objects.
A class will define a new type in a program.
I now have the type Rectangle that I can manipulate in a program like this:
I can declare variables of this type,
which are actual realizations of this type. So the declaration of a variable
of this type, is what is called in object-oriented jargon, an object.
It is generally manipulated with a variable.
To summarize and illustrate these remarks
the person who writes the class Rectangle conceptually
creates a new type.
He will do this of course by writing a program
that contains the code of the class Rectangle.
The user of this class will use the new type,
by declaring variables of type Rectangle
that will only come into real existence
at the execution of the program.
So the moment the new objects of this type are created,
we will be able to start working
with these objects in the program.
So the user will work with specific concretizations
of objects of class Rectangle.
We've come to the end of this presentation
of two fundamental aspects of object-oriented programming :
encapsulation and abstraction.
You will, in the next episodes,
start to put in practice these concepts in Java.
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
