Signature des méthodes redéfinies

Version imprimable

03/10/2013, 02h56
Yiempia

Signature des méthodes redéfinies

Bonjour
J'essaye de traiter un problème qui nécessite d'avoir une classe abstraite que j appellerais ClasseAbstraite. Cette classe contient une méthode abstraite dont la la signature serait par exemple public abstract void methodeAbstraite();
Je voudrais que les classes filles de ClasseAbstraite redéfinissent la méthode abstraite mais en spécifiant des paramètres obligatoires à passer la méthode selon le besoin de chaque classe fille.
Cela est il faisable? Y a t'il d'autres possibilités pour parvenir au même résultat ?
Merci d'avance
03/10/2013, 03h07
plawyx

la redéfinition impose la même signature (même nombre d’arguments et même types) et le même type de valeur de retour

Dans ton cas, public abstract void methodeAbstraite();

Donc pas question de lui passer des arguments lors de la redéfinition
03/10/2013, 03h19
Yiempia

Merci pour la réponse. J'ai vu qu il était possible de changer lors de la redéfinition le type de retour par une classe fille du type de retour initial. Est il possible d'en faire autant avec les paramètres? Concrètement si je passe en paramètre de methodeAbstraite un objet A. Serait il possible lors de la redéfinition dans les classes filles de passer un objet B qui hériterait de A?
03/10/2013, 03h30
plawyx

Citation:

Envoyé par Yiempia

Concrètement si je passe en paramètre de methode Abstraite un objet A. Serait il possible lors de la redéfinition dans les classes filles de passer un objet B qui hériterait de A?

Le type de l'objet est B et par extension, son type est aussi A. Donc en travaillant sur des objets surtypé A, la différence de traitement entre les objets B se fera par polymorphisme.
03/10/2013, 03h34
Yiempia

Ok. Parfait. Cela devrait résoudre mon problème. Je teste ça et te dit quoi.

Merci.
03/10/2013, 03h36
plawyx

peux-tu donner le traitement à faire dans la méthode abstraite?

Tu veux dire les méthodes redéfinies? La méthode abstraite n'ayant pas de corps.

Pour aller plus en détails les classes filles doivent juste retourner des messages textes en utilisant les paramètres qui leurs seraient passés.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
public class Fille1 extends ClasseAbstraite
{
         public String methodeAbstraite(String nom)
         {
               return "Bonjour "+ nom;
         }
}
 
public class Fille2 extends ClasseAbstraite
{
         public String methodeAbstraite(int age)
         {
               return "J'ai "+ age + "\n" + "ans";
         }
}

J'ai ensuite une classe Service dans laquelle sont injectées les classes filles sant que la classe service ne connaissent leur implémentation réelle.

Code:

1
2
3
4
5
6
7
8
9
10
 
public class Service
{
         ClasseAbstraite fille1;
         ClasseAbstraite fille2;
         public String donnerInfos()
         {
               return fille1.methodeAbstraite("toto") +"\n"+fille2.methodeAbstraite(15);
         }
}

À propos du test, le compilo n'a pas l'air d'apprécier.
J'ai ceci:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
public class ClasseA
{}
 
public class ClasseB extends ClasseA
{}
 
public abstract ClasseAbstraite()
{
       public abstract String methodeAbstraite( ClasseA classeA);
}
 
public classe Fille1 extends ClasseAbstraite
{
       @Override
       public String methodeAbstraite( ClasseB classeB)
       {
               return null;
       }
}

Le compilo ne reconnaît pas la redéfinition et demande d'implementer la méthode abstraite de la classe abstraite.

03/10/2013, 04h35
plawyx

la redéfinition impose la même signature (même nombre d’arguments et même types) et le même type de valeur de retour

donc tu ne peux pas faire :

String methodeAbstraite(String nom) et String methodeAbstraite(int age)

par contre, nom et age semble être des atttributs nom et age. Alors

public class Fille1 extends ClasseAbstraite
{
public String methodeAbstraite()
{
return "Bonjour "+ this.getNom();
}
}

public class Fille2 extends ClasseAbstraite
{
public String methodeAbstraite()
{
return "J'ai "+ this.getAge() + "ans";
}
}

