Abstract et Interface

Version imprimable

03/10/2006, 01h12
MisterTee

Abstract et Interface

Bonsoir à tous,

j'ai lu les tutos mais j'arrive tjs pas à bien cerner la différence entre abstract et interfaces, lequel choisir??? lequel est le mieux....

Merci à vous:)
03/10/2006, 02h26
bouye

=> voir ici : http://www.developpez.net/forums/sho...95&postcount=3

Si tu as deja fait du C++, une interface est l'equivalent d'une classe virtuelle pure, et une classe abstraite d'une classe virtuelle.
03/10/2006, 02h45
MisterTee
donc si je comprend bien,

mon type définit par l'interface sera customisé par les classes qui vont l'implémenter?
exemple si j'ai
Code:

1 2 3 4 5 interface véhicule{ public demarrer(); public arreter(); }
et que j'ai deux classe
voitureMoteur et voitureAeau
ils vonts implémenter demarrer() et arreter() mais en définissant un comportement différent c'est ça?

et abstract alors? je pige pas, je m'enmêle un peu là.

lmerci de votre aide
03/10/2006, 03h08
bouye
oui les methodes peuvent etre totalement differentes et sans rapport entre elles.

Avec une classe abstraite, tu peux :

1) ne pas definir de comportement :

Code:

public abstract void arreter();

2) definir un comportement generique et modifiable (surchargeable) :
Code:

1 2 3 public void arreter() { ... }
3) definir un comportement definitif :
Code:

1 2 3 public final void arreter() { ... }
N'oublie pas que tu peux aussi definir des methodes protected, package protected et private qui en plus des methodes publiques peuvent servir a definir un comportement plus commun a toutes les sous-classes.

Evidement la difference est peu flagrante sur une classe a deux methodes. Regarde du cote des actions (Action et AbstractAction) Swing. Tu peux soit :
- definir tes propres Action avec ta propre implementation completement differente de celle de AbstractAction.
- reutiliser AbstractAction telleq uelle dans une classe fille (apres tout y a pas des masses de methode abstract dans cette classe - mais c'est la un cas particulier)
- surcharger les methodes de AbstractAction pour reutiliser le comportement pre-existant mais ne le modifiant a ta sauce.

Sinon tu peux aussi voir du cote de ItemSelectable (utilisee a la fois par AsbractButton et JCheckBox par exemple) et de AbstractButton (et de ses differentes classes filles).
Le comportement commun entre tous les types de boutons est introduit par AbstractButton, tandis que ItemSelectable indique juste qu'on peut rajouter des listeners (mais ne specifie rien sur leur stockage (puisqu'il n'y a pas de code) donc chaque implementation doit faire a sa sauce).

Evidement on introduit aussi un type quand on utilise une classe abstraite, oui mais voila, il n'y a pas d'heritage multiple en Java. D'ou la necessite des interface, pour heriter de plusieurs types a la fois.
03/10/2006, 03h14
MisterTee

ok, nickel je comprend mieux.
j'ai une autre question mais je vais créer un autre topic
11/10/2006, 02h22
MisterTee

désolé de réouvrir ce topic mais je voulais pas en créér un autre vu que ça en rapport avec ma question.

Comment prouver que les champs d'une interface sont implicitement static et final?

Merci de votre aide
11/10/2006, 06h29
N_I_C_S

Salut,

Il me semble qu'il y a une difference conceptuelle importante entre les 2 (mais comme toujours, tout n'est que sémantique...). selon moi :

- La classe abstraite définit une généralisation de comportements par rapport à des type déjà existant, par ex :

Objets : jeep, bus, quad, voiture, ...

Comportements abstraits : avancer, tourner, etc...

- L'interface définit des comportements avant l'existence des objets y faisant référence. Ex :

Interface :
- Ouvrir();
- Fermer();

Objets :
- portes
- bouches
- gaz
- femmes etc...

Cette difference est causée par la capacité des classes abstraites à posséder des attributs, et par le fait qu'une classe quelconque puisse implémenter plusieurs Interfaces.

Donc, pour répondre à la question, une interface n'a pas d'attributs, ni static, ni final, c'est le domaine des classes abstraites.
11/10/2006, 07h19
Betatesteur
Citation:

Envoyé par N_I_C_S

Salut,

Il me semble qu'il y a une difference conceptuelle importante entre les 2 (mais comme toujours, tout n'est que sémantique...). selon moi :

- La classe abstraite définit une généralisation de comportements par rapport à des type déjà existant, par ex :

Objets : jeep, bus, quad, voiture, ...

Comportements abstraits : avancer, tourner, etc...

- L'interface définit des comportements avant l'existence des objets y faisant référence. Ex :

Interface :
- Ouvrir();
- Fermer();

Objets :
- portes
- bouches
- gaz
- femmes etc...

Cette difference est causée par la capacité des classes abstraites à posséder des attributs, et par le fait qu'une classe quelconque puisse implémenter plusieurs Interfaces.

