Discussion :

[schnito]

Salut tout le monde !

J'ai fait du java en licence il y a un an de ca, et la je decide de m'y remettre ...

Ca se passe a peu pres bien, mais alors ya un truc dont je comprenais deja pas l'interet en licence, et je comprends pas mieux maintenant ... c les interfaces ...

Dans mon cours, j'ai lu que ca pouvait remplacer l'heritage multiple impossible en java ...

Il est aussi dit ceci

Surtout, les interfaces servent à créer des comportements génériques: si plusieurs classes doivent obéir à un comportement particulier, on créé une interface décrivant ce comportement, on est la fait implémenter par les classes qui en ont besoin


Bon je veux bien.

Voici l'exemple de mon cours :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
 
public interface Animal
  {
  // tous les animaux doivent implémenter les méthodes suivantes
  void manger(String nourriture);
  void seDeplacer();
  void respirer();
  }
 
public interface Parler
  {
  // une interface plus spécifique
  void parle(int phrase);
  }
 
public interface Aboyer
  {
  void aboie();
  }
 
public class Homme implements Animal, Parler
  {
  //implémentations de l'interface Animal
  public void manger(String nourriture)
    {
    System.out.println("Miam, " +nourriture+ "!");
    }
  public void seDeplacer()
    {
    System.out.println("déplacement de l'homme");
    }
  public void respirer()
    {
    System.out.println("respiration de l'homme");
    }
 
  //implémentations de l'interface Parler
  public void parle(int phrase)
    {
    System.out.println(phrase);
    }
  }
 
public class Chien implements Animal, Aboyer
  {
  //implémentations de l'interface Animal
  public void manger(String patee)
    {
    System.out.println("Miam, " +patee+ "!");
    }
  public void seDeplacer()
    {
    System.out.println("déplacement du chien");
    }
  public void respirer()
    {
    System.out.println("respiration du chien");
    }
 
  //implémentations de l'interface Aboyer
  public void aboie()
    {
    System.out.println("Ouaf!");
    }
  }

Voila, c la que je cale pas l'interet, ya aucun heritage puisqu'on est obligé de redefinir les methodes pour chaque classe ... on enleve la classe interface, ca fait exactement le meme chose ...
Le seul petit but, c qu'on fait un regroupement des fonctions utilisées ....

Bref, si vous avez de meilleurs explications, elles sont les bienvenues, car la je pense pour le moment que j'utiliserai jamais les interfaces ...

Merci bien !

@+.

[BainE]

l'interet est que tu peux declarer une liste d'animal et stocker dedans des hommes et des chiens, vu qu'ils herites de animal

et en plus tu sais que sur ces objets tu peux appeler les methodes :

void manger(String nourriture);
void seDeplacer();
void respirer();

regarde plus profondement cette notion.
Tant que tu l'aura pas assimilé tu ne pourra pas te dire developpeur objet

[schnito]

je connais le language objet, je connais l'heritage et son but ...

mais les interfaces la, j'ai du mal a en comprendre l'interet, dans l'exemple de cours que j'ai donné, l'heritage n'au aucun but pour moi ...

[adiGuba]

Salut,


En ce qui concerne l'héritage multiple, c'est plutôt une solution alternative. En Java l'héritage multiple est interdit à cause des problèmes qu'il peut engendrer...


Sinon l'objectif des interfaces est de définir un comportement génériques (comme tu l'as dit), mais sans proposer d'implémentation spécifique. Ainsi chaque classe qui implémente l'interface peut proposer une implémentation différente en respectant le contrat initial.

On peut également utiliser les interfaces avec une classe abstraite représentant une implémentation par défaut...


Par exemple dans l'API tu as l'interface List qui définit une structure de stockage de données ordonnées, qui possède trois implémentations distinctes : Vector, ArrayList et LinkedList qui sont toutes plus ou moins basé sur la classe abtraite AbstractList...



Cela permet d'utiliser des listes quel que soit leurs implémentations :

Code :

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

1
2
3
public void method(List list) {
    ...
}

a++

[BainE]

en fait je dirais que les interfaces ont été créées pour empécher les heritage en diamant (célébre notement en C++) qui sont capable des plus beau effet de bord que j'ai jamais vu.

Une interface n'est qu'une classe abstraite pure

[adiGuba]

je connais le language objet, je connais l'heritage et son but ...

mais les interfaces la, j'ai du mal a en comprendre l'interet, dans l'exemple de cours que j'ai donné, l'heritage n'au aucun but pour moi ...

Pourtant il a un intérêt : tu peux utiliser des objets du type Animal en ignorant leurs types réels (cela peut aussi bien être Homme que Chien). Toutefois c'est vrai que ce style d'exemple n'est pas très clair... Un cas concret est nettement plus instructif je trouve...

