Pourquoi n'est-ce pas getClass() disponible comme une méthode statique?

En statique contextes, comment se fait que vous ne pouvez pas appeler une version statique de getClass() (plutôt que d'avoir à utiliser my.package.name.MyClassName.class) ?

N'est pas le compilateur assez intelligent pour savoir quand utiliser des méthodes d'objet + lors de l'utilisation de méthodes statiques?

REMARQUE pour plus de clarté:

Je ne dis pas qu'un static getClass() doit être utilisé au lieu de la non-méthode statique getClass() (c'est assez évident-si SpecialFoo est une sous-classe de Foo, puis le getClass() d'un Foo pourrait revenir Foo.class ou SpecialFoo.class ou de quelque chose et il doit être déterminé au moment de l'exécution).

Je dis que je me demandais pourquoi il n'existe pas de deux versions de getClass(), qui est une méthode statique qui ne s'applique que dans un contexte statique, et la non méthode statique getClass(). Si il n'est pas possible, alors il n'est pas possible, et c'est la réponse. Si c'est possible, mais n'a pas été fait, c'est un choix historique, et peut-être il ya une bonne raison pour cela. C'est ce que j'aimerais savoir.

Il serait bon de déclarer

final static Logger logger = LoggerFactory.getLogger(getClass());

au lieu de 

final static Logger logger = LoggerFactory.getLogger(my.package.name.MyClass.class);

où le premier peut être copiée mot pour mot d'une classe à l'autre, tandis que le second vous oblige à copier le nom de la classe dans chaque fichier.

  • Bonne question. Groovy permet this de référence à la classe actuelle dans un contexte statique 😉
  • Probablement parce que, au moment de l'exécution des méthodes statiques qui n'ont aucune classe.
  • Droit, mais à partir du compilateur, point de vue, lorsque vous appelez une méthode statique foo(), il sait foo() se réfère à la méthode statique. Je crois que je vais poser est de savoir pourquoi il n'y a pas un getClass() méthode statique qui renvoie la builtin statique .class champ.
  • Il semble probable qu'il n'y a pas de getClass() parce que de retour dans la journée, les développeurs du langage java, de mettre dans la .catégorie de la propriété et de la pensée "qui est assez bon". Un peu comme le Tableau.la longueur de la propriété.
  • Éventuellement, une méthode n'est pas la bonne solution, mais moyen de faire référence à la Class objet de la classe actuelle, ce serait bien. Peut-être this.class comme un cas particulier de la Class littérale toujours en se référant à la classe contenant l'expression.
  • Je suppose que je devrais re-titre; mon point n'est pas tellement pourquoi n'est-il pas présent, mais est-il possible que cela puisse être fait.
  • Si c'est possible, mais n'est tout simplement pas mis en œuvre, alors que j'avais proposer pour le prochain Projet-forme de Pièce de monnaie de l'effort. Mon code est plein de final static Logger logger = LoggerFactory.getLogger(my.package.name.MyClassName.class) lignes qui ne sont pas facilement maintenable.
  • Pourquoi le nom pleinement qualifié de la classe lorsque vous êtes dans cette classe déjà? MyClassName.class devrait suffire.
  • Je ne sais pas pourquoi vous pensez que ce n'est pas facilement maintenable. Puisque vous êtes en train d'ajouter que l'exploitant init sein même de la classe le nom de la classe ne doit jamais changer, sauf si vous renommer la classe et c'est l'unité de compilation qui est très rare. Aussi comme colinD dit, le paquet est redondant, vous êtes déjà dans la classe que vous n'en avez pas besoin.
  • SEC -- c'est quand vous copiez le code d'une classe à l'autre. Aussi loin que la modification du nom, de l'Éclipse du refactoring des poignées de cas correctement.
  • On dirait qu'il est temps pour moi d'utiliser un autre Lombok fonction -- projectlombok.org/features/Log.html

