Discussion :

[behess]

Bonjour,
je m'interroge sur l'aspect et la délégation : quid de ces technique dans Java ?
J'ai vu un truc intéressant dans Groovy a ce sujet : l'annotation @Delegate sur un champ. C'est super pratique ! On peut éventuellement redéfinir des méthodes déléguées qui sont semble-t-il alors appelées en lieu et place de la méthode du délègué. Quel gain en clareté et en maintenabilité !
Mais pourquoi diable n'est-ce pas standard ?

[tchize_]

parce que l'api java est déjà très grosse, parce que tout le monde n'a pas besoin de jouer avec les aspects, parce que rajouter à votre projet une librairie qui gère des fonctionnalités supplémentaire est en général facile est suffisant. Si vous n'avez pas assez avec l'api standard de java, dirigez vous vers l'api enterprise (mais c'est un p*** de tartine) ou faites du groovy. On ne peux pas tout mettre dans l'api de base.

[behess]

Certe, mais l'AOP est plus qu'un gadget ! et la délégation une technique plutôt classique en POO. Il est étonnant que cela ne fasse pas partie du langage ou d'une prochaine (ou lointaine vu le rythme actuel) évolution déjà décrite dans une JSR.
Si vous connaissez une API Java qui permet d'automatiser la delagation en JsE alors ça m'intéresse évidemment.

[tchize_]

Beaucoup de librairies disponibles autour de java ne sont pas "un gadget", ca n'empeche qu'on ne gonfle pas, actuellement, l'api java pour passer la jvm d'une grosse 60aine de M à plusieurs ceintaines

Maintenant, je connais pas d'api qui fasse de la délégation automatique, en général, je me contente de mettre ceci dans mon ide

Code :

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

1
2
3
4
 
public class MonTypeDeleguant implements unType{
    private unType delegate;
}

puis clic droit -> generate delegate methods

[behess]

c'est évidemment ce que je fais aussi mais ça obscurcit le code ! alors qu'un bête @Delegate en groovy rend le code si limpide... c'est vraiment dommage.
Voilà c'est tout, c'était juste un troll de plus. Gasp!

[behess]

Pour revenir sur ton intervention, je précise que je ne parlais pas au départ de librairie mais bien d'une intégration au langage. Depuis j'ai lu quelques articles a ce sujet, en particulier ceux évoquants "l'affaire" J++ de MS qui proposait une instruction delegate et qui, ayant été rejetée par Sun car hors specs, a provoque la création de C# et .Net ; j'ai également lu un autre article sur une proposition individuelle pour l'évolution de Java dans ce sens. ça me rassure : je ne suis pas le seul a râler sur ce sujet. Voilà un truc intéressant a rajouter pour Java (8?), non ?

[Edit]je précise en plus que je ne parle pas du delegate a la MS mais de la délégation de l'implementation d'un interfaces un champ implementant cette même interface.[/Edit]

