9
votes

Déterminer si une méthode statique est purement fonctionnelle

donné un java.lang.reflect.method est là pour déterminer si la méthode est purement fonctionnelle (c.-à-d. Compte tenu de la même entrée, elle produira toujours la même sortie et elle est apatride. En d'autres termes, la fonction ne dépend pas de son environnement)?


10 commentaires

Pourquoi ne le testez-vous pas avec un test d'unité? Remplissez-le avec des données aléatoires et voyez ce qui se passe. Comment voulez-vous récupérer ce résultat?


Vous avez du mal à trouver une solution 100% efficace


S'il vous plaît clarifier: Pourquoi faites-vous cela? Possédez-vous tout le code que vous avez l'intention d'appliquer ce test? Voulez-vous tester un code externe (API)?


Imaginez que vous écriviez une fonction API qui prend un objet de méthode et renvoie un booléen indiquant si la méthode est purement fonctionnelle.


Possédez-vous tout le code que vous avez l'intention d'appliquer ces tests? ¹


Oui. Hmm .. Pour quoi?


Je ne sais pas si cela est possible, mais demandez à voir si une personne ayant une expertise plus peut aider. Serait-il possible de prendre juste le code de la fonction et de le mettre dans une machine virtuelle où il n'avait aucune autorisation de sécurité pour affecter l'état de l'application? Encore une fois, je ne connais pas assez de choses comme SecurityManager, donc cela peut être complètement indûble. Mais l'idée est généralement de mettre le code dans un conteneur isolé (VM, etc.), qui applique les règles nécessaires et voir si des violations se produisent.


Ne serait-ce pas équivalent au problème d'arrêt?


Donc, si vous possédez tout le code que vous testez, pourquoi ne savez-vous pas s'il est fonctionnel ou non?


Si vous possédez tout le code que vous avez l'intention de tester, accédez à l'approche @sotirosdelimanolis. Il suffit d'ajouter une annotation (ou configurez-vous quelque part quelque part) si les méthodes sont fonctionnelles ou non.


5 Réponses :


9
votes

Non, il n'y a aucun moyen de le faire.

Réflexion ne vous permet pas d'inspecter le code réel derrière la méthode.

Et même si cela est possible, l'analyse réelle serait probablement ... difficile, de dire le moins.


2 commentaires

Vous connaissez-vous de tout document qui a discuté du calcul de ce type de problème? Et merci pour la réponse. :)


@Eonetwothree: Nope, je ne sais pas de cela. Intuitivement, je dirais que vous courez à proximité de la région de Halse-Problème ici, mais vous pouvez probablement aller assez loin en permettant de "ne pas savoir" et de le traiter comme non (en d'autres termes: quelques heuristiques simples vont probablement fonctionner pour les cas très positifs).



0
votes

existe-t-il de toute façon pour déterminer si la méthode est purement fonctionnelle (c.-à-d., Compte tenu de la même entrée, elle produira toujours la même sortie

Je sais que c'est maintenant ce que vous avez demandé, mais les tests unitaires peuvent vous aider avec cela.


4 commentaires

Mais seulement si vous pouvez définir correctement ce que "l'environnement" est de sorte que vous puissiez créer tous les scénarios possibles dans lesquels vous pouvez modifier quelque chose pour voir si ce changement influence la méthode / la fonction statique. Sinon, même en lançant des tests unitaires à ce sujet, vous ne pouvez toujours pas savoir avec une certitude raisonnable.


Oui, je suis au courant de cela. Mais si vous pouvez effectivement charger un environnement «test» complet pour les tests de l'unité, cela sera probablement très efficace.


Et si j'écris une API qui prend une méthode comme entrée et retourne un booléen?


Vous ne seriez probablement pas à tester n Times la méthode avec son paramètre, puis vérifiez si les résultats sont les mêmes.



7
votes

Non, il n'y a aucun moyen de le faire avec une réflexion ou un autre mécanisme.

Le développeur sait si la méthode est fonctionnelle. Par exemple, le ressort a un @Cacheable annotation qui donne un indice à l'application que la méthode est fonctionnelle et peut donc cacher le résultat pour un ensemble d'arguments donné. (Le ressort enveloppera votre objet dans un proxy qui fournit le comportement de la mise en cache.)


3 commentaires

+1 J'étais sur le point de commenter quelque chose comme "faire ajouter le développement une annotation".


Je pense que cela s'applique à un très court ensemble de scénarios, étant donné qu'il aurait besoin de contrôler tout le code qu'il a l'intention de vérifier. Mais si l'OP a ce contrôle, oui c'est efficace. En outre, cela s'appuie sur ce qu'il est dit sur la méthode (l'annotation), pas ce que cela fait vraiment.


@Evertonagner Vous pouvez appliquer la mise en cache sans l'annotation, mais avec une configuration AOP. Le document lié explique la configuration requise.



0
votes

non. La réflexion ne peut pas lire le code octet de la méthode. Donc, vous ne pouvez pas vraiment dire quelle méthode fait ou même quelles autres classes utilisées.


0 commentaires

0
votes

La réflexion ne vous aidera pas ici. Si vous voulez vraiment pour le définir au moment de l'exécution, vous pouvez essayer d'utiliser Javap -c classname.class . Mais il serait préférable d'éviter de tels hacks.


0 commentaires