InformationsquelleAutor Jason S | 2011-04-20
  1. 3

    Si rien d'autre, car il n'est pas légal d'avoir à la fois un static et nonstatic version d'une méthode (probablement parce que c'est légal, si découragé, pour appeler un static méthode dans un non-static contexte).

    J'ai aussi l'impression que cette méthode, bien qu'utiles dans le contexte de la définition d'un enregistreur ou que ce soit, pourrait être source de confusion dans d'autres contextes, comme lorsqu'il est appelé à partir d'une méthode d'instance.

    InformationsquelleAutor ColinD
  2. 26

    Vous pouvez utiliser cet idiome

        Class<?> cl=new Object(){}.getClass().getEnclosingClass();

    Par exemple:

    static class Bar {
    public static void main(String[] args) {
        Class<?> cl=new Object(){}.getClass().getEnclosingClass();
        System.out.println(cl==Bar.class);  //will print true
    }
}
    • +1 ... intéressant!
    • Je reçois toujours la valeur null à l'aide de cette méthode. Cela dépend-il de Barre à une classe statique?
    • Vous avez écrit,new Object().getClass().getEnclosingClass(). La bonne façon est d'utiliser des new Object(){}, qui définit et instancie une classe anonyme basée sur Object.
    InformationsquelleAutor alexsmail
  3. 7

    Chaque objet est une instance d'une classe en Java, et aucune classe ne peut être une instance d'une autre classe! C'est pourquoi getClass() n'est pas statique, comme il n'a de sens que dans le contexte d'un objet : vous êtes à essayer de trouver un objet de la classe est une instance de.
    Si c'était une fonction statique, il peut être appelé de l'extérieur d'un objet, mais il ne fait pas de sens d'écrire

    String.getClass()

    parce que vous savez déjà que vous êtes "demander" à la classe String!

    • raison: j'ai entendu que lors de l'écriture de ma question. Voir les modifications.
    • il n'ajoute pas de valeur pour l'utiliser hors de la classe, mais il ajoute de la valeur pour l'utiliser à l'intérieur de la classe.
    InformationsquelleAutor Liv
  4. 5

    getClass() fournit une fonctionnalité différente de la statique .classe. Il est utilisé pour obtenir le temps d'exécution de la classe de l'instance, il est appelé sur.

    Object o = new String();
o.getClass() //returns Class<String>    
Object.class //returns Class<Object>
    • oui, bien sûr-désolé, je n'ai pas à me faire clair dans ma question initiale. voir mes modifications.
    • Gotcha, il semble que quelqu'un d'autre a déjà donné cette réponse, mais le plus probable, c'est parce que vous ne pouvez pas la surcharge des noms de méthode avec le mot-clé static seul. Vous auriez besoin d'un deuxième méthode avec un nom différent ou de paramètres. J'imagine qu'ils ont pensé que ce serait inutile et/ou de confusion pour ajouter une deuxième méthode getClass. Je suppose qu'ils ont pensé que personne n'aurait un problème à l'aide de la statique .catégorie de la propriété.
    InformationsquelleAutor Jberg
  5. 2

    Parce que si getClass() serait statique, son code devra être définie dans une classe - probablement Object. Là, vous ne pouvez pas déterminer la appelants classe et il n'y a pas une instance de l'objet qui l'appelle.

    Edit:

    Il n'est pas sur le nom, ça pourrait être très bien getClass2(). Je suis en train de dire que si vous définissez une méthode statique, vous ne pouvez pas savoir la classe qui l'appelle:

    public class Object {

    public static Class<?> getClass2() {
        return ...?
    }

}
    • Il y a une astuce similaire au travail avec Enum.getValues(): c'est une méthode statique qui est disponible sur chaque enum (un.k.un. "chaque sous-classe de java.lang.Enum). Quelque chose de similaire serait envisageable ici.
    • Je ne dis pas qu'il devrait être lieu de la non-méthode statique getClass() (c'est assez évident-si SpecialFoo est une sous-classe de Foo, puis le getClass() d'un Foo pourrait revenir Foo.class ou SpecialFoo.class ou autre chose). Je suis en train de dire que, dans un contexte statique pourquoi n'est-il pas une seconde statique version de getClass().
    • S - Vous ne pouvez pas déclarer deux méthodes qui se différencient uniquement sur le mot-clé static:)
    • OK, alors c'est la réponse, donc ils doivent avoir deux noms différents afin de mettre en œuvre.
    • Je pense que tu veux dire values() de enum, pas getValues(), droit?
    • bien sûr, ma faute.

    InformationsquelleAutor True Soft
  6. 2

    Vous pouvez mettre en œuvre un vous-même. Obtenir le stacktrace, et trouver de l'appelant classe.

    Fait l'enregistreur de lib pourrait en œuvre que lui-même

    static Logger logger = LoggerFactory.getLogger(); //auto detect caller class
    InformationsquelleAutor irreputable
  7. 1

    N'est-ce pas statique getClass() de retour de méthode de la classe object la classe de la variable qui contient l'objet est d'? Qui allait changer la sémantique de getClass(). Exemple:

    Interface foo = new FooImpl(); 
foo.getClass(); //returns Class<FooImpl> because the runtime type is FooImpl. 
                //If getClass() was static, it would return Class<Foo>.
    InformationsquelleAutor atamanroman
  8. 1

    En plus d'autres réponses (ce qui explique pourquoi nous ne pouvons pas faire une méthode statique avec la même signature que le non-static 'getClass () la méthode), on peut se demander si il serait possible d'avoir, disons, un static Class getStaticClass() de sorte que, par exemple String.getStaticClass() serait équivalent à String.class. Mais, encore une fois, cette méthode ne pouvait pas être "normal" de la méthode, Où serait-il défini? dans l'Objet? Alors comment cette méthode unique de savoir ce qu'il doit retourner (String.class ou Object.class) quand il a été appelé en tant que Chaîne de caractères.getStaticClass() ou d'un Objet.getStaticClass() ? Serait-il décider qu'il en exécution ? Aucun moyen.

    Une méthode statique n'a pas de sens parce que String.class est connu (résolu) au moment de la compilation. La méthode n'a pas de chose raisonnable à faire lors de l'exécution; que vous avez à faire certaines compilation la magie de sorte que le résultat de cet appel de méthode est en fait résolu au moment de la compilation.

    InformationsquelleAutor leonbloy