Interfaces

Loading...

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

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

135 notes

École Polytechnique Fédérale de Lausanne

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

135 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

Le modificateur static ; Interfaces

Cette semaine nous abordons la notion importante d'interface qui va complémenter vos acquis sur l'orienté objet en Java. Nous étudions aussi le modificateur static.

Attributs statiques13:21

Méthodes statiques9:22

Interfaces16:38

Les interfaces depuis Java 822:05

Rencontrer les enseignants

Jamila Sam
Dr
School of Computer and Communication Sciences
Jean-Cédric Chappelier
Dr.
School of Computer and Communication Sciences

In this episode and the following one,

we'll see a new concept:

Java interfaces.

But first, let's begin with an example, with another game

that would for example need balls,

rackets, nets, and players.

And let's suppose that each of these entities

needs an 'evolue' (= "evolves") method, to make them evolve during the game.

Naturally, the way of conceiving this

in object-oriented programming

would be to create an abstract class 'Entite' (= "Entity")

which would have the abstract method 'evolue',

and to make the ball, the rackets, the net, the player

inherit from the abstract class 'Entite'.

But let's suppose that we go a bit further

in the game's analysis,

and that we realize that some of these entities,

for example the balls, the rackets, the nets,

should have a graphical representation such

that we effectively do see them on the game's screen,

and that, for example, we don't see the player.

So at that moment we would have to dissociate

the players from the balls, the rackets, and the nets,

as having or not a graphical representation.

We could also imagine that some entities

should be interactive,

for example to be able to control them

with the keyboard or with the mouse,

like a ball or a racket.

And others that we couldn't move,

so for example the net and the player.

So how would we organize all this

in the context of our object- oriented conception?

Ideally we would do all this through classes

with, for example, an interactive class

which would allow us to manage the ball and the racket

in an interactive way.

A class that would allow us to have a method

to graphically draw the graphical objects

of which would inherit net, racket and ball.

But this would make what is called multiple inheritance.

The ball would inherit in multiple ways

from an interactive and graphical entity.

But we can't have multiple inheritance in Java;

there's only single inheritance in Java.

So how do we do?

Before answering that question, let's simply note

that some other programming languages

have chosen multiple inheritance,

so why isn't there multiple inheritance in Java?

Simply because multiple inheritance

may induce confusion,

and make some situations difficult to understand.

For example if we had a class that multiply inherits of an animal,

is it an animal? The same animal?

Or is it two animals?

And these situations are also difficult for the compiler,

which has decisions to take.

Those that would want to convince themselves could go and see

the episode on virtual classes in C++,

on our other MOOC that is taking place in parallel

on the C++ language, and you'll most certainly be convinced.

Another reason is that there can be ambiguity

when a method or a variable is declared

in many super-classes.

Which one to use? How to access it?

So, for good reasons, Java decided

not to have multiple inheritance.

So, how can we well design the game

that we've imagined until now in Java?

For that, let's go back to the reason that pushed

us to introducing multiple inheritance.

Why did we want multiple inheritance in our video game?

To impose the use of common methods to

some classes.

So for example, we wanted 'ball' and 'racket'

to have methods that allow you to manage a mouse click, for example.

But the 'gestionClic' (= "clickManager") method

can't be a method for their super-class,

common to all for the 'Entite' class,

because a 'gestionClic' method makes no sense for the player for example.

What we want to do is to impose a common content to some sub-classes,

without any inheritance relation,

and differentiate them from other sub-classes.

That's the notion of

interface in Java.

The interface notion in Java,

which is different from the notion of class,

will allow us to impose to some classes

to have a particular content,

without them being part of a class, properly speaking.

So for example, here, the sub-classes 'Raquette' and 'Balle',

sub-classes of the 'Entite' class,

will additionally have, for example,

the 'Interaction' or 'Interactive' interface,

which gives the ability to manage, for example, mouse interactions.

Of course, it wouldn't have been correct

to have this 'gestionClic' method in the 'Entite' class,

because in that case, the net and the player

would also have had a 'gestionClic' method,

of which they doesn't have any use.