Donc, pour répondre à la question, une interface n'a pas d'attributs, ni static, ni final, c'est le domaine des classes abstraites.

Désolé mais tu confonds beaucoup de choses!!!!
je vais aller pas à pas.....
d'abord.....
1. Depuis quand une interface ne peux pas avoir d'attributs?
tu peux bien faire
Code:

1 2 3 4 5 interface Truc { int i = 5; // c'est bien un attribut!!! void machin(); }
11/10/2006, 09h31
thibaut

Citation:

Envoyé par N_I_C_S

Salut,

Il me semble qu'il y a une difference conceptuelle importante entre les 2 (mais comme toujours, tout n'est que sémantique...). selon moi :

- La classe abstraite définit une généralisation de comportements par rapport à des type déjà existant, par ex :

Objets : jeep, bus, quad, voiture, ...

Comportements abstraits : avancer, tourner, etc...

- L'interface définit des comportements avant l'existence des objets y faisant référence. Ex :

Interface :
- Ouvrir();
- Fermer();

Objets :
- portes
- bouches
- gaz
- femmes etc...

Cette difference est causée par la capacité des classes abstraites à posséder des attributs, et par le fait qu'une classe quelconque puisse implémenter plusieurs Interfaces.

Donc, pour répondre à la question, une interface n'a pas d'attributs, ni static, ni final, c'est le domaine des classes abstraites.

En fait au niveau conceptuel il n'y a pas grande différence entre classe abstraite et une interface. Dans les deux cas ça te permet de définir des comportement sans les implémenter.

Un classe abstraite est pour moi à mi-chemin entre une interface et une classe concréte: en effet tu peux à la fois définir le comoportement de méthodes et l'implémentation d'autres méthodes.

En fait une interface est utile quand tu ne peux impléménter aucune des méthodes de la classe.

Une classe abstraite par contre est utilisée quand tu peux implémenter quelques méthodes mais pas toutes.

Alors la plupart du temps tu définis une interface Vehicule par exemple, qui est ilmplémentée pas une classe abstraite DeuxRoues qui est elle même implémentée par une classe concréte Moto.

A+
11/10/2006, 09h38
adiGuba

Salut,

Une interface définit un comportement, sans imposer ni proposer d'implémentation. Elle défini donc ce que devront faire les classes qui l'implémente, mais pas comment elle devront le faire.

Comme l'a décrit bouye, une classe abstraite quand à elle peut proposer une implémentation particulière, imposer sa propre implémentation (méthode final), ou proposer des méthodes utilitaires destiné aux classes filles. Elle permettent de définir des comportements par défaut...

Par exemple l'interface List décrit toutes les méthodes pour gérer une liste d'objet, la classe AbstractList propose donc une implémentation pour la plupart de ces méthodes, et te permet donc de simplifier l'écriture de tel classe. Ainsi les classes ArrayList et LinkedList se contente d'implémenter les méthodes "absentes" et/ou de réimplémenter certaines méthodes...

Quand aux interfaces, elles ne peuvent pas avoir d'attributs en tant que tels, mais seulement des constantes static final (qui est implicite s'il est absent).

a++
11/10/2006, 09h44
Betatesteur

Citation:

Envoyé par adiGuba

Quand aux interfaces, elles ne peuvent pas avoir d'attributs en tant que tels, mais seulement des constantes static final (qui est implicite s'il est absent).

Tu l'as bien dit et je pense qu'il a compris tous ces exposés. Mais regardez bien ça question

Citation:

Comment prouver que les champs d'une interface sont implicitement static et final?

Citation:

Envoyé par Betatesteur

Tu l'as bien dit et je pense qu'il a compris tous ces exposés. Mais regardez bien ça question

Citation:

Comment prouver que les champs d'une interface sont implicitement static et final?

Oui en effet j'ai répondu par rapport à la remaque qui suivait :oops:

Pour prouver cela il y a deux solutions :
Les spécifications du langages :
http://java.sun.com/docs/books/jls/t...faces.html#9.3

Citation:

