Discussion :

[scheme]

Bonjour à Tous, j'ai une architecture qui a environ cette structure:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
class A{
    public A() {}
    public A(double, enum) {}
    //J'ai beaucoup d'autres constructeurs
}
 
abstract class B extends A{
    public B(double, enum) { super(double, enum); }
}
 
class C extends B{
    public C(double, enum) { super(double, enum); }
}

Je n'ai pas tout montré mais en gros, ça m'embête de devoir répéter tous les constructeurs de A dans B pour pouvoir l'utiliser depuis C, du coup j'aimerais savoir s'il y a moyen d'appeler directement le constructeur de A depuis C, sans passer par super ?

Merci d'avance

[adiGuba]

Salut,


Non il faut passer par super...

a++

[scheme]

Salut ça veut dire qu'il faut obligatoirement que je redéfinisse tous mes constructeurs de A dans B ? :-(

[adiGuba]

Oui...


a++

[scheme]

C'est un peu à chier comparé à C++ non ? ...

[adiGuba]

A titre tout à fait personnel c'est plutôt l'approche "Orienté Objet" du C++ qui est "à chier"...

a++

[scheme]

Qu'est-ce qui te fait dire ça ?

[thelvin]

Bah, c'est simple : un objet ne peut pas à la fois étendre une classe, et se passer d'appeler un de ses constructeurs (ce que permet C++, en substance.)

C'est l'un ou c'est l'autre, pas les deux à la fois.

(Après, peut-être qu'un raccourci pour dire "définir un constructeur pour chacun des constructeurs de ma classe mère, avec la même signature et qui se contente d'appeler super dessus," pourrait servir dans certains cas de POJOs très simples et bien organisés.)

[BugFactory]

Sous Eclipse : clic droit, source, generate constructors from superclass.

[scheme]

Je ne vois pas le problème d'appeler le constructeur de A depuis C, je trouve que c'est plus une limitation qu'autre chose de ne pouvoir appeler que le constructeur de la classe directement héritée.

[adiGuba]

Qu'est-ce qui te fait dire ça ?

Je ne trouve pas cohérent que l'on puisse appeler directement le constructeur de la classe "grand parent".

a++

[SucreGlace]

Je ne vois pas le problème d'appeler le constructeur de A depuis C, je trouve que c'est plus une limitation qu'autre chose de ne pouvoir appeler que le constructeur de la classe directement héritée.

Dans ton cas, où les constructeurs de B ne contiennent aucun code, tu ne vois pas le problème.
Mais supposons que B initialise des données dans son constructeur, alors C ne pourrait pas se permettre de court-circuiter le constructeur de B...

Code :

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

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
class A
{
	public final int a;
 
	public A(int a)
	{
		this.a = a;
	}
 
}
 
class B extends A
{
	public final int b;
 
	public B(int a, int b)
	{
		super(a);
		this.b = b;
	}
 
}
 
class C extends B
{
	// on ne peut pas appeler directement un constructeur de A, autrement B.b ne serait jamais initialisé
}

[scheme]

Disons qu'à la différence de Java, C++ offre la liberté de le faire, au développeur de bien s'en servir. Il est vrai que plus de liberté engendre plus de possibilité de faire des erreurs.

Moi je suis partisan de cette liberté, mais je comprend qu'on puisse ne pas l'être.

[adiGuba]

Dans ce cas précis ces "libertés" cassent le principe d'encapsulation.

Au niveau de la classe "B" tu ne peux pas définir si les classes filles auront accès ou pas au paramètres du constructeur du parent. Que se passe-t-il si tu veux utiliser une valeur spécifique dans "B" mais qu'une classe fille utilise directement une autre valeur ???


a++

[scheme]

Tu pourrais illustrer ce que tu dis par un bout de code stp ? Je comprendrais mieux de quoi tu veux parler

[thelvin]

Disons qu'à la différence de Java, C++ offre la liberté de le faire, au développeur de bien s'en servir. Il est vrai que plus de liberté engendre plus de possibilité de faire des erreurs.

Moi je suis partisan de cette liberté, mais je comprend qu'on puisse ne pas l'être.

+1 sur ce que dit adiGuba sur le principe d'encapsulation.

Mais de manière générale, Java fait très souvent le choix de conception de limiter les libertés du programmeur pour prévenir certaines erreurs qui peuvent être prévenues au compile-time. (Et d'autres ASAP au runtime.)

C'est intrinsèque au langage, c'est un fait. C'est loin d'être limité à ce seul exemple.

Tu pourrais illustrer ce que tu dis par un bout de code stp ? Je comprendrais mieux de quoi tu veux parler

SucreGlace l'a déjà fait au-dessus.

[adiGuba]

Un exemple à la con : dans B je veux fixer certaines valeurs du parent :

Code :

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

1
2
3
4
5
class B extends A {
	public B() {
		super(0.0 ENUM_VALUE);
	}
}

Afin que toutes les classes filles utilisent ces valeurs.


Comment ferais-tu cela en C++ si les classes filles peuvent appeler directement le constructeur du "grand parent" ?


a++

[scheme]

Effectivement dans ce cas ce ne serait pas une bonne chose d'appeler directement le constructeur de A depuis C.

Je ne dis pas qu'il faut le faire systématiquement, mais que c'est bien pratique d'en avoir la possibilité, dans le cas que j'ai cité tout au début du topic par exemple.

A l'usage, ça évite de devoir recopier le constructeur plusieurs fois, de faire des super() partout, et de passer en copie les collections plusieurs fois au lieu d'une seule.

[thelvin]

et de passer en copie les collections plusieurs fois au lieu d'une seule.

À moins que tu le demandes en le programmant explicitement, les collections (et tous les objets) ne seront pas copiées, mais passées telles que.

[scheme]

C'est bon à savoir

Et pour les objets, ils sont passés par copie ou par référence ?