Discussion :

[pjmorce]

Bonjour

La question que je me pose est simple.
En java il y a les interfaces qui sont utilisées pour obliger les classes qui les implémentent à posséder certaines méthodes avec certaines signatures et types de données retournées.

Je suis en train de développer une classe qui contient plusieurs méthodes. Je voudrait faire en sorte que toutes ces méthodes ne puissent retourner que des objets de type String. Si il y a une méthode qui retourne un int par exemple, la classe ne compilerait pas.

Est-ce possible de faire ceci mais sans avoir recours aux interfaces vu que si je veux créer de nouvelles méthodes je ne veux pas de restrictions à par celle ci (du type de retour)?

merci

[thelvin]

Non, rien de prévu pour ça en Java.
Je suis pas sûr de voir l'intérêt, d'ailleurs.

[pjmorce]

Bonjour,

Je vais essayer d'expliquer l'interet de ceci.
Je suis en train de développer une classe qui utilise "Java Reflection" (donc qui effectue l'appel de classes/méthodes en utilisant du code comme le suivant):

final Class cl = Class.forName(classname)
...
final Method mthd = cl.getMethod(method, par);

// We execute the method
final String result = (String) mthd.invoke(cl, paramsInput);

Les nom des classes et méthodes a exécutés sont obtenues à partir d'une base de données. Je voudrais faire en sorte que toutes les méthodes qui sont appelées soient obligées de retourner un objet de type String de façon à ce que la dernière ligne du code présenté ne génère pas d'erreur...

merci

[thelvin]

Passons sur la monstruosité de noms de méthodes stockés en base de données.

Donc, faire qu'une classe soit forcée de répondre aux contraintes d'un mécanisme extérieur, avec implémentation par réflexion.

Ce qu'il faut, ce n'est pas avoir des noms de méthodes, mais des noms de classe.

- Tu fais une interface :

Code :

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

1
2
3
4
5
public interface FaiseurDeTrucs {
 
  String faitDesTrucs(Param1 p1, Param2 p2);
 
}

Tu le fais implémenter par plein de classes, et c'est le nom de ces classes que tu stockes en BDD. Le nom de la méthode appelée est toujours le même, et l'interface exige qu'elle renvoie String.

[pjmorce]

Merci pour la réponse.

En fait dans ma BD je stock le nom de la classe ET le nom de la méthode car j'avais pensé à une architecture où dans une classe plusieurs méthodes pourraient exister.

Je ne trouve pas qu'avoir le nom des méthodes dans la BD soit une monstruosité (quelle est la différence avec le stockage du nom d'une classes?) mais bon, c'est une opinion que je respecte.

Je pense qu'en stockant seulement le nom de la classe et en utilisant une interface ça me résout le problème.

Merci beaucoup pour ton aide.

[hwoarang]

En fait dans ma BD je stock le nom de la classe ET le nom de la méthode car j'avais pensé à une architecture où dans une classe plusieurs méthodes pourraient exister.

C'est tres simple. Tu as 2 methodes. Soit tu fais comme tte l'a suggeré theelvin et tu imposes qu'une classe implemente une interface avec une seule methode (dans ce cas, comme il n'y a qu'une methode, seul le nom de la classe est important). Soit tu veux que tes classes puissent avoir des methodes non connues a l'avance et dans ce cas, il faut utiliser la reflexion pour regarder la signature de celles-ci et verifier qu'elles renvoient bien un String. Mais dans ce cas, c'est pas possible de le verifier a la compilation.

Je ne trouve pas qu'avoir le nom des méthodes dans la BD soit une monstruosité

Java est un langage qui essaye d'obliger les developpeurs à utiliser de "bonnes manieres", c'est à dire des objets, qui ont des attributs avec des visibilités différentes... Bref, en stockant une classe et une methode dans la base de données, tu t'obliges à te poser les questions qui t'ont amené à faire ce post. C'est pour ca que c'est une méthode à éviter (et je ne parle meme pas des mises à jour qui seront une galere meme pour toi donc pour un autre developpeur...). D'autant que je parierai ma chemise qu'il est possible de faire autrement. Mais bon, c'est toi qui connait tes contraintes.

quelle est la différence avec le stockage du nom d'une classes?

Effectivement, c'est pas terrible non plus. Mais au moins, si on trouve la classe en question, on est sur qu'elle possede la methode de l'interface et que celle ci renvoie un String. C'est ce qui ressemble le plus à ta demande initiale.

Je pense qu'en stockant seulement le nom de la classe et en utilisant une interface ça me résout le problème.

Mais ca t'oblige à t'assurer des parametres de tes methodes et des types renvoyés. Alors qu'avec la solution des classes qui implementent des interfaces, cette verification n'est pas necessaire. Et si tu a besoin de regrouper tes methodes ensemble, il suffirait de mettre les classes avec les methodes que tu veux regrouper dans un meme package.
Vu de l'extérieur, c'est comme si une classe représentait une methode et un package représentait une classe.