a++

[schnito]

Un cas concret est nettement plus instructif je trouve...

ben ouais ... vous en auriez par hasard ??

[adiGuba]

ben ouais ... vous en auriez par hasard ??

ben... l'exemple avec les List en est un...

a++

[bouye]

Salut,
Sinon l'objectif des interfaces est de définir un comportement génériques (comme tu l'as dit), mais sans proposer d'implémentation spécifique.

Plus simplement un type (voir les interfaces de typage Clonable, Serialisable, etc...), puisque le comportement vient avec l'implementation. Les signatures de methodes contenues dans une interface ne sont pas suffisantes en elles-meme pour definir un comportement.

[professeur shadoko]

Toutefois c'est vrai que ce style d'exemple n'est pas très clair... Un cas concret est nettement plus instructif je trouve...

adiGuba est d'une politesse exquise: d'habitude je fulmine plus fort contre le manque d'imagination de certains pédagogues

[schnito]

Si j'ai bien compris, le but d'une interface c de dire :

les classes qui heritent se comporteront comme ca, avec tels methodes, mais je sais pas encore vraiment coment dans les details ... une sorte de planification ...

[sricard]

En effet, les interfaces ont un rôle de planification pour les classes qui les implémentent, mais cela sert aussi de sécurité.
Ainsi, X classes qui implémentent une interface Y doivent avoir les méthodes décritent dans Y (au minimum).
Cela te permet entre autre de définir des "types" de classes.

Et maintenant que j'utilise des interfaces, je m'aperçois que mon projet et beaucoup plus structuré.

[aPique]

Je suis en train de regarder le fonctionnement des threads justement dans le cas ou l'on ne desire pas heriter de la classe Thread. Ceci est possible en implementant l'interface Runnable.

Ce que j'en comprends: on ne peut creer un objet Thread à partir d'un autre objet que si ce dernier dispose d'une methode run qui realisera le traitement dans le thread et qui pourra etre appele depuis la methode start de Thread.

- On implémente la méthode run dans l'objet que l'on veut faire tourner dans un thread.
- L'on crée un objet Thread à qui l'on passe l'objet créé précédamment et qui respecte donc l'interface Runnable (la methode run).
- Comme la methode run est implementee, l'objet thread par sa methode start peut demarrer l'execution (en appelant run bien sur).

C'est le seul exemple que je connaisse qui justifie les interfaces.
Mais ..... je débute.

[Jacti]

aPique a écrit :

C'est le seul exemple que je connaisse qui justifie les interfaces.

L'interface runnable n'est pas le meilleur exemple d'interface en Java car elle ne dispose que d'une seule méthode.

