juin
2006
Il y a deux semaines, je vous présentais une petite API permettant de gérer la configuration d’une application avec les Annotations, et il se trouve que Romain Guy a eu une idée similaire, puisqu’il présente Fuse, une petite librairie destinée à modifier les ressources des interfaces graphiques.
Le procédé est assez proche (les attributs d’une instance de classe sont automatiquement modifiés selon les valeurs d’un fichier de propriété), mais plus adapté aux interfaces graphiques (gestion des couleurs, images, etc…).
Je vous invites à y jeter un coup d’oeil si la langue de Shakespeare ne vous fais pas peur : Fuse, UI Oriented Resource Injection.
Gageons que ce type de procédé sera de plus en plus courant, en particulier avec Mustang qui permettra d’utiliser APT avec le compilateur standard…
6 Commentaires + Ajouter un commentaire
Tutoriels
Discussions
- jre 1.5, tomcat 6.0 et multi processeurs
- [REFLEXION] Connaitre toutes les classes qui implémentent une interface
- Difference de performances Unix/Windows d'un programme?
- L'apparition du mot-clé const est-il prévu dans une version à venir du JDK?
- [ fuite ] memoire
- Classes, méthodes private
- Possibilité d'accéder au type générique en runtime
- Recuperation du nom des parametres
- Définition exacte de @Override
Je n’ai pas dit qu’APT etait complexe, mais que ce n’etait pas aussi simple que les annotations de type runtime
Quant a l’injection de valeurs dans des champs prives je trouve qu’en fait cela renforce les regles de la POO puisque tu n’exposes pas ton champ inutilement (que ce soit avec public ou un setter). Effectivement ce n’est pas tres « propre » a premiere vue mais le gain est beaucoup plus important.
Oui même sans voir vu ton code complet, je me doutait bien qu’on devait utiliser les mêmes procédés
>> Je vois que tu as aussi pris le parti de « contourner » la visibilite private
Oui j’avais vu cela dans la gestion des annotations de JDBC 4.0 (cf. le lien dans mon premier commentaire). Au début cela ne m’a pas paru très « propre » puisque cela « cassait » un peu les règles de POO…
Mais en fait dans le context d’une initialisation d’un objet je trouve cette solution tout à fait correct et avantageuse…
Quand à APT, ce n’est pas si complexe que cela…
Le seul frein pour le moment (à mon avis) c’est que cela implique l’utilisation du compilateur apt à la place de javac (et que peux d’EDI peuvent les gérer), mais il me semble que ce sera plus le cas avec Mustang (mais je n’ai pas encore testé cela).
a++
Edit : je viens de voir ton API et c’est en effet tres tres similaire Je vois que tu as aussi pris le parti de « contourner » la visibilite private et j’aime aussi beaucoup ton approche de retourner une liste des erreurs. En gros c’est comme si j’avais ecris un parser pour ta bibliotheque. Pour te donner une meilleure idee de ma lib, voila un exemple de TypeLoader (== tes Parser) :
class BooleanTypeLoader extends TypeLoader { <br />
BooleanTypeLoader() { <br />
super(boolean.class, Boolean.class); <br />
} <br />
<br />
@Override <br />
public Boolean loadType(String name, String value) { <br />
return Boolean.parseBoolean(value); <br />
} <br />
} <br />
Je suis d’accord avec toi adiGuba, il n’y a pas de raison que ca devienne le foutoir. C’est d’autant plus vrai qu’APT n’est pas si simple a utiliser et qu’il demande du travail pour l’integrer dans le workflow d’une equipe et/ou d’un projet existant. Les annotations utilisees a l’execution, comme dans mon API, requierent pour leur part l’utilisation de la reflection qui peut s’averer couteuse dans certains cas. En outre, il faut un mecanisme d’analyse quelque part et le lancement de ce processus peut souvent etre realise a un moment ou l’appelant dispose deja des informations necessaires. Quand je vois par exemple ce que les annotations permettent de faire avec les web services dans Mustang, je trouve que les avantages enfoncent de loin les inconvenients.
C’est sûr qu’on risque de voir ce type d’API se multiplier…
Pour les tests unitaires par exemple, il y a déjà TestNG qui utilise les annotations, et ce devrait être le cas également de la version 4 de JUnit…
A l’inverse Mustang intègrera en standard des annotations pour gérer le mapping objet/relationnel de JDBC :
Mustang, JDBC 4.0 et les Annotations. Ces annotations peuvent être géré directement par le driver JDBC, ou par la JVM le cas échéant…
Mais ce n’est pas parce qu’il existera plusieurs API que cela va forcément devenir un gros foutoir… au contraire cela laissera un choix plus vaste aux developpeurs…
Une chose est sûr, il va falloir s’habituer aux annotations
A la fois je trouve ca tres bien, mais j’ai de plus en plus peur de ce que vont devenir les annotations. Si chacun developpe dans son coin une api annotation pour les gui, les @todo (ca me rapelle un bon article ), le log, l’aop, jdbc, la persistance objet etc… ca va devenir un vrai foutoir.
J’espere que ca va se standardiser au maximum.