en déclarant les getter et setter de tes attributs de la classe fille.
(si age et nom sont des attributs de la classe mère, déclare les egtter et les setter dans la classe mère et remplace this par super: super.getAge().

public class Service
{
ClasseAbstraite fille1 = new fille1();
ClasseAbstraite fille2 = new fille2();
public String donnerInfos()
{
return fille1.methodeAbstraite() +"\n"+fille2.methodeAbstraite();
}
}

c'est le polymorphisme.

D'autre part, si tu utilises beaucoup le concaténation, passes dans un permier temps par StringBuilder .
03/10/2013, 04h45
Yiempia

Tout à fait daccord avec toi sur la redéfinition des méthodes.
Mais mon souci est que la classe service se trouve dans un projet qui ne connait pas les implémentations réelles des classes filles. Elle ne peut donc pas faire
ClasseAbstraite fille1 = new fille1();
Elle peut tout au plus passer des argument à une fabrique qui lui retourne une instance de Fille1 sous le type ClasseAbstraite.

Dans la réalité des faits la construction des messages est beaucoup plus complexe. J'ai juste simplifier pour l'exemple.

Citation:

Envoyé par Yiempia

Elle peut tout au plus passer des argument à une fabrique qui lui retourne une instance de Fille1 sous le type ClasseAbstraite.
.

tu souhaiterais un truc comme ça
Code:

1 2 ClasseAbstraite fille1 = Factory.create(int age); ClasseAbstraite fille2 = Factory.create(String nom);
Si oui, modifie la Factory et surcharge : public abstract void methodeAbstraite();
Code:

1 2 public abstract String methodeAbstraite(int age); public abstract String methodeAbstraite(String nom);
ensuite, après implémentation, tu pourras utiliser ce genre de code
Code:

1 2 3 4 public String donnerInfos() { return fille1.methodeAbstraite("toto") +"\n"+fille2.methodeAbstraite(15); }

03/10/2013, 05h25
Yiempia

Je parlais d'un autre projet.
Le premier projet me fournit un .jar que j inclus dans le second.
Le premier projet définit des objects abstraits que j'utilise dans le second sans connaître leur implantation réelle. J'ai accès uniquement au classes abstraites. Lorsque j'ai besoin d'un objet je passe juste des paramètre et le premier projet se charge de le créer et me le retourne sous un type abstrait.
Cela me permet de modifier la structure des données dans le projet 1 sans affecter le code du projet2.

Je peux bien sur modifier le code de ces deux projets. Mais le projet 2 ne doit jamais connaître les implémentations réelles des classes. Sinon tout modification de ces implémentations impliquera une modification de ce dernier. Ce qui n est pas souhaitable.
03/10/2013, 06h52
Yiempia

Ça me donne un début de solution. Je vais creuser plus pour adapter à mon cas. Merci beaucoup pour ton aide.
03/10/2013, 08h29
thelvin

Ce n'est pas terrible -_-°.

Puisqu'à fille1 on lui donne une String et à fille2 on lui donne un int, ça veut dire qu'on connaît une différence de type entre les deux.

Deux possibilités :
- Ce n'est pas la même méthode qu'on appelle sur l'une et sur l'autre : (une méthode prend un int, l'autre une String.) Dans ce cas fille1 et fille2 n'ont pas besoin d'etre de type ClasseAbstraite. Elles pourraient être ClasseAbstraiteString et ClasseAbstraiteInt.

OU

- On rend ClasseAbstraite générique, et on déclare fille1 comme ClasseAbstraite<String> et fille2 comme ClasseAbstraite<Integer>. La méthode appelée sera alors la même, mais le type attendu étant générique, l'une prendra une String et l'autre un Integer.
C'est en général la solution la plus flexible. Mais pas forcément la plus simple ni la plus logique.
03/10/2013, 14h06
Yiempia

La deuxieme méthode semble tres intéressante.
J'avais entre temps adopté une solution qui résolvait mon probleme mais ne comvenait pas trop coté maintenance du code.
Je vais tenter cette piste et te dire quoi.
Merci
03/10/2013, 17h04
plawyx

Citation:

Envoyé par thelvin

Puisqu'à fille1 on lui donne une String et à fille2 on lui donne un int, ça veut dire qu'on connaît une différence de type entre les deux.

D'où la surcharge de la méthode abstraite dans la factory : 1 ligne

Citation:

Envoyé par thelvin

- On rend ClasseAbstraite générique, et on déclare fille1 comme ClasseAbstraite<String> et fille2 comme ClasseAbstraite<Integer>. La méthode appelée sera alors la même, mais le type attendu étant générique, l'une prendra une String et l'autre un Integer.
C'est en général la solution la plus flexible. Mais pas forcément la plus simple ni la plus logique.

l'implémentation de la méthode surchargé permet aussi de différencier le traitement selon le type: 3 lignes dans ce cas.

L'adaptation du traitement de la méthode au type se fait en 4 voir 5 lignes et en deux minutes grâce à une simple surcharge de méthode
03/10/2013, 17h24
thelvin

La surcharge (des classes produites, pas de leur factory,) est une solution du pauvre. Elle désactive la vérification du compilateur et la remplace par une détection d'erreur au runtime peu maintenable.
Elle implique que chacun de ces deux objets dispose de deux méthodes : une qui reçoit un int et une qui reçoit une String.

D'après ce que j'ai compris ce n'est pas le cas. L'un des objets est capable de recevoir un int et pas une String, et l'autre objet est capable de recevoir une String et pas un int.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class Fille1 extends ClasseAbstraite
{
         public String methodeAbstraite(String nom)
         {
               return "Bonjour "+ nom;
         }
}
 
public class Fille2 extends ClasseAbstraite
{
         public String methodeAbstraite(int age)
         {
               return "J'ai "+ age + "\n" + "ans";
         }
}

Il y a donc deux classes Fille1 et Fille2. Avec la surcharge, il aurait une classe unique :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
public class Fille extends ClasseAbstraite
{
         public String methodeAbstraite(String nom)
         {
               return "Bonjour "+ nom;
         }
 
         public String methodeAbstraite(int age)
         {
               return "J'ai "+ age + "\n" + "ans";
         }
}

donc une classe, deux méthodes.

03/10/2013, 17h41
thelvin

Citation:

Envoyé par plawyx

donc une classe, deux méthodes.

... Certes.

Et justement de ce que j'en ai compris, ce qu'on veut, c'est deux objet, avec chacun sa méthode unique.

Fuseau horaire GMT +2. Il est actuellement 20h57.