L'utilité des interfaces est de séparer la spécification de l'implémentation.
Par exemple, le design pattern "façade" est, en général, une classe qui implémente l'interface d'un package.
Bien que la plupart des auteurs/formateurs/concepteurs/développeur/etc. présentent les interfaces comme une façon de faire de l'héritage multiple en Java, cette argumentaire et cette vision des interfaces sont erronnés.
En effet, si une classe peut implémenter plusieurs interfaces (alors qu'elle ne peut pas étendre plusieurs autres classes) c'est avant tout pour permettre une grande modularité des interfaces car, dans certains cas, il y a de nombreuses méthodes dans une interface (je pense, par exemple, à l'interface de certains services métier dans une architecture orientée services : SOA).
En ce qui concerne l'héritage multiple, mais c'est une autre discussion à un niveau général sur l'approche objet, il devrait être presque totalement banni. C'est en effet un faux concept car jamais personne n'a pu produire un exemple où l'héritage multiple est "inévitable". De nombreux articles existent sur le Web qui montrent que l'héritage multiple n'est jamais nécessaire (au sens de inhérent à un problème).
Perso, je pense que l'héritage multiple ne peut que semer la confusion dans une conception s'il est utilisé au plus haut niveau d'une architecture en couches. Je ne suis pas contre son utilisation très locale au niveau le plus bas. Je pourrais produire des exemples mais ils seraient assez longs.

Revenons aux interfaces.
A part le pattern runnable de Java, il y a un pattern vraiment fondamental concernant les données qui justifie impérativement l'utilisation des interfaces, c'est le pattern DAO (pour Data Access Object). Il permet de définir un contrat clair pour l'interface (le fameux CRUD pour Create, Read, Update, Delete) avec une base de données et de définir différentes implémentations (BD relationnelle, ou objet ou XML, par exemple). Avec ce pattern, les applications n'ont plus à se soucier de quel type de base de donnée est utilisée.

Jacti

[bouye]

Encore une fois : une interface (en Java) est une definition d'un type ou contrat (contract), pas d'un comportement (behavior) => pas de code , pas de comportement : le comportement/implementation c'est ce que la classe fait et comment elle se comporte, pas ce qu'on lui fait faire ni comment on l'utilise. Avec des interface, on ne fait que definir des signatures de methodes communes a toutes les implementations (qui peuvent donc avoir des comportement differents).

Une classe abstraite est un bon moyen d'avoir une base de comportement commun tout en ayant des implementations concretes plus ou moins differentes (une classe normale non-finale peut tout aussi bien faire l'affaire d'ailleurs - mais ca a ses avantages d'etre abstrait).

http://java.sun.com/docs/books/tutor...interface.html
http://java.sun.com/docs/books/tutor...aceAsType.html

Comme le dit Jacti, l'heritage multiple est a priori completement inutile et on arrive au meme resultat avec la composition et la delegation.

Sinon en cas d'anneries, je =>

[mavina]

Salut,

Je peux donner un exemple concret utilisé dans un de mes projets de DUT :
Un jeu d'Abalone.
Dans ce jeu, on avait un plateau de Billes.
Le Problèmes est qu'on ne sait pas de quelle couleur sont ces billes.
On a dont codé une interface Bille.
Cette interface Bille contenait les fonctions estBlanche(), estNoire() et estVide(), toutes les trois retournant un booleen.
Ensuite, nous avons crée les trois classes BilleNoire, BilleBlanche, CaseVide, toutes les trois implémentant l'interface Bille, et donc redéfinissant les trois fonctions sus-citées.
Ces trois fonctions dans ces trois classes ne retournent pas la même chose. estNoire() retourne true dans la classe BilleNoire, et false dans les deux autres, et ainsi de suite.
Il a ensuite suffi de créer un tableau de Bille comme ceci :

Code :

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

Bille[][] plateau;

d'une taille n et de le remplire de billes noires, blanches et cases vides.
A n'importe quel moment du jeu, il suffisait de faire, pour savoir si la bille à l'endroit (x,y) était une bille noire par exemple,

Code :

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

if (plateau[x][y].estNoire())

On voit bien là que j'appelle la fonction sur un type Bille, ca ne devrait pas fonctionner. Pourtant ici intervient le concept de polymorphisme.

Je pense que tu devrais t'orienter vers la compréhension de ce concept pour bien saisir l'interet des interfaces.

Cordialement

Fred

[herve91]

Une interface peut servir également à "unifier" des classes indépendantes les unes des autres. Par exemple, soient les classes suivantes :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class A {
  public int getColor() {...}
  public void setColor(int color) {...}
  public int getShape() {...}
  public void setShape(int shape) {...}
  // d'autres méthodes
}
 
class B {
  public int getCouleur() {...}
  public void setCouleur(int couleur) {...}
  public int getForme() {...}
  public void setForme(int forme) {...}
  // d'autres méthodes
}

Imaginons qu'un même traitement "buildColorShape()" exploitant les notions de couleur et de forme soit applicable sur des objets de type A et B. Pour une raison quelconque, A et B ne peuvent être modifiées. Comment dans ce cas éviter de dupliquer le code et écrire deux méthodes buildColorShape(), une pour A et une pour B ?
En définissant une interface qui spécifie les besoins de la méthode buildColorShape() :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
interface ColorShape {
  int getColor();
  void setColor(int color);
  int getShape();
  void setShape(int shape);
}
 
void buildColorShape(ColorShape cs) {
  int color = cs.getColor();
  int shape = cs.getShape();
  ...
}

et en l'implémentant une fois pour A et une fois pour B :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
class AColorShape implements ColorShape {
  private A a;
 
  public AColorShape(A a) {
    this.a = a;
  }
 
  public int getColor() {
    return a.getColor();
  }
 
  public void setColor(int color) {
    a.setColor(color);
  }
  ...
}
 
class BCouleurForme implements ColorShape {
  private B b;
 
  public BCouleurForme(B b) {
    this.b = b;
  }
 
  public int getColor() {
    return b.getCouleur();
  }
 
  public void setColor(int couleur) {
    b.setCouleur(couleur);
  }
  ...
}

et pour l'utilisation :

Code :

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

1
2
3
4
5
A a = new A(...);
buildColorShape(new AColorShape(a));
 
B b = new B(...);
buildColorShape(new BCouleurForme(b));

[Betatesteur]

Hello,
Si je dois vulgariser, je dirais:
L' interface dit : " Voici ce à quoi ressemblera toutes les classes qui implémenteront cette interface ". Ceci veut dire que tout code utilisant une interface particulière sait quelles méthodes peuvent être appelées pour cette interface, et c'est tout!

d'ailleurs l'exemple qu'a donné adiGuba illustre parfaitement ce concept

@++