Every field declaration in the body of an interface is implicitly public, static, and final. It is permitted to redundantly specify any or all of these modifiers for such fields.
Tester en utilisant JNI :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 interface Truc { int i = 5; // c'est un attribut public static final!!! void machin(); } public class Main { public static void main(String[] args) throws Exception { // boucle foreach Java 5.0, a adapter pour du JDK 1.4 ou inférieur for (Field field : Truc.class.getDeclaredFields()) { System.out.println(field); } } }
Ce qui nous donne bien le résultat suivant :

Code:

public static final int Truc.i
a++

11/10/2006, 10h06
®om

Citation:

Envoyé par MisterTee

désolé de réouvrir ce topic mais je voulais pas en créér un autre vu que ça en rapport avec ma question.

Comment prouver que les champs d'une interface sont implicitement static et final?

Merci de votre aide

Le fait que cela soit implicite est une décision arbitraire, donc pas tellement prouvable...

On peut simplement montrer que cette décision a été prise...

Tu fais une interface où tu définis un attribut int i; sans lui attribuer de valeur, le compilo ne veut pas compiler car i n'a pas de valeur => c'est implicitement final.
Pour statique, c'est simplement que tu peux appeler MonInterface.i...
Pour public, c'est que tu peux faire ça depuis un autre package, sans relation d'implémentation...
11/10/2006, 10h08
Betatesteur

en utilisant javap j'ai aussi le même résultat. donc en conclusion , le seul moyen de prouver est d'utiliser ta méthode (adiGuba) ( que je connaissais pas d'ailleurs :mouarf: )
ou de décompiler le Truc.class

@++
11/10/2006, 10h10
Betatesteur

Citation:

Envoyé par ®om

Le fait que cela soit implicite est une décision arbitraire.

chui pas d'accord. tu peux me dire pourquoi ça serait arbitraire?
11/10/2006, 10h14
®om

Citation:

Envoyé par Betatesteur

chui pas d'accord. tu peux me dire pourquoi ça serait arbitraire?

Bah, les gens de sun auraient pu interdire tout attribut non déclaré public static final...
Ils l'ont autorisé, en disant que c'était implicitement public static final...
11/10/2006, 10h27
Betatesteur

la raison serait ( selon moi) plus tôt : Comme on ne peut placer aucun code dans les corps des méthodes, toutes les variables avouées dans une interface doivent être des champs globaux à la classe...

ça parait plus juste comme explication je pense
11/10/2006, 10h57
adiGuba
Citation:

Envoyé par Betatesteur

la raison serait ( selon moi) plus tôt : Comme on ne peut placer aucun code dans les corps des méthodes, toutes les variables avouées dans une interface doivent être des champs globaux à la classe...

ça parait plus juste comme explication je pense

En effet ! D'ailleurs on retrouve la même chose dans plusieurs autres cas :
- Les méthodes d'une interface sont implicitement public abstract.
- Une enum est implicitement final. De plus elle est implicitement static lorsqu'elle est déclaré à l'intérieur d'une autre classe.
- Les valeurs d'une enum sont implicitement des constantes public static final du type de l'enum.
- Les constructeurs d'une enum sont implicitement private.
Ne pas respecter (avec un mot-clef contraire par exemple) provoquera des erreurs de compilation...

Ces "restrictions" ont toutes une raison valable (plonger dans les spec pour plus de détail) et il n'y a généralement aucune raison de vouloir passer outre...

a++
12/10/2006, 18h49
MisterTee

Merci adiGuBa, Merci Betatest
Merci aussi aux autres.

Je vais certainement en poser d'autres questions!!!!:)
25/10/2006, 15h05
N_I_C_S

Salut,

Citation:

Envoyé par Betatesteur

Désolé mais tu confonds beaucoup de choses!!!!
je vais aller pas à pas.....
d'abord.....
1. Depuis quand une interface ne peux pas avoir d'attributs?

C'est vrai, c'était un peu outrancier mais il me semble que ce n'est pas le "rôle" des interfaces d'avoir des attributs. d'ailleurs, dans une conception objet structurée (soit dans l'API java, ou dans les sources de gros projets comme JBoss) je n'ai jamais vu d'interface ayant des attributs ! L'interface est là pour décrire un comportement sans l'implémenter, avoir des attributs est déjà le début d'une implémentation.

Citation:

Envoyé par thibaut

En fait au niveau conceptuel il n'y a pas grande différence entre classe abstraite et une interface. Dans les deux cas ça te permet de définir des comportement sans les implémenter.

Je ne suis pas d'accord, la différence fondamentale est qu'une classe lambda ne peut hériter que d'une seule classe abstraite mais peut implémenter toutes les interfaces voulues. Ce mécanisme ne peut exister, justement, que par l'absence totale d'implémentation.
Par exemple, imaginons une interface A. Deux interfaces B et C héritent de A.
Une classe L implémente B et C.
Si, dans l'interface A on définit "int x;" Dans l'interface B : x=5, dans l'interface C : x=6.
Quid de la classe L? De quel valeur va-t'elle hériter ?
C'est pour éviter au maximum ce genre de conflit que les interfaces java existent.
25/10/2006, 15h16
thibaut

Alors moi je vois plutôt ça comme une conséquence de l'existance des interfaces que comme une cause...
25/10/2006, 15h46
N_I_C_S

Je ne crois pas, ce concept d'interface est, certes, un choix purement arbitraire des concepteurs de Java. néanmoins je ne crois pas qu'on "subisse" cet etat de fait. Je pense qu'un enseignement a été tiré de la pratique de C++ en particulier (langage objet mais tradition séquentielle) pour coller au plus près des pratiques objet. Cette idée d'interface nourrit la méthode plus qu'elle ne la subit.