Sonar se plaint du nom de méthode privée dans une classe lorsque nous utilisons le même nom de méthode privée parente. En qualité de code, quel est l’inconvénient de définir une méthode privée avec le même nom que la méthode privée parente?
Ou devons-nous classer cela comme faux positif
4 Réponses :
OMI, c'est parce que cela peut prêter à confusion. Considérez ci-dessous, lisez le commentaire:
class Child extends Super{
public void myMethod() {
System.out.println("in child");
}
}
class Super{
public static void main(String[] args) {
Super s = new Child();
s.myMethod(); // At this point you might expect myMethod of child to be called if it'll call the Parent's since it is private.
}
private void myMethod() {
System.out.println("in super");
}
}
La question demande quand les deux méthodes sont privées. Dans votre exemple, si les deux méthodes sont privées, vous ne devez pas vous demander si la méthode Child peut être invoquée, vous savez que seule Super.myMethod () peut être invoquée dans le contexte courant.
Lorsque vous avez une méthode dans votre sous-classe avec le même nom avec votre superclasse, à première vue, l'hypothèse sera un remplacement, causant de la confusion quand ce n'est pas le cas.
La documentation mentionne trois situations dans lesquelles cela peut arriver:
La méthode de classe parente est statique et la méthode de classe enfant ne l'est pas.
Les arguments ou types de retour de la méthode enfant sont dans différents packages que ceux de la méthode parente.
La méthode de la classe parente est privé.
Et aussi la recommandation:
Mais si l'intention est vraiment que la méthode de classe enfant soit différente, alors la méthode doit être renommée pour éviter toute confusion .
Donc, si vous voulez vraiment ne pas remplacer la méthode de la superclasse, la recommandation est de la changer pour éviter toute confusion.
Vous pouvez consulter un exemple dans la RSPEC-2177 - Documentation des règles du sondeur ,
La décision de renommer la méthode ou de marquer l'occurrence comme un faux positif dépend entièrement de la manière dont l'équipe organise sa base de code et de la convention de code utilisée entre les développeurs.
"Donc, si vous voulez vraiment ne pas remplacer la méthode de la superclasse, la recommandation est de la changer pour éviter toute confusion." Pour éviter toute confusion, la chose à faire est d'annoter @Override les méthodes remplacées.
@davidxxx Je suis entièrement d'accord avec vous, mais je mentionne la recommandation présentée par Sonar dans la documentation.
De plus, dans certains cas, vous pouvez simplement ajouter l'annotation @Override , ayant une méthode privée dans la superclasse et une méthode publique dans la sous-classe par exemple, si vous ajoutez le @Override annotation le compilateur se plaindra puisque la visibilité n'est pas disponible dans la sous-classe.
Je sais que c'est une recommandation de Sonar. Juste je trouve que c'est faux. À chaque fois que j'ai fait une revue de code, au moins 50% du problème n'est pas détecté par le sondeur et au moins 50% des alertes / problèmes Sonar ne sont pas de vrais problèmes, juste des détails. Quelle que soit votre conclusion est correcte. Ce n'est pas à Sonar de se prononcer sur ce point (+1)
IHMO, cette règle n'a aucun sens.
Si la dénomination a du sens pour le parent et la sous-classe, vous n'inventerez pas un nom différent pour l'un d'entre eux pour rendre Sonar heureux.
Cela pourrait rendre le code moins clair et le rendre moins homogène dans votre code de base.
Les méthodes privées ne sont visibles qu'à l'intérieur de la classe courante, il suffit donc de sécuriser ce choix.
Je comprends le but de la règle. Cependant, cela ne devrait pas s'appliquer aux classes abstraites avec des méthodes privées concrètes.
Nous utilisons la bibliothèque Apache MINA, qui a plusieurs méthodes privées concrètes dans CumulativeProtocolDecoder qui sont référencées dans leurs méthodes concrètes publiques. Si les méthodes publiques sont surchargées, nous sommes obligés de fournir nos propres implémentations des méthodes privées. Cela n'a pas de sens de leur donner un autre nom juste pour éviter d'être habillé par Sonar.