The 'balle', 'raquette' and 'filet' (= "net") sub-classes of the 'Entite' class

will also have an interface

that oblige them to make a choice, from a graphical point of view.

So that's it concerning the interface concept.

Now that you have an idea of the utility of interfaces,

let's see what they concretely look like in Java.

Before going on about interfaces,

we shall add an important remark.

Interfaces up to Java 7,

as you'll see it in the coming slide,

can contain only constant variables,

and abstract methods.

However, many new features have been added in Java 8.

In the following slides, we will mainly present interfaces

as they were till Java 7.

The new Java 8 features will be presented in another video.

In Java, an interface is declared a bit like a class,

with the difference that we'll replace

reserved word 'class' with the reserved word 'interface'

followed by the interface's name, freely chosen,

then a pair of opening and closing curly braces,

like the body of a class.

Unlike a class, an interface can only contain

abstract methods, which is the most common case,

or also constants.

This is how the code of interfaces from the small introductory example

could look like.

Here you'll wonder why

the methods defined inside the interfaces

are defined without the reserved word 'abstract',

when we've just seen that an interface

can only contain abstract methods.

We'll come back to this later.

As a reminder, the idea was that these interfaces

impose a certain content to the classes

to which they are related to.

And here the imposed content was typically

a number of methods.

An interface, that can only contain abstract methods,

can't contain any constructors.

It is therefore impossible to create an interface instance.

So for example here, I can't write something like

this in a program, which

is to declare a graphical object

and try to instantiate it this way.

This is obviously impossible.

But let's go back to the question in which we were concerned before:

why are we here exempt from

explicitly putting the reserved word 'abstract', for example?

As the methods of an interface are necessarily abstract,

java exempts you from explicitly mentioning it.

What you must know

is that any method declared in an interface

is necessarily abstract and necessarily public.

If you try declaring an interface method

with another modifier than 'public',

you'll get a compiler error message.

It is also possible to put constants in an

interface, even if that's less common

than abstract methods.

For example, I could define an interface like this

that contains constants.

And in this case, I need to give values to the constants,

as there's no eventual constructor

that could give initial values to these constants.

I must do it at this stage,

and like the methods,

there are also implicit modifiers for the constants.

Every constant that you put in an interface

is necessarily public, final,

and static.

We now know what we can put

inside an interface.

Let's look at how to establish the link

between the interface and the class.

This link is established with a particular reserved word:

the reserved word 'implements'.

When we declare the class,

we'll indicate that this class implements a number of interfaces.

There can be many, separated by commas.

For example, to indicate that our net class

extends the class Entite,

but implements the Graphique interface,

which will let us see this net as a draw-able object,

we'll write, in Java, the class 'Filet' (= net) extends the class 'Entite' (= entity),

and implements the 'Graphique' (= Graphical) interface.

When a class implements a number of interfaces,

It is imperative, if we want it to be instanciable,

that is redefines all the methods

declared in the interfaces.

All the abstract methods

must be concretely redefined in the class that implements them,

so that these are instanciable.

This is the way that an interface imposes a content

to a class that implements it.

The moment we establish the link between the class and the interface,

so the class, if we want to instantiate it,

must redefine all the methods specified in the interface.

So as we've seen,

a class can perfectly implement

many interfaces, for example,

the ball is a clickable object and is a draw-able object,

so it implements two interfaces.

The Interactive interface and the Graphique interface.

If we want to create basic instances,

which is probably the case,

then the Balle class must imperatively

give a concrete definition of the 'gestionClic'

and 'dessiner' (= draw) methods.

Note that in Java, it is totally possible

to declare a hierarchy of interfaces.

We'll say that an interface extends another

and this is expressed with the reserved word 'extends',

like with the classes.

For example, here we have two interfaces

GerableParSouris (= manageable with the mouse) and GerableParClavier (= manageable with the keyboard),

which both extend an Interactive super-interface.

Here we indeed have a hierarchy of interfaces

and two interactive super-interfaces,

and two sub-interfaces GerableParSouris

and by keyboard.

Before continuing,

let's go back to our first example of a class implementing an interface,

to mention a point that can have its importance.

We previously saw that, in an interface,