(PS:peut être un modo devrait-il déplacer ce sujet là où on discute des JSR ou le l'aspect en partiulier ?)

[adiGuba]

Salut,

Depuis j'ai lu quelques articles a ce sujet, en particulier ceux évoquants "l'affaire" J++ de MS qui proposait une instruction delegate et qui, ayant été rejetée par Sun car hors specs, a provoque la création de C# et .Net ;

Ce n'est pas les delegates qui ont été rejeté, mais le J++ en lui même.
J++ était une implémentation de Java qui n'était pas conforme...
Il n'y avait pas seulement les delegates en plus, mais la suppression de certaines fonctions (RMI, JNI) et l'accès direct à l'API Win32 de Windows... ce qui en faisait un langage fortement lié à un OS !

En gros ils ont voulus reprendre Java à leurs compte et en faire une version "Windows only"

j'ai également lu un autre article sur une proposition individuelle pour l'évolution de Java dans ce sens. ça me rassure : je ne suis pas le seul a râler sur ce sujet. Voilà un truc intéressant a rajouter pour Java (8?), non ?

Il y a des propositions d'évolutions du langages sur a peu près tout

Mais l'intégration de ces évolutions peuvent prendre beaucoup de temps... voir ne jamais être mis en place...

Et depuis toujours Java n'est pas le langage aux multiples "features". Au contraire l'idée était de simplifier le langage afin qu'il soit rapidement compréhensible...


a++

(PS : le sujet est très bien dans ce forum ! - tu voudrais le mettre où ?)

[behess]

Merci pour ta précision. En effet J++ n'a jamais été Java compliant

Concernant la simplicité du langage, je ne suis pas contre. Simplement je préfère voir les bonnes pratiques du GoF facilitées par le langage.

Actuellement Java n'aide pas la bonne pratique primodiale qu'est "la composition est préférable à l'héritage" et quand on parle de composition dans ce cas on entend "délégation".

Je compte émettre un JSR sur ce sujet, on verra ce que ça donnera.

Pour ma part je verrais bien un mot clé "delegate" à placer devant une variable d'instance ou de classe dont le type est une interface implémentée par la classe ; en cas de conflit entre deux methodes identiques pour deux interfaces implémentées, le compilateur remonterait une erreur ; il faudra dans ce cas implémenter la methode et faire une délégation manuellement.

Cela dit, le top ce serait d'avoir la possibilité d'utiliser nativement les annotations pour la programmation par aspect, ce qui permettrait d'implémenter la délégation par un aspect, car je ne crois pas que ce soit faisable actuellement : il n'y a pas moyen d'intercepter les appels de méthodes non implémentées via une annotation, et de toute manière, il faudrait que le compilateur accepte les implémentations incomplètes d'interfaces, ce qui est inconcevable sans un indicateur spécifique.

[behess]

Je vois que tu as pondu un article sur le projet Coin et les évolutions de Java 7.

A ce propos, la JSR 292 et son InvokeDynamic pourrait-elle être mise à contribution ? J'imagine qu'il y a un lien derrière ça, mais je ne vois pas où.

[professeur shadoko]

Concernant la simplicité du langage, je ne suis pas contre. Simplement je préfère voir les bonnes pratiques du GoF facilitées par le langage.

Actuellement Java n'aide pas la bonne pratique primodiale qu'est "la composition est préférable à l'héritage" et quand on parle de composition dans ce cas on entend "délégation"..

<provoc délibérée>
pour moi c'est plutot l'inverse: c'est aux patterns de s'adapter aux paradigmes d'un langage .
</provoc délibérée>

pour reprendre le cas de la délégation:
- il est dans la philosophie de Java d'être le plus explicite possible (au risque d'être trop bavard)
- dans la délégation le principe fondamental est que l'on ne reprend pas toutes les méthodes de l'objet cible (il faut donc préciser les méthodes que l'on choisi de déléguer)
- certaines méthodes s'appuient sur la méthode d'origine de l'objet cible mais en "décorant" - en rajoutant du code- et il faut donc l'écrire.

bien sûr on peut objecter que ça devient pénible si on fait une délégation sur une mégatonne de méthodes. mais dans le cas le plus général (quelques méthodes) je préfère le code explicite.

Donc le mieux étant l'ennemi du bien je préfère éviter les crises d'acute featuritis (machin-truc-chosite aiguë) -malheureusement on sent que beaucoups poussent Java dans cette direction -

[tchize_]

et rappelons qu'un bon IDE va vous écrire les code des delegates en 3 secondes Restera plus qu'à remplir à où vous voulez altérer.

[behess]

Je passe sur la provocation

pour reprendre le cas de la délégation:
- il est dans la philosophie de Java d'être le plus explicite possible (au risque d'être trop bavard)

C'est plutôt explicite de dire qu'on va déléguer à un autre le boulot non ?
C'est aussi plus lisible que de faire 10 fois (pour 10 methodes différentes) :

Code :

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

1
2
3
object message(args){
   return delegue.message(arg);
}