Et pour aladin1984, merci d'ouvrir ton propre post pasque venir pourrir celui de quelqu'un d'autre qui est encore en cours c'est pas sympa (sans parler que tu demandes de faire tes devoirs et que tu n'obtiendras surement pas de réponse sans montrer que tu as un minimum bossé mais ca, c'est une autre histoire)

[thelvin]

En fait dans ma BD je stock le nom de la classe ET le nom de la méthode car j'avais pensé à une architecture où dans une classe plusieurs méthodes pourraient exister.

Je m'en doutais, mais tu n'en as pas besoin. Si tu as besoin de séparer logiquement tes classes en groupes de classes, tu peux les mettre dans des packages différents.
Et toujours stocker le nom de la classe, avec son package.

Bon et si tes méthodes vont toujours par paires, fais en sorte que ton interface contienne deux méthodes, pas une. Ou 3 si c'est par triplets, ect.

(quelle est la différence avec le stockage du nom d'une classes?)

'fectivement y'en a pas.

Je ne t'ai pas dit comment tuer la monstruosité. Je l'ai ramenée dans ma tête à un truc que je considère plus sain (une conf' genre Spring applicationContext,) et qui pose aussi le problème dont tu parles.
Puis je résous ce problème-là, pas la monstruosité.

Je pense qu'en stockant seulement le nom de la classe et en utilisant une interface ça me résout le problème.

Oui.

[aladin1984]

Réalisation d'un détecteur d'Entités Nommées
Dans le domaine du Traitement Automatique des Langues pour la Recherche d'Information, la détection et le typage d'Entités Nommées constitue une tâche classique, pour laquelle des techniques tant symboliques (règles) que statistiques, voire mixtes, ont été développées. Dans le cadre de cet exercice, il vous est demandé de réaliser un module logiciel dénommé "Gazetteer", assurant principalement les fonctionnalités suivantes :
•identification d'Entités Nommées
◦par consultation d'un lexique
◦par application de cascades d'expressions régulières
•typage d'Entités Nommées
◦par consultation d'un lexique
◦par application de cascades d'expressions régulières.
Les deux fonctionnalités ci-dessus seront en réalité réalisées de manière conjointe, bien que pour des raisons de présentation elles soient ici distinguées.
En sus de ces fonctionnalités, le composant assurera les fonctionnalités suivantes :
•ouverture d'un fichier texte ;
•segmentation en unités linguistiques de base, dont vous déterminerez le type : paragraphes, phrases, mots graphiques, mots composés ;
•écriture de fichier texte structuré en XML, associé à une feuille de style CSS fournie.
Vous trouverez ci-dessous un schéma synthétique des traitements, ainsi que des exemples d'annotation automatique. Afin de réaliser ce module (dont vous élaborerez la structuration par vous-mêmes), une liste des entreprises du CAC40 ainsi que des dépêches de test, dans différents jeux d'encodage, vous seront fournies. D'autres ressources vous seront fournies afin, notamment, d'assurer une visualisation conviviale du fichier de sortie.
Dans le schéma ci-dessous, les composants à réaliser figurent en bleu, les composants et ressources fournis ne sont pas colorés.
L'ordre des traitements vous indique la logique générale des traitements à adopter pour un résultat optimal. Notamment, il est préférable de réaliser l'identification/typage des Entités Nommées "sûres" avant les autres, autrement dit de réaliser en premier l'annotation par consultation d'un lexique, avant celle par cascades d'expressions régulières.
Enfin, les deux flèches bidirectionnelles en bleu figurent les fonctions :
•de consultation des entrées du lexique et de récupération des annotations qui y figurent ;
•d'application des règles de détection et de typage exprimées par des expressions régulières.
Dans l'ensemble de votre réalisation, vous devrez vous efforcer d'adopter une logique de conception et d'implémentation mettant l'accent sur la modularité : vos classes doivent être le plus possible spécialisées, ainsi que vos méthodes (un traitement/une méthode). Pas de programme "monolithique", dont toutes les fonctionnalités sont codées dans une seule fonction "main" !
Vous prendrez soin de fournir les éléments de documentation suivants :
•un fichier README de base, explicitant en quelques lignes le but du programme, ainsi que les options et commandes ;
•un fichier openoffice explicitant vos choix de conception et d'implémentation, et présentant de façon synthétique les différentes fonctionnalités ;
•une javadoc explicitant le plus possible la signature des méthodes (nombre et type des arguments), leur valeur de retour et les fonctionnalités de chaque classe ; pour ce faire, vous intègrerez autant de commentaires javadoc (@param etc.) que nécessaire.
Vous n'oublierez pas de faire figurer dans l'en-tête de vos classes votre nom, la date de création, ainsi que la version de chaque classe. Vous adopterez la convention suivante, en termes de version :
•1.0 et supérieures : classe mature ;
•0.1 : classe en version expérimentale (alpha) ;
•0.5 et supérieures jusqu'à 0.9 : classe non mature mais que vous estimez suffisamment fiable.
Ces numéros de version sont indicatifs, ils sont à considérer comme des éléments de documentation que vous associez à chacune des classes. Ils présupposent, bien sûr, que vous aurez réalisé des tests afin d'évaluer le degré de maturité de vos classes.