Discussion :

[Chatbour]

Salut à tous et à toutes

je suis débutant en java, et j'ai récemment fait face à la notion d'interface : j'ai compris que c'est une "classe particulière" dont tous les membres sont static final, et les méthodes sont abstract..

ma question : quand on fait face à un cas comme celui-ci :

Code :

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

1
2
3
4
abstract class maClasse{
    final static int i=1;
    abstract void afficher();
}

c'est à dire que maClasse peut être remplacée par une interface, on opte pour une classe abstraite ou une interface ?

Merci d'avance

[mavina]

Salut,

L'un des intérêts d'une classe abstraite (corrigez moi si je me trompe) est d'éviter la duplication de code dans les classes filles.
Ici, tu n'as "pas besoin" d'une classe abstraite(sauf si afficher() fait la même chose dans toutes les classes filles) .

Je pense que tu peux passer à une interface.

Fred

[Chatbour]

merci pour la réponse

L'un des intérêts d'une classe abstraite (corrigez moi si je me trompe) est d'éviter la duplication de code dans les classes filles.

je pense que c'est l'avantage de l'héritage en général.. les classes abstraites servent (à mon avis bien sûr) à imposer l'implémentation de méthodes dans des classes dérivées..

[mavina]

Oui, donc ici tu n'as pas besoin d'une classe abstraite si afficher() fait des choses différentes.

Fred

edit:quel était l'objet du doute au passage ? Parceque tu n'as pas l'air de douter en fait

[adiGuba]

Salut,

Et pourquoi pas les deux !!!

Perso j'ai bien le principe des 3 niveaux :

• Une interface qui définit le contrat général sans préciser d'implémentation.
• Une ou plusieurs classes abstraites qui implémentent l'interface et propose une implémentation spécifique "partielle".
• Et enfin les classes concrètes qui seront réellement utilisées, et qui hérite des classes abstraites...

On retrouve ce principe dans l'API de Collections (par exemple : List -> AbstractList -> ArrayList).

L'un des intérêts d'une classe abstraite (corrigez moi si je me trompe) est d'éviter la duplication de code dans les classes filles.

Il y a aussi la possibilité d'y définir des méthodes protected/package-only : toutes les éléments d'une interface sont implicitement public


a++

[Amine_sas]

Salut à tous et à toutes

je suis débutant en java, et j'ai récemment fait face à la notion d'interface : j'ai compris que c'est une "classe particulière" dont tous les membres sont static final, et les méthodes sont abstract..

Toutes les methodes d'une interface sont effectivement sans corps.
Tu utilises une interface pour obliger les classes qui l'implémentent de redéfinir toutes ses méthodes sinon le compilateur signale une erreur.
Par exemple la méthode sort de la classe Arrays accpete un tableau d'objets d'une classe qui implemente l'interface Comparable et doit par conséquent redéfinir la méthode compareTo.
Exemple:

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
 
class Person implements Comparable
{
  ....
  private int id;
 
 public Person(int id, String name){
  ....
}
 
/* Si on veut que les objets Person soient trié par id on definit la methode
compareTo ainisi : */
 
public int compareTo(Object o){
 
  Person otherPerson  =  (Person) o;
if (this.id ==  otherPerson.id ) return 0;
if (this.id >  otherPerson.id ) return 1;
(this.id <  otherPerson.id ) return -1;
 
// ou tout simplement return (this.id - other.id);
 
}
 
...
 
}

La méthode sort sait qu'une classe implémentant l'interface Comparable avait forcement redéfinit compareTo et elle se contente de l'appeler.

On pourrait bellement créer une classe abstraite qui définit une méthode abstraite CompareTo et faire en sorte que notre classe Person hérite de cette classe et fournit un corps pour compareTo et que la méthode sort accepte des objets qui étendent cette classe mais l'avantage est qu'en java on peut implémenter un nombre théoriquement illimité d'interfaces tandis qu'on ne peut hériter que d'une seule classe.

Les classes abstraites sont utilisées pour rassembler le maximum de traitement que ses sous classes en ont besoin.
Par exemple pour deux classes Student et Teacher qui ont chacune des méthodes getId et getName et getSalary on peut créer une classe abstraite Person :

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
 
abstract class Person {
 
private int id;
private String name;
 
// cette méthode n'est pas abstraite
public int getId() {
   return id;
}
 
// cette methode l'est aussi
public String getName()
return name;
}
// On évite ainsi la réecriture du code pour chacune des sous classes
 
/* Mais cette méthode est abstraite car chaque sous classe a besoin de la définir à sa manière : */
public abstract int getSalary();

Les sous classe n'ont besoin de définir que la méthode getSalary().

J'espèreque j'ai été clair.

[eclesia]

Je suis d'avis d'utiliser toujours des interfaces quand cela est possible (et meme d'en abuser).

A partir du moment où une classe peut avoir une variante qui puisse faire la meme chose il faut une interface.

On peut meme arriver a faire la structure d'un programme qu'avec des interfaces. Libre au developpeur d'en faire des implementations diverses.
La maintenance est grandement simplifier si on manipule les objects que par des interfaces.

Cette facon de faire est utiliser par GeoApi par exemple, cette librairie est faite presque exclusivement d'interface. Ensuite d'autres librairies comme GeoTools ou des logiciels comme GvSIG,UDIG,Geoserver ...etc... implementent ces interfaces. Ces interfaces sont en realité des transpositions en code des normes iso et ogc, tout le monde est gagnant a les utiliser. L'interopérabilité des outils est aussi grandement amélioré.

[Amine_sas]

Je suis d'avis d'utiliser toujours des interfaces quand cela est possible (et meme d'en abuser).

A partir du moment où une classe peut avoir une variante qui puisse faire la meme chose il faut une interface.

On peut meme arriver a faire la structure d'un programme qu'avec des interfaces. Libre au developpeur d'en faire des implementations diverses.
La maintenance est grandement simplifier si on manipule les objects que par des interfaces.

A mon avis, en utilisant les interfaces, on finit souvent par tirer partie des avantages de l'héritage multiple tout en évitant sa complexité (et parfois inefficacité ) inhérente.

[Chatbour]

merci beaucoup les gars

Amine_sas, merci pour l'explication étendue

[divxdede]

Voila ma vision des choses:

Une interface décrit le contract général d'un "type" d'objets, ce contract est composés de deux grandes familles de méthodes
- les business
- les techniques (gestion des listeners, sécurités, affichage, etc...)

La ou les classes abstraites implémentant l'interface vont donner une implémentation par défaut (bien souvent suffisante) pour toutes les méthodes techniques (gestion des listeners).

De plus la classe abstraite peut fournir des méthodes suplémentaires (protected) permettant d'aider sensiblement l'implementation des classes réélles (exemple: les fireXXX() pour la gestion des listeners)

Les classes réélles pourront ainsi deriver de la classe abstraite et se concentrer sur le "métier" de l'objet.

Avec cette méthodologie, puisque tu possédes malgrés tout une interface tu pourras malgrés tout faire implémenter ton contrat général à un objet pour lequel son héritage ést déja imposé par ton architecture.

Bien sur, des classes abstraites peuvent donner des implémentations par défaut de méthodes dites "business", tout dépends ensuite de la conception et l'architecture choisie, il s'agissait que de donner un exemple.