Recherche Aide Java UML MessageDigest
comeochris
Messages postés
51
Date d'inscription
lundi 23 mai 2005
Statut
Membre
Dernière intervention
19 octobre 2014
-
14 mars 2006 à 20:16
verdy_p Messages postés 202 Date d'inscription vendredi 27 janvier 2006 Statut Membre Dernière intervention 29 janvier 2019 - 25 mars 2009 à 07:06
verdy_p Messages postés 202 Date d'inscription vendredi 27 janvier 2006 Statut Membre Dernière intervention 29 janvier 2019 - 25 mars 2009 à 07:06
5 réponses
sheorogath
Messages postés
2448
Date d'inscription
samedi 21 février 2004
Statut
Modérateur
Dernière intervention
29 janvier 2010
17
14 mars 2006 à 20:28
14 mars 2006 à 20:28
heuuu plus clairement c'est quoi ton probleme ?
"n'est pas mort ce qui semble a jamais dormir et en d'etrange temps meme la mort peut mourrir"
"n'est pas mort ce qui semble a jamais dormir et en d'etrange temps meme la mort peut mourrir"
comeochris
Messages postés
51
Date d'inscription
lundi 23 mai 2005
Statut
Membre
Dernière intervention
19 octobre 2014
1
14 mars 2006 à 20:44
14 mars 2006 à 20:44
En fait, j'aimerais parler de mon code avec quelqu'un qui "touche" afin de savoir s'il est possible de l'optimiser.
;-)
;-)
sheorogath
Messages postés
2448
Date d'inscription
samedi 21 février 2004
Statut
Modérateur
Dernière intervention
29 janvier 2010
17
14 mars 2006 à 20:46
14 mars 2006 à 20:46
a la base ici on touche tous plus ou moins mais je ne trouve pas ton poste assez clait pour te rpondre
"n'est pas mort ce qui semble a jamais dormir et en d'etrange temps meme la mort peut mourrir"
"n'est pas mort ce qui semble a jamais dormir et en d'etrange temps meme la mort peut mourrir"
Twinuts
Messages postés
5375
Date d'inscription
dimanche 4 mai 2003
Statut
Modérateur
Dernière intervention
14 juin 2023
111
14 mars 2006 à 21:47
14 mars 2006 à 21:47
Salut,
idem que sheorogath de plus je trouve vachement dévalorisant pour les
gens qui ne maitrise pas super super java d'arriver sur un poste disant
je veux des gens qui touche sachant que toutes les idée aussi bonnes
qu'elles puissent etre ne sont pas toujours le produit d'un expert
WORA
idem que sheorogath de plus je trouve vachement dévalorisant pour les
gens qui ne maitrise pas super super java d'arriver sur un poste disant
je veux des gens qui touche sachant que toutes les idée aussi bonnes
qu'elles puissent etre ne sont pas toujours le produit d'un expert
WORA
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
verdy_p
Messages postés
202
Date d'inscription
vendredi 27 janvier 2006
Statut
Membre
Dernière intervention
29 janvier 2019
25 mars 2009 à 07:06
25 mars 2009 à 07:06
Une "factory" en Java c'est une méthode de classe (sont statique) qui sert à retourner une instance d'un objet, non nécessairement unique et réutilisable, construite avec un certain nombre de paramètres. La factory la plus simple en Java est l'opérateur "new" (avec en paramètre la classe et ses paramètres), mais cette factory ne permet pas la réutilisation ni la préinstanciation à l'avance.
En général, une factory se complète d'un cache des instances déjà construites, et peut en construire un certain nombre à l'avance dans un "pool". La factory peut aussi vérifier un certain nombre de contraintes et déterminer la classe réellement à instancier parmi plusieurs supportant une interface commune. Si une factory retourne des instances réutilisables, celles-ci doivent être soit non mutables (par exemple pour une factory de String) soit synchonisées; sinon il n'est pas nécessaire de gérer un cache.
Globalement c'est la factory qui est responsable de déterminer la politique d'instanciation d'un ensemble de classes supportant une même interface ou dérivées d'une même classe de base, et est chargée de déterminer l'implémentation à utiliser en fonction des contraintes données. Elle sert donc à séparer et rendre inivisible ces implémentations diverses, pour que le code qui emploie la factory ne soit pas dépendant de ces implémentations diverses.
Dans ton contexte, si on te demande une factory, ce devrait donc être une fonction retournant une instance de type MessageDigest (voire MessageDigestSPI) en fonction de deux paramètres: le nom de l'algorithme de hachage et la source des algorithmes (un provider JCE par exemple, ou une classe interne implémentant directement l'interface MessageDigestSPI). Il n'est sans doute pas nécessaire pour ta factory de gérer un "pool" mais il lui appartient de gérer le chargement des providers et leur mise en cache, ainsi que de gérer les exceptions si un algorithme n'est pas implanté dans un des providers. La classe contenant le factory devrait êre capable d'énumérer les providers disponibles, ou de les charger si nécessaire s'ils ne sont pas déjà préchargés dans le classpath actuel.
Ensuite, ton appli de test emploiera cette métgode d'énumération des providers pour énumérer aussi les algos de hachage qu'ils supportent. Et proablement stocker le tout dans des tables de hachage simples; puis il parcourera la liste globale des algorithmes, et pour chacun les instanciera successivement avec chacun des providers (pour les comparer) au moyen de ta factory. Il ne te rest elalors plus qu'à "nourrir" ces instances avec les données de test, et rerourner le Digest obtenu, à l'afficher et le comparer avec les Digests obtenus pour le même algorithme de hachage par d'autres providers, et à effectuer des mesures de performance (en nourissant avec un contenu identique pour tous les providers, mais assez volumineux pour que la mesure de performance soit significative).
Ce qui est important dans ce qui t'est demandé est bien d'isoler le programme de test des spécificités de chacun des fournisseurs utilisés, en les forçant à utiliser une interface commune (et en les adaptant au besoin, avec une classe utilitaire).
Le principe des "factory" est bien cette isolation (en général les programmes de test et de comparaison ou sélection de fournisseurs disponibles adorent utiliser de telles factories car cela facilite le déploiement final des applications testées, avec un choix plus large d'implémentations adapté à chaque plateforme finale). C'est la factory qui masque tous ces détails et simplifie leur sélection.
En général, une factory se complète d'un cache des instances déjà construites, et peut en construire un certain nombre à l'avance dans un "pool". La factory peut aussi vérifier un certain nombre de contraintes et déterminer la classe réellement à instancier parmi plusieurs supportant une interface commune. Si une factory retourne des instances réutilisables, celles-ci doivent être soit non mutables (par exemple pour une factory de String) soit synchonisées; sinon il n'est pas nécessaire de gérer un cache.
Globalement c'est la factory qui est responsable de déterminer la politique d'instanciation d'un ensemble de classes supportant une même interface ou dérivées d'une même classe de base, et est chargée de déterminer l'implémentation à utiliser en fonction des contraintes données. Elle sert donc à séparer et rendre inivisible ces implémentations diverses, pour que le code qui emploie la factory ne soit pas dépendant de ces implémentations diverses.
Dans ton contexte, si on te demande une factory, ce devrait donc être une fonction retournant une instance de type MessageDigest (voire MessageDigestSPI) en fonction de deux paramètres: le nom de l'algorithme de hachage et la source des algorithmes (un provider JCE par exemple, ou une classe interne implémentant directement l'interface MessageDigestSPI). Il n'est sans doute pas nécessaire pour ta factory de gérer un "pool" mais il lui appartient de gérer le chargement des providers et leur mise en cache, ainsi que de gérer les exceptions si un algorithme n'est pas implanté dans un des providers. La classe contenant le factory devrait êre capable d'énumérer les providers disponibles, ou de les charger si nécessaire s'ils ne sont pas déjà préchargés dans le classpath actuel.
Ensuite, ton appli de test emploiera cette métgode d'énumération des providers pour énumérer aussi les algos de hachage qu'ils supportent. Et proablement stocker le tout dans des tables de hachage simples; puis il parcourera la liste globale des algorithmes, et pour chacun les instanciera successivement avec chacun des providers (pour les comparer) au moyen de ta factory. Il ne te rest elalors plus qu'à "nourrir" ces instances avec les données de test, et rerourner le Digest obtenu, à l'afficher et le comparer avec les Digests obtenus pour le même algorithme de hachage par d'autres providers, et à effectuer des mesures de performance (en nourissant avec un contenu identique pour tous les providers, mais assez volumineux pour que la mesure de performance soit significative).
Ce qui est important dans ce qui t'est demandé est bien d'isoler le programme de test des spécificités de chacun des fournisseurs utilisés, en les forçant à utiliser une interface commune (et en les adaptant au besoin, avec une classe utilitaire).
Le principe des "factory" est bien cette isolation (en général les programmes de test et de comparaison ou sélection de fournisseurs disponibles adorent utiliser de telles factories car cela facilite le déploiement final des applications testées, avec un choix plus large d'implémentations adapté à chaque plateforme finale). C'est la factory qui masque tous ces détails et simplifie leur sélection.
