Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Utilisation des generics

2 réponses
Avatar
oziris
bonjour,

Je me mets doucement aux nouveaut=E9s de Tiger, notamment aux
g=E9n=E9rics.
J'ai tent=E9 un truc dans le genre mais ca n'a pas l'air de plaire au
compilateur. Peut etre que c'est totalement idiot, que ca veut rien
dire...

public abstract class AbstractComponent extends <A extends JComponent>
implements ChangeListener {
// class content
}

Pkoi ca ne pourrait pas marcher? snif...

-o

2 réponses

Avatar
oziris
Pour etre plus précis c'est pour résoudre "joliement" un probleme
d'héritage multiple.
J'ai la classe abstraite suivante:

public abstract class AbstractComponent implements ChangeListener {
// class content
}

Et des classes concretes comme celles ci *en considerant que
l'héritage multiple est possible*:

public Component1 extends AbstractComponent, JLabel {
// class content
}

public Component2 extends AbstractComponent, JTable {
// class content
}

etc.

Mon idée était donc d'étendre les composants JLabel, JTable, etc. au
niveau de la classe abstraite AbstractComponent.

C'est une idée de 22h, soyez indulgent ;-)

-o






bonjour,

Je me mets doucement aux nouveautés de Tiger, notamment aux
générics.
J'ai tenté un truc dans le genre mais ca n'a pas l'air de plaire au
compilateur. Peut etre que c'est totalement idiot, que ca veut rien
dire...

public abstract class AbstractComponent extends <A extends JComponent>
implements ChangeListener {
// class content
}

Pkoi ca ne pourrait pas marcher? snif...

-o


Avatar
Sylvain
oziris wrote on 20/07/2006 22:26:
Pour etre plus précis c'est pour résoudre "joliement" un probleme
d'héritage multiple.
J'ai la classe abstraite suivante:

public abstract class AbstractComponent implements ChangeListener {
// class content
}


si elle ne fait que prétendre implémenter ChangeListener tout en restant
abstraite pour ne pas le faire, cette classe ne sert à rien.


Et des classes concretes comme celles ci *en considerant que
l'héritage multiple est possible*:

public Component1 extends AbstractComponent, JLabel {
// class content
}


quelle avantage pour rapport à un appel à addPropertyChangeListener dans
le constructor ?

public abstract class AbstractComponent extends <A extends JComponent>
implements ChangeListener {
// class content
}



un générique ne sert que à rendre la classe définie générique par
rapport à un type de données manipulé ou possédé; il ne peut pas servir
pour hériter de quelque-chose-non-défini.

une écriture possible serait:

public class AbstractComponent<A extends JComponent>
implements javax.swing.event.ChangeListener
{
A component;

public AbstractComponent(A component){
this.component = component;
}
public void stateChanged(javax.swing.event.ChangeEvent e){
// que faire de l'event ?????????
component.firePropertyChange("???", 1, 2);
}
}

je passe ici une instance du type concrêt en param. du constructeur car
la classe générique ne peut pas le construire elle-même.

on peut alors avoir des AbstractComponent typés en faisant:

AbstractComponent<JLabel> label new AbstractComponent<JLabel>(new JLabel(...));

AbstractComponent<JTable> table new AbstractComponent<JTable>(new JTable(...));

mais cela n'apporte rien de génial, de beau, ..., à la spécialisation
d'un label ou d'une table (le besoin initial), voire complexifie ce
qu'il faut faire des events reçus.

Sylvain.