the methods are de facto public.

What happens if a class that implements an interface

defines the method present in the interface

but with rights different that the public right?

So imagine for example that here

I put the access right 'protected'.

Well this will simply be refused by the compiler

because in Java, when you redefine an existing method,

you are allowed to enlarge the rights,

but never restrict them.

Note that this is also valid

for the redefinition in the context of inheritance.

For example, if I have a super-class A

of which inherits a sub-class 'B',

if A defines a method m as 'public',

then the method's redefinition

can't restrict the rights.

This will be refused.

By declaring an interface in a Java program,

you in fact declare a new type,

as it is the case when you declare a new class.

It is therefore possible to declare

a variable of 'interface' type

like this, for example,

and to affect an object to it. But be careful, not any object:

the object of a class that implements this interface.

This is the case here,

so we affect to a variable of type Graphique,

an object

initially instantiated as a Balle.

So that it is possible, the 'Balle' class must

obviously implement

the 'Graphique' interface.

In some situations, it can be interesting

to manipulate the objects through their interface

rather than through their initial type.

For example here, rather manipulate a ball

as a graphical object, and in this case,

it justifies this kind of assignment.

Last small note:

knowing that we can perfectly assign

an object of a sub-class type to a variable of super-class type,

this variable containing an object of 'Balle' type,

which implements the 'Graphique' interface.

Is it possible to assign this variable

to an object of 'Graphique' type?

So, this is possible, but with a condition.

You must here reassure your compiler

on the fact of what is contained in the variable

is indeed an object that implements the interface

in question, the 'Graphique' interface.

To do so, we use type conversion,

casting, here.

To summarize, the essential function of an interface

is to attribute common components

to classes that aren't linked with an inheritance relation.

In our example, the 'Interactif' interface

allowed us here to impose

a common content, a 'gestionClic' method,

to two classes, Balle and Raquette for example,

which aren't related by an inheritance relation.

We don't have 'Balle' inheriting from 'Raquette' or vice versa.

An interface can have constants,

that is, final, static, public variables.

That's quite rare and requires some discipline.

Why? Because there can be

a possible ambiguity, if, for example, a class

implements two interfaces that each contain the same constant.

Suppose for example that in a program,

we have a first interface 'l1'

that contains the definition of a constant,

and a second interface 'l2'

that would contain a constant of the same name.

With possibly another value, but not necessarily.

Now, if we want to declare a class C

that implements the two interfaces,

then there is clearly a problem, an ambiguity:

which of the two constants do we want to use?

This will be refused by the compiler.

Another possible component of an interface,

and the most common one: the abstract methods.

And here we saw that every class

that implements the interface, if it wants to be instantiated,

must provide a concrete definition of the method,

otherwise it can't be instantiated.

The interface therefore allow to

impose to some classes to provide a certain content without necessarily

using the notion of class and abstract method.

Contrary to the case of variables,

as the abstract methods don't have any instruction lines,

there isn't any possible ambiguity, for example,

if in the 'l1' interface

there's an abstract method m, and in another

interface 'l2' there's also

an abstract method 'm', then a class 'C'

can perfectly implement the two interfaces

without making the compiler react.

If it wants to be instantiated,

the 'C' class must, indeed, provide a definition of the 'm' method,

no matter what imposes its presence.

Note that the Java API

provides many predefined interfaces, for example,

the 'comparable' interface

imposes to the classes that implement it to provide a 'compareTo' method,

that takes an object of Object type as an argument.

To conclude, let's look at what relation types

set up an interface.

Typically, we saw that

inheritance allows us to use an "is-a" relation type.

A ball "is an" entity of the game.

We also saw that when a class

has as an object of another class as an attribute,

then a "has-a" relation type is established

between the two classes: a warrior has a weapon.

Finally, an interface lets us be reassured

that a class conforms to a certain protocol,

and we'll say that the relation that is set up

is a relation of type:

"behaves-as": a ball 'is-a' game entity,

but it behaves like

a graphical object and an interactive object.

And this concludes our episode about Java interfaces.

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.

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

Télécharger dans l'App Store

Disponible sur Google Play