Interfaces Graphiques : Que pensez vous de l'héritage multiple en JavaFX ?
Le 2009-06-29 19:41:32, par guitariste, Membre régulier
salut.
J'ai appris que javafx permettait l'héritage multiple. Je voulais savoir comment elle a résolu les problèmes classiques qui sont liés à cette pratique !
Par exemple, si les deux classes mères contiennent deux méthodes avec le même nom ?
Merci
J'ai appris que javafx permettait l'héritage multiple. Je voulais savoir comment elle a résolu les problèmes classiques qui sont liés à cette pratique !
Par exemple, si les deux classes mères contiennent deux méthodes avec le même nom ?
Merci
-
bouyeRédacteur/ModérateurCa les resout mal et de maniere pas vraiment bien definie (c'est le flou officiel) dans les versions 1.0 et 1.1/1.1.1*.
La version 1.2 introduit l'usage du mot cle mixin a placer sur les autres classes meres** et permet enfin d'appeler super.nomDeMethodeOuFonction().
**On pouvait heriter d'un nombre infini d'interfaces et de classes JavaFX, le nombre d'heritages de classe Java etait limite a 1 il me semble.
**On ne peut donc heriter d'une seule et unique classe JavaFX et Java directement et d'un nombre infini de mixing JavaFX ou d'interfaces. Le nombre d'heritage de classe Java doit toujours etre limite a 1 vu que le mot cle mixin n'existe pas dans ce language.
Pour le reste, je n'ai pas pousse plus loin mes investigations quant a l'heritage en diamant ou les collisions de nom dans cette nouvelle version (trop de problemes dans les version precedentes font que j'ai vite abandonne le sujet : VIVE LA DELEGATION !).le 30/06/2009 à 2:19 -
PhiLhoMembre régulierExemple :
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
30def individual = Contact { firstName: "Julien", lastName: "Jabbot", role: "Senior Developer" }; //~ individual.printInfo(); //~ println(individual.id); (individual as Person).printInfo(); (individual as Employee).printInfo(); println("{(individual as Person).id}"); println("{(individual as Employee).id}"); mixin class Person { var firstName = "Fabien"; var lastName = "Flubbler"; var id = 89771; function printInfo() { println("{firstName} {lastName}"); } abstract function isAlive(); } mixin class Employee { var role = "Project Manager"; var id = 11666342; function printInfo() { println("{role}"); } } class Contact extends Person, Employee { override function isAlive() { return Person.id > 0; } }
Je crois que la solution est qu'un des deux champs sera caché par l'autre...
Comme dit bouye, et comme un peu partout dans JavaFX, c'est pas parfait et en cours d'amélioration...
Ce qui est marrant, c'est qu'on a encore des classes abstraites, qui font maintenant bien double emploi avec les mixins (en plus limité !).le 26/08/2009 à 17:50 -
nicolofontana12InscritC'est vraiment & evidement le derangement que peut avoir l'heritage simple.
En effet c'est vrai normal qu'un enfant peut heriter de sa mere et son pere d'ailleurs s'il s'agit d'un enfant unique. Supposon que sa mere à un villa au Mali et son pere un autre à Moscone. Je peux bel et bien heriter de ses deux villa.
Mais un probleme persiste, comme il est heritier, les barbes etant public et le sein protected, alors il peut avoir les barbes de son pere et les seins de sa mere.
La on se retrouve devant un autre Michael Jackson. C'est ce qui est frequent en C++.
C'est vrai que ca limite effetictement java mais les interfaces resolvent la plupart de temps ce probleme.
Enfin c'etait juste pour detendre le debat.le 28/08/2009 à 12:00 -
galienMembre avertiComme mon grand père le disait, si ma tante en avait, l'héritage serait plus simple...le 28/08/2009 à 16:44
-
bouyeRédacteur/ModérateurAllez hop, un petit article sur le sujet : http://java.sun.com/developer/techni.../javafx/mixin/
Je comprend tout a fait qu'on ne puisse pas faire cela :Code : 1
2var m:MyMixin = new MyMixin(); // ILLEGAL. COMPILER ERROR.
Code : 1
2
3
4var m:MyMixin = MyMixin { // ILLEGAL. COMPILER ERROR. variable1: "Hello Again" variable2: "World" }
le 31/08/2009 à 2:04 -
PhiLhoMembre régulierAh, bah, JavaFX n'est pas Java (je suppose que tu as remarqué...) et les mixins semblent être un croisement étrange entre interfaces (qui ne peuvent pas être instanciées, et peuvent être combinées) et classes abstraites (qui peuvent être instanciées en fournissant les méthodes manquantes).
Donc cette restriction ne me choque pas (si on se place du côté "interface"mais je comprends ta démarche (du côté "classe abstraite" .
Je ne suis pas fana du concept des classes anonymes en Java, c'est sans doute pour ça que je n'ai jamais pensé à essayer ça...le 31/08/2009 à 10:33 -
bouyeRédacteur/ModérateurFaudrait que je revérifie (voir plus bas) mais il me semble qu'on peut tout instancier de cette manière en JavaFX SAUF les mixins donc je vois pas pourquoi on ne peut pas faire ainsi. Rappel il ne s'agit pas d'une simple instanciation mais de la création d'une classe concrète anynome et donc c'est plutot stupide de ne pas permettre de le faire sur des mixin.
Code : 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import javax.swing.AbstractAction; // Interface. def actionListener:ActionListener = ActionListener { public override function actionPerformed(e:ActionEvent):Void { } } // Classe abstraite. def action:AbstractAction = AbstractAction { public override function actionPerformed(e:ActionEvent):Void { } }
le 31/08/2009 à 11:29 -
PhiLhoMembre régulierTu peux instancier des classes abstraites, bien sûr, mais pas des interfaces. Si les concepteurs voient les mixins comme ces dernières, ils interdisent leur instanciation. Soit c'est volontaire pour cette raison, soit il y a problème technique interdisant cette opération, soit ils n'y ont simplement pas pensé. Dans ce dernier cas, rien n'empêche un petit saut à Jira pour le suggérer... :-)
Classes anonymes en JavaFX : c'est vrai, mais elles sont "cachées", on s'en fiche. Ce qui m'ennuie avec elles en Java, c'est qu'on créée une classe seulement pour enrober une petite fonction, et la syntaxe est lourde. Au moins, en JavaFX, on peut assigner une fonction directement, c'est plus proche de JavaScript et autres langages dynamiques.le 31/08/2009 à 16:57 -
bouyeRédacteur/ModérateurEuh as-tu au moins lu le code que j'ai poste ?le 31/08/2009 à 23:05
-
PhiLhoMembre régulierDoh ! Que d'un œil, probablement endormi, j'en ai peur.
Désolé.
En fait, je crois avoir confondu ActionListener (une interface) avec MouseAdapter (une classe abstraite avec des méthodes concretes...) ou je ne sais quoi. Bref, je me suis planté, mais cela gravera la leçon dans ma mémoire... :-Ple 01/09/2009 à 10:12