Discussion :

[MisterTee]

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

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

[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 :

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

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

[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 :

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

public abstract void arreter();

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

Code :

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

1
2
3
public void arreter() {
...
}

3) definir un comportement definitif :

Code :

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

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.

[MisterTee]

ok, nickel je comprend mieux.
j'ai une autre question mais je vais créer un autre topic

[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

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

[Betatesteur]

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 :

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

1
2
3
4
5
 
interface Truc {
  int i = 5;   // c'est bien un attribut!!!
  void machin();
}

[thibaut]

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+

[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++

[Betatesteur]

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

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

[adiGuba]

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

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

Pour prouver cela il y a deux solutions :

1. Les spécifications du langages :
   http://java.sun.com/docs/books/jls/t...faces.html#9.3
   

   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.

2. Tester en utilisant JNI :
   

   Code :

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

   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 :

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

   public static final int Truc.i

a++

[®om]

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

[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 )
ou de décompiler le Truc.class

@++

[Betatesteur]

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

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

[®om]

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

[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

[adiGuba]

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++

[MisterTee]

Merci adiGuBa, Merci Betatest
Merci aussi aux autres.

Je vais certainement en poser d'autres questions!!!!

[N_I_C_S]

Salut,

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.

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.