Surdéfinition de données membres héritées

Version imprimable

01/07/2008, 23h52
Babcool

Surdéfinition de données membres héritées

Bonjour,

Voila les différentes données de mon problème, j'ai une classe A, qui contient une donnée membre sommet de type Sommet, de plus j'ai réalisé une classe Etat qui hérite de sommet.

Est il possible de réaliser une classe B qui hérite de A mais dans laquelle sommet serait de type Etat (il faudrait redéfinir sommet pour lui donner le type Etat).

Merci d'avance ;)

Babcool

Salut,
Non, il faut passer par les méthodes pour avoir l'override (ainsi que l'ellipse introduit dans Java 5) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
class A {
	protected Sommet getSommet(){
		return new Sommet();
	}
 
	public void test(){
		System.out.println(getSommet());
	}
 
}
 
class B extends A {
 
	@Override
	protected Sommet getSommet() {
		return new Etat();
	}
}

02/07/2008, 00h21
tchize_
Non. Pour la simple est bonne raison que les méthodes de A traitent un sommet de type Sommet, y compris probablement sa création. Hors si tu pouvais changer le type du membre, tu te retrouverais à faire dans A "Etat sommet; ..... sommet = new Sommet()", çà pourrais pas marcher.

Par contre point de vue design, ton but est atteignable (ouf!)

classe A:
Code:

1 2 3 4 5 6 private Sommet sommet = new Sommet(); protected Sommet getSommet() {return sommet;} public void machin(){ getSommet().quelquechose(); }
classe B extends A:
Code:

1 2 3 4 private Etat sommet = new Etat(); protected Sommet getSommet() {return sommet;} //pas besoin de réécrire machin(), il manipulera le "etat"
Donc en gros, ce que tu veux "changeable", faut y accéder par des getters qui sont soit protected soit public. Ainsi les descendant ont le controle sur ce qu'ils renvoient.
02/07/2008, 00h57
Babcool

Ok, merci bah je vais voir comment je peux me débrouiller avec ça alors ;)...

Merci bien :)

Salut,

Il faut revoir vos classiques les gars ;)
Depuis Java 5.0 et le type de retour covariant c'est possible !

:faq: Quelles sont les règles à respecter pour redéfinir/implémenter une méthode ?

Prenons cette classe avec getter/setter :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
class A {
 
	private Sommet sommet;
 
	protected Sommet getSommet(){
		return this.sommet;
	}
 
	protected void setSommet(Sommet sommet) {
		this.sommet = sommet;
	}	
}

Si on veut changer le type de "Sommet" dans "B", on peut utiliser quelque chose du genre :

Code:

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
28
29
30
31
32
33
34
35
class B extends A {
 
	/*
	 * On redéfinit la méthode en changeant on type de retour
	 * (grave à la covariance intégré avec Java 5.0),
	 * et en effectuant un cast (il faut bien sûr s'assurer
	 * par ailleur que le sommet est bien du type etat) :
	 */
	@Override
	protected Etat getSommet() {
		return (Etat)super.getSommet();
	}
 
	/*
	 * On redéfini setSommet(Sommet) en la dépréciant car elle
	 * ne doit plus être utilisé directement, mais on l'implémente
	 * quand même en vérifiant le type du paramètre (car la méthode
	 * peut être utilisé par ailleurs).
	 */
	@Override @Deprecated
	protected void setSommet(Sommet sommet) {
		if (sommet instanceof Etat) {
			super.setSommet(sommet);
		}
		throw new IllegalArgumentException();
	}
 
	/*
	 * On surcharge setSommet() avec un paramètre Etat qui devra
	 * être utilisée pour définir le sommet avec un Etat ;)
	 */
	protected void setSommet(Etat etat) {
		super.setSommet(etat);
	}
}

Sinon une seconde solution serait d'utiliser les Generics sur la première classe (si on peut la modifier) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
class A<S extends Sommet> {
 
	private S sommet;
 
	protected S getSommet(){
		return this.sommet;
	}
 
	protected void setSommet(S sommet) {
		this.sommet = sommet;
	}	
}

Il n'y aurait alors quasiment rien à faire sur la classe fille, si ce n'est de définir le paramétrage :

Code:

1
2
3
class B extends A<Etat> {
 
}

a++

02/07/2008, 13h21
tchize_

Citation:

Envoyé par adiGuba

Salut,

Il faut revoir vos classiques les gars ;)
Depuis Java 5.0 et le type de retour covariant c'est possible !

Ben il a pas précisé la version de java hein :p Puis bon on fait que préciser la méthodologie (à savoir utiliser des getters / setter plutot qu'un field :D) (oui, je suis de mauvaise fois! :p)