Discussion :

[techz]

Bonjour à tous ,
je débute en java et je vois beaucoup d'exemples de code qui instancient des objets de cette facon :

Code :

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

superclasse mareference = new sousclasse () ;

Je ne comprend pas pourquoi ils utilisent une reference du type de la superclasse pour instancier un objet d'une sous-classe .

Quelle différences entre :

Code :

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

superclasse mareference = new sousclasse () ;

et

Code :

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

sousclasse mareference = new sousclasse () ;

Je sais que les deux sont correct mais pourquoi ecrire plus l'une que l'autre ?
Merci d'avance de votre aide .

[Eric73]

Bonjour,

Je réponds à ce sujet car la question que tu soulèves relève d'une maladresse que je rencontre fréquemment dans le code existant sur lequel je travaille depuis maintenant presque 2 ans.
A la base de la POO, il y a le polymorphisme, que tu connais je pense. Si ce n'est pas le cas, et pour faire bref, c'est ce qui donne son sens à la notion d'héritage. En effet, lorsqu'une classe hérite d'une autre, c'est parce que l'objet qu'elle modélise est de même nature que son parent, mais possède des spécificités supplémentaires. L'exemple bateau, c'est celui des formes géométriques : un Rectangle et un Cercle sont des Forme, et ils partagent la possibilité de se dessiner(). Cette méthode dessiner() est d'ailleurs définie sur la classe Forme, et chaque classe enfant la redéfinit à sa façon. Pour autant, l'intérêt est de pouvoir manipuler des Forme sans connaître leur nature exacte. Si je parcours une liste de Forme, je peux les faire se dessiner successivement sans chercher à savoir si ce sont des Rectangle ou des Cercle :

Code :

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

1
2
3
for (Forme forme : formes) {
  forme.dessiner();
}

Donc, afin de ne pas te fermer des portes dans ton code, il est bon, lorsque tu dois définir une variable, de toujours te demander jusqu'à quel point le traitement que tu vas lui faire subir est générique, afin de lui choisir le type le plus général possible.
Le meilleur exemple, c'est l'utilisation des collections. Je vois énormément au travail des choses du genre :

Code :

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

1
2
3
4
LinkedList<UnType> list = new LinkedList<UnType>();
for (UnType objet : list) {
  [...traitement sur l'objet...]
}

Le programmeur a décidé d'utiliser une LinkedList, et a déclaré sa variable comme telle. Mais le traitement qu'il fait n'utilise absolument pas le fait que c'est une LinkedList qu'il manipule.
S'il avait écrit :

Code :

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

1
2
3
4
Collection<UnType> list = new LinkedList<UnType>();
for (UnType objet : list) {
  [...traitement sur l'objet...]
}

il aurait pu changer d'implémentation et passer à une ArrayList si besoin, sans rien avoir à changer d'autre que la ligne d'instanciation. Et même s'il avait, à un moment donné, besoin d'utiliser les spécificités des listes, à savoir accéder à un élément par son indice par exemple, il vaudrait alors mieux qu'il écrive ça :

Code :

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

List<UnType> list = new LinkedList<UnType>();

pour la même raison.

Dans cette exemple, la question à se poser, c'est : "Que dois-je faire de ma collection ?". Si je dois seulement la parcourir, je dois déclarer une Collection. Si je dois accéder à des éléments par leur indice, j'ai besoin d'une List. ArrayList et LinkedList n'en sont que des implémentations, chacune avec ses avantages et inconvénients, mais le code qui utilise la collection s'en fiche. S'il ne doit pas y avoir de doublon, il me faut un Set. Même si Set ne définit aucune méthode spécifique de plus que Collection, on voit alors en lisant le code qu'il est important de ne pas avoir de doublon. Libre à moi de choisir un HashSet ou un TreeSet à l'instanciation.

La meilleure pratique, à mon sens, est de s'interroger sur l'utilisation qu'on fait de ses variables (membres ou pas), et de les déclarer du type le plus général possible par rapport au besoin.

J'ai été long, mais j'espère avoir été clair .

[techz]

Merci beaucoup ,
effectivement c'est beaucoup plus clair avec l'exemple des enssembles .

Merci à toi .

[Eric73]

Mais de rien, n'oublie pas de passer le sujet en Résolu .