classe "récursive" et héritage - Page 1

abstract class ClasseDeBase {
    (...)
    protected ClasseDeBase PointeurVersUneInstanceDeClasseDeBase;
    (...)
}

public class ClasseHeritante extends ClasseDeBase {
    (...)
    fonction Toto(blabla) {
        PointeurVersUneInstanceDeClasseDeBase= UneInstanceDeClasseClasseHeritante;
    }
    (...)
}

Lors de l'affectation, est-ce que PointeurVersUneInstanceDeClasseDeBase sera du type ClasseHeritante, donc est-ce que les méthodes et les attributs de ClasseHeritante seront utilisables ?

Bon, c'était prévisible : ça ne marche pas. Ca m'embête, je voudrais créer une classe générique pour créer des listes chaînées. Il faudrait que cette classe contienne un pointeur vers elle-même, puisque c'est une liste chaînée. Le problème, c'est que les classes qui en héritent ne peuvent pas utiliser ce pointeur, se référencer elles-mêmes... Bref ma classe générique ne sert à rien.

[edit du post ./1] : Je me suis mélangé les pinceaux en l'écrivant.

(si tu écrivais "a" et "b" pour tes attributs au lieu de noms de 3km de long ça serait bien plus facile à lire et donc comprendre)

Pour ton truc ça devrait marcher, mais tu vas de toutes façons avoir besoin d'un cast (enfin tout dépend de ce que tu veux faire, tu n'as pas précisé). Mais il me semblait que Java supportait les templates, non ? (c'est précisément pour ce genre de cas qu'ils existent, normal que tu n'arrives pas à faire sans)

[edit] tiens, JackosKing connecté, je prédis une explication avec au moins 2 ou 3 mots en anglais pour décrire un truc complètement basique de poo qui pourrait s'expliquer en français, et au moins une fois "contrat"
[edit 2] raté

A priori, je ne vois pas de problème dans ton bon de code.
Peux-tu être plus précis. sur le message d'errreur que tu as est a quel niveau?

Enfin, ça n'a rien à voir mais en java il y a des conventions sur l'écriture des variables, très pratiques pour la lisibilité car en général bien respectée par tous:
-Les classe s'écrivent : MaClasse (premières lettres des mot en majuscule pas de _)
-Les variables/objets s'écrivent : monObjet (premier mot en minuscule, puis majuscule pous la première lettre des autres mots, pas de _)
-Les constantes s'écrivent : MA_CONSTANTE (tout en majuscule avec _ entre les mots)
Quand on a pris l'habitude, les mon d'objets en majuscule ça pique les yeux.

pas envie de troller mais ça c'est totalement arbitraire et je vois pas pourquoi il *faut*

(ok, je sais, c'est pratique, tout le monde fait comme ça, mais il *faut* pas.)

sinon moi un PointeurVersUneClasseDeBase j'aurais plutot écrit:


ClasseDeBase *PointeurVersUneClasseDeBase

, non?

[edit] en fait, dsl ^^

Heu... "Index » Forum Informatique » Java" ?

mais la première partie de mon post en toujours dans le sujet #rattrapobranches#

Uther : Un programme Java n'est pas moins lisible quand il est écrit en C-style. C et Java c'est la même syntaxe
Je trouve la convention Java moche et chiante (appuyer 36 fois par seconde sur SHIFT avec le petit doigt, c'est chiant).


Tiens, régale-toi : } /*   Thibaut BARTHELEMY - mai 2008   Cette classe définit de manière générique, universelle, l'élément   de base d'une liste chaînée : un maillon.   Elle permet de ainsi la création de chaînes adaptées à n'importe   quel besoin. Le but est de simplifier et d'accélérer la   construction de listes chaînées, en fournissant les méthodes de base   nécessaires à leur exploitation (ajout d'un maillon, etc). */ public class c_maillon {     protected  int        identifiant;         // numéro unique pour identifier le maillon     protected  c_maillon  lien;                // pointeur (optionnel) vers un autre maillon (pouvant appartenir à une autre chaîne)     protected  int        nombre_de_referents; // indique combien de maillons ont inscrit celui-ci dans leur attribut "lien"     protected  c_maillon  precedent,           // maillon précédent dans la chaîne                           suivant;             // maillon suivant dans la chaîne     // renseigne les attributs essentiels du maillon     protected void  renseigner_maillon (int identifiant_, c_maillon precedent_, c_maillon suivant_)     {         identifiant= identifiant_;         lien= null;         nombre_de_referents= 0;         precedent= precedent_;         suivant=  suivant_;     }               // initialise le maillon à zéro lors de sa création     // lorsqu'aucun renseignement n'est donné     c_maillon ()     {         renseigner_maillon(-1, null, null);     }               // initialise le maillon lors de sa création     // en utilisant les renseignements donnés     c_maillon (int identifiant_, c_maillon precedent_, c_maillon suivant_)     {         renseigner_maillon(identifiant_, precedent_, suivant_);     }               // demande au maillon d'insérer un nouvau maillon dans la chaîne     public c_maillon  inserer_maillon (int identifiant_)     {         c_maillon  nouveau_maillon;         nouveau_maillon= new c_maillon(identifiant_, this, suivant);                  if (suivant != null) suivant.precedent= nouveau_maillon;         suivant= nouveau_maillon;                  return (nouveau_maillon);     }     // Cette méthode demande au maillon de se retirer lui-même de la chaîne.     // Java libérera automatiquement la mémoire car plus aucun pointeur ne le référencera.     // Il faut d'abord s'assurer qu'aucun autre maillon n'a établi de lien vers lui.     public boolean  retirer_maillon ()     {         if (nombre_de_referents != 0) {             return (false);         }         else {             if (precedent != null) precedent.suivant= suivant;             if (suivant != null) suivant.precedent= precedent;             if (lien != null) lien.nombre_de_referents-= 1;             return (true);         }     }               // demande au maillon de pointer vers un autre maillon     public boolean  set_lien (c_maillon lien_)     {         if (lien != null)         {             return (false);         }         else {             lien= lien_;             lien.nombre_de_referents+= 1;             return (true);         }     }     // le maillon communique son identifiant     public int  get_indentifiant ()     {         return (identifiant);     }          // le maillon renvoie l'adresse du maillon qu'il référence     public c_maillon  get_lien ()     {        return (lien);     }               // le maillon renvoie l'adresse de celui qui le précède dans la chaîne     public c_maillon  get_precedent ()     {        return (precedent);     }               // le maillon renvoie l'adresse de celui qui le suit dans la chaîne     public c_maillon  get_suivant ()     {        return (suivant);     }

T'as qu'à appuyer avec l'index espèce de feignasse trolleuse

Je ne dis pas qu'un code ne respectant pas ça est forcément moche. Mais c'est quand même bien sympa de reconnaitre au premier coup d'œil variables, classes et constantes.

Dans ton premier exemple c'est particulièrement troublant car on a l'impression que tu utilises cette convention ce qui n'est pas le cas. Dans ton dernier post on voit dessuite que tu n'utilise pas la syntaxe recommandée. Au moins on est pas surpris.

Faute de frappe dans get_indentifiant.

Uther : Tu ne trouves pas ça moche d'avoir des majuscules partout au milieu des identificateurs ?
M'enfin bon, je ne compte pas mettre mon code sous GPL et le diffuser au monde entier, t'inquiète pô Ca va rester entre moi et mon prof d'info.

Kevin : Ah ? Dans le commentaire ? (la classe compile)

Thibaut (./13) :
Tu ne trouves pas ça moche d'avoir des majuscules partout au milieu des identificateurs ?

jesaispassicettephraseestvraimentlisible, MaisCelleLaLEstCertainementPlus (et_celle_la_encore_mieux)

entre fileoutputstream et FileOutputStream, je préfère prendre le temps d'écrire 3 majuscules, avec le pouce en plus )

Thibaut (./12) :
Uther : Tu ne trouves pas ça moche d'avoir des majuscules partout au milieu des identificateurs ?
M'enfin bon, je ne compte pas mettre mon code sous GPL et le diffuser au monde entier, t'inquiète pô Ca va rester entre moi et mon prof d'info.

Mon principal soucis n'est pas la beauté mais la lisibilité.
Quand tu échanges du code avec plusieurs personnes, c'est quand même bien pratique d'avoir des convention ne nommage communes. En l'occurence, ça peux être sympa pour ton prof d'info et tes futurs collèges, même si tu ne fais pas de prog libres.
J'ai déjà bossé dans des équipes qui n'ont aucune convention de codage communes et parfois ca fait peur. Des chose que certain estimaient super pratique et propres peuvent paraitre illisibles à d'autres.

parlesTu_des_noms_melanges_CommeCa?

Au fait ! Je n'ai plus besoin de la réponse à ma question. Cependant, je suis quand même curieux de savoir comment parvenir à ce que je voulais faire.

Le but était de pouvoir faire un classe générique, capable de pointer vers une autre instance d'elle-même. Mais, quand cette classe aurait été héritée, il aurait fallu que ses enfants puissent pointer vers des instances héritées et non-pas sur la classe de base.

Aucun problème en java pour faire ce que tu veux faire, le problème viens plutot de ta syntaxe. Le mot clé "function" par exemple n'existe pas en java:

J'ai essayé ce bout de code, il marche:

abstract class ClasseDeBase { 
   protected ClasseDeBase objetDeClasseDeBase; 
} 
 
class ClasseHeritante extends ClasseDeBase { 
    void newClasseHeritante() { 
        objetDeClasseDeBase= new ClasseHeritante(); 
    } 
}

c'est pas plutot:

abstract class ClasseDeBase {  
   protected ClasseDeBase objetDeClasseDeBase;  
}  
  
class ClasseHeritante extends ClasseDeBase {  
    ClasseHeritante() {  
        objetDeClasseDeBase= this;  
    }  
}

qu'il veut faire?

C'est pareil enfin je pense. Ce que fait Uther correspond mieux à ce que je demandais si on veut chipoter.

Oui, j'ai remarqué que ça passait, le compilo ne bronche pas... Par contre, essaie d'accéder à des attributs et des méthodes définis dans ClasseHeritante avec le pointeur objetDeClasseDeBase : ça ne marche pas. Pourtant, il pointe bien vers l'adresse retournée par new ClasseHeritante().

C'est normal, le type de son conteneur est toujours ClasseDeBase quel que soit la valeur que tu y affectes (et même si, en l'occurrence, c'est une instance de ClasseHeritante ce que le compilo ne peut pas deviner).

Plusieurs solutions :
- Soit des templates
- Soit au lieu d'accéder directement à l'attribut, tu crées un getter et un setter que tu peux surcharger pour leur faire retourner un pointeur du bon type (ClasseHeritante et non pas ClasseDeBase) (par contre il y aura toujours un cast à faire dans ces getter/setter, ou bien il faudra dupliquer les attributs au fur et à mesure que tu hérites, la solution à base de templates est donc clairement plus propre)

et un cast? (après un test instanceof truc)

Au final ça revient au même que la 2eme solution, sauf qu'il va devoir mettre des casts partout où il veut accéder à l'attribut plutôt qu'un seul (dans le getter). C'est juste pour faire un peu moins moche.

ahwé, ok. on est d'accord.

Dupliquer, ça veut dire déclarer un attribut dans la classe héritante portant le même nom qu'un attribut dans la classe de base ? Cela revient à dire qu'on change le type de l'attribut ?

ça voulait dire ajouter un nouvel attribut du bon type à chaque fois (je ne sais pas si on peut surcharger des attributs en Java, il ne me semble pas donc il faudra qu'ils portent des noms différents), mais du coup tu te traines de plus en plus d'attributs inutiles dans les classes filles, sous-filles, etc. Même si c'est masqué par le fait que tes getters/setters vont accéder uniquement au bon attribut et que tu n'auras pas à te poser la question dans le reste du code, ça reste très lourd et très laid :/

./19 ce que tu fais est plus logique mais je faisait pour être le plus conforme a ce qu'a demandé Thibaut.

Si tu veux l'utiliser c'est tout à fait possible mais encore faut il être sur que la variable de type ClasseDeBase point bien sur un objet de classe ClasseHeritante, sinon tu auras une ClassCastException. Si tu en est certain tu peux faire une conversion avec un truc du genre:
) ((ClasseHeritante)objetDeClasseDeBase).maFonctionHeritee(
Si tu n'en est pas certain du type tu peux faire

if(objetDeClasseDeBase instanceof ClasseDeBase){
  ((ClasseHeritante)objetDeClasseDeBase).maFonctionHeritee()
} else {
  //fonctionnalité non supportée par cet objet
}

Merci "instanceof" ça correspond à "is" en C++ (à moins que ce soit en Pascal Objet) ?
Au fait, c'est pas plutôt :

(ClasseHeritante
)objetDeClasseDeBase).maFonctionHeritee()

?

en effet, pas bien réveillé ce matin

./21 > Je ne suis pas d'avis que les generics(équivalent des template C++) soient plus propre.

Je ne pense pas que les generics doivent être utilisé systématiquement pour éviter les cast.
Autant je trouve le gain des generics tout a fait appréciable dans certains cas comme pour des conteneurs ou ca fait réelement sens. Je trouve carrément pas clair dans ce genre de cas, ou on ne vois pas directement a quoi ça correspond.

Uther (./29) :
en effet, pas bien réveillé ce matin

./21 > Je ne suis pas d'avis que les generics(équivalent des template C++) soient plus propre.
Je ne pense pas que les generics doivent être utilisé systématiquement pour éviter les cast.

En général c'est une bonne idée, mais pas en java. A ce que j'ai compris quand on me l'avait expliqué les generics de Java ont plutôt tendance à rajouter des casts (implicitement) qu'a en retirer comme c'est le cas en C++ ou C#.

Autant je trouve le gain des generics tout a fait appréciable dans certains cas comme pour des conteneurs ou ca fait réelement sens. Je trouve carrément pas clair dans ce genre de cas, ou on ne vois pas directement a quoi ça correspond.

Moi je serais plutôt de l'avis de Zephyr, tu fais une classe "ClasseHeritee extends ClasseDeBase<ClasseHeritee>" c'est pas la solution absolue mais au moins c'est clean du cotée de tes classes enfant. (En fait il faudrait avoir un langage avec un pseudo-type genre "ThisType" qui représenterait le type de l'instance actuelle. ça serait assez sympa et puis ça ne casserait pas les relations d'héritage ^^)