Introduction

Loading...

En provenance du cours de École Polytechnique Fédérale de Lausanne

Introduction à la programmation orientée objet (en Java)

169 notes

Explore Related Videos

At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you

École Polytechnique Fédérale de Lausanne

Introduction à la programmation orientée objet (en Java)

169 notes

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.

À partir de la leçon

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 ».

Introduction20:03

Classes, objets, attributs et méthodes en Java14:01

public et private19:27

Encapsulation et abstraction : résumé6:17

Encapsulation et abstraction : étude de cas18:37

Rencontrer les enseignants

Jamila Sam
Dr
School of Computer and Communication Sciences
Jean-Cédric Chappelier
Dr.
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.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2019 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play