Discussion :

[backlash]

Bonjour,

Je suis à la base programmeur C++ ( qui a parlé de fosse aux Lions ), j'ai le code suivant :

B.java

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public class B
{
	public void foo (){}
}

C.java

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public interface C
{
	public void foo ();
}

A.java

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
public class A extends B implements C
{
	public static void main ( String[] argv )
	{
		System.out.println ( "Hello" );
	}
}

Le code compile et s'exécute parfaitement alors que la méthode virtuelle pure foo de l'interface C n'a pas été réimpléménté dans la classe A, n'y a t'il pas un problème ?
Les méthodes foo de B et C ont bien des signatures différentes puisqu'elle n'appartiennent à la même en classe, non ?

Comme vous pouvez le constater j'ai un raisonnement de C++iens .

[thelvin]

Le code compile et s'exécute parfaitement alors que la méthode virtuelle pure foo de l'interface C n'a pas été réimpléménté dans la classe A, n'y a t'il pas un problème ?

Non pourquoi ? S'il n'y a pas redéfinition, alors la méthode est héritée implicitement, ce qui est assez heureux quand on y réfléchit.

Mon C++ est rouillé, mais j'ai du mal à voir l'intérêt de devoir forcément redéfinir absolument toutes les méthodes virtuelles, juste parce qu'elles sont virtuelles et qu'il est possible de les redéfinir.

Pardon, j'avais mal compris.

La classe A hérite de la méthode définie par sa classe mère B, compatible avec la déclaration de l'interface C.
Il n'est donc pas nécessaire d'en redéfinir une autre.

Les méthodes foo de B et C ont bien des signatures différentes puisqu'elle n'appartiennent à la même en classe, non ?

Non, leur signature est identique. Je n'ai pas souvenir d'avoir jamais lu que la signature d'une méthode avait quoi que ce soit à avoir avec la classe ou l'interface qui la contient.

C'est aussi pour cela qu'on dit qu'implémenter ou étendre plusieurs interfaces résout le problème de l'héritage multiple en Java.
Bon, pas vraiment en réalité, mais ça permet déjà ça.

[-gma-]

Je n'ai pas souvenir d'avoir jamais lu que la signature d'une méthode avait quoi que ce soit à avoir avec la classe ou l'interface qui la contient.

En effet, signature=nom + type des paramètres (dans l'ordre bien sûr ^^)

D'ailleurs essaye de changer le type de retour de la méthode dans B (ou de réduire sa visibilité). A ne compilera plus, non pas parce que la méthode de l'interface ne sera pas définie mais parce que son type de retour (ou sa visibilité) ne seront plus compatibles avec la méthode définie dans C.

[backlash]

Mon raisonnement C++ m'empêchait de comprendre car en C++ la classe à laquelle appartient une méthode fait partie de sa signature.

[tchize_]

Pour référence, les méthode "pure virtuelle", ça n'existe pas en java. On peux ne pas définir le contenu d'un méthode

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public abstract class Machin{
     public abstract void truc();
}

Mais la présence des mots clés abstract sur la classe interdit d'instancier cette classe, et donc pas d'appel virtuel possible autorisés par le compilateur.

[backlash]

Heu, je ne suis pas sur de te suivre tchize_. Si la méthode n'a pas d'implémentation est que la classe à laquelle elle appartient est déclarée abstract, alors il n'y a aucune différence avec une méthode virtuelle pure ( C++ ).

[tchize_]

Il me semblait qu'en C++ tu peux instancier une classe qui a des méthodes virtuelles. En java on ne peux pas

Mais je suis pas expert en c++ :p

[backlash]

on peut instancier une classe avec des méthodes virtuelles mais non pure.

[thelvin]

Ok donc comme en Java, en fait.

En Java une classe qui déclare ou hérite de méthodes abstraites ou de méthodes déclarées par interface (bref, même chose que virtuelles pures,) doit impérativement être elle-même abstraite. Ce qui signifie qu'on ne peut pas l'instancier.