- dans la délégation le principe fondamental est que l'on ne reprend pas toutes les méthodes de l'objet cible (il faut donc préciser les méthodes que l'on choisi de déléguer)

Dans ce cas on pourrait avoir plutôt une syntaxe du genre :

Code :

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

object message(args) delegate_to champDelegue;

ça ne me gênerait pas plus que ça, c'est quand même plus lisible que l'exemple rébarbatif ci-dessus !

- certaines méthodes s'appuient sur la méthode d'origine de l'objet cible mais en "décorant" - en rajoutant du code- et il faut donc l'écrire.

certaines méthodes. Rien n'empêche d'implémenter réellement les méthodes, la délégation ne fonctionnerait que pour ce qui n'est pas implémenté évidemment.

[behess]

et rappelons qu'un bon IDE va vous écrire les code des delegates en 3 secondes Restera plus qu'à remplir à où vous voulez altérer.

C'est une redite.

Précisons qu'en fait, si ton interface varie, tu dois regénérer/modifier tes méthodes de délégation... dans toutes les classes qui délèguent...

Tu me diras que la conception n'avait qu'à être plus aboutie, ou que l'IDE n'a qu'à être mieux fait... ok c'est vrai.

Mais n'empêche que concrêtement, ce n'est pas la façon la plus smart de gérer des délégations pour un langage objet, c'est tout !

[behess]

Dans ce cas on pourrait avoir plutôt une syntaxe du genre :

Code :

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

object message(args) delegate_to champDelegue;

ça ne me gênerait pas plus que ça, c'est quand même plus lisible que l'exemple rébarbatif ci-dessus !

Je reviens là dessus, en fait ça revient au même en ce qui concerne la résistance à la variation, la solution "tout par défaut" est bien plus smart.

(je reprécise que je n'ai rien inventé, ceci n'est donc pas de l'autocongratulation, et que j'ai vu ça dans Groovy)

[tchize_]

C'est une redite.

Précisons qu'en fait, si ton interface varie, tu dois regénérer/modifier tes méthodes de délégation... dans toutes les classes qui délèguent...

Je trouve surtout que c'est beaucoup de chipos pour du pas grand chose. En 6 ans, j'ai rarement du faire de la délégation à grande échelle sur des interfaces qui en plus évoluaient dans le temps. Je vous très peu d'interêt, personellement, dans cette pattern, puisque les seuls usage que je leur trouve, c'est pour écrire des wrappers, et jai rarement eu besoin de wrappers.

[behess]

J'aime pas non plus les chipos

Mais bon, c'est juste une des bonnes pratiques de base de la POO.

Pourquoi le GoF conseille la composition (et la délégation de fait) plutôt que l'héritage ?

Que tes conceptions ne soient pas facilement évolutives ne te donne pas forcément raison

Moi j'utilise pas mal la délégation, que je trouve plus souple que l'héritage, ce qui permet de faire du développement agile assez facilement.

Mais il est effectivement des cas où je préfère un petit héritage qui répond mieux à un besoin ponctuel de factorisation de structure.

Je pense qu'on ne clôturera pas ce débat ici, aussi je préfère que la discussion reste concentrée sur la recherche de solutions, merci

[professeur shadoko]

Code :

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

1
2
3
object message(args){
   return delegue.message(arg);
}

Dans ce cas on pourrait avoir plutôt une syntaxe du genre :

Code :

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

object message(args) delegate_to champDelegue;

ça ne me gênerait pas plus que ça, c'est quand même plus lisible que l'exemple rébarbatif ci-dessus !

Pendant des années j'ai travaillé sur la conception de langages de programmation: un point qui me frappe est que chacun trouve midi à sa porte et donc que l'ergonomie de la lecture reste quelque chose de soumis à une évaluation très personnelle -c'est sympa mais pas très démonstratif : j'ai vu des gens qui me faisait l'éloge de la lisibilité du langage APL ! (pour ceux qui connaissent c'est une conclusion plutôt surprenante!).
Donc je ne me prononce pas sur l'avis ci-dessus mais comme le dis tchize_ le jeu en vaut-il la chandelle?

OOps! désolé Behess je n'avais pas vu ton message précédent. pardon pour cette disgression.

[behess]

Pour aller dans votre sens (ne pas modifier le langage), j'aurais peut-être une idée, mais je ne sais pas si c'est faisable...

En fait pourquoi ne pas utiliser les annotations et une génération par APT ?

Par contre il ne faudrait pas que ça modifie ma classe annotée, mais la remplace au moment de la compilation...

(du genre, j'ai un fichier maclasse.java et ça me génèrerait un fichier maclasse$delegation.java qui prendrait sa place à la compilation, avec les méthodes de délégation générées)

ça collerait à nos deux points de vu simultanément

Est-ce faisable ?

[behess]

Je clôture cette discussion et j'en ouvre une autre spécifique à cette solution pour affiner.