2013-10-07 4 views
2

Comment se débarrasser des nombres magiques dans Java sans déclarer une quantité massive de finales ou de finales statiques? Gardez à l'esprit la mise en boucle, les tableaux ne sont pas autorisés. Cela ne semble pas possible? Aide appréciée. Merci.Se débarrasser des nombres magiques en Java

code Exemple:

drawOval(5, 5, width, height); 
drawOval(10, 10, width, height); 
drawOval(15, 15, width, height); 
drawOval(20, 20, width, height); 
drawOval(25, 25, width, height); 
+0

Est-ce que '52' est une faute de frappe? –

+0

Cela dépend de la signification que les valeurs ont pour chacune et si elles peuvent changer dynamiquement à travers l'exécution de l'application – MadProgrammer

+0

@lc, oui it it. fixé. – Larry21

Répondre

6

constantes Définition est vraiment votre seule option. Quelle est votre opposition à les utiliser? Ils valent certainement leur place dans ce contexte. Les futurs développeurs préfèreraient voir des constantes supplémentaires plutôt que de se demander ce que ces chiffres signifient.

+2

+1. Veuillez utiliser des constantes bien nommées. Cela facilite infiniment le travail de tous les autres. – asteri

+1

Oui, et en supposant que les emplacements des formes soient corrélés, j'utiliserais * une * bien nommée constante et '* 2',' * 3', etc. pour le reste. –

1

Une alternative à la finale/statique que je l'ai déjà vu est d'utiliser un objet personnalisé comme argument:

public void drawOval(OvalArg arg) { 
    // ... 
} 

OvalArg arg = new OvalArg(); 
arg.first = 10; 
arg.second = 10; 
arg.width = 100; 
arg.height = 500; 

drawOval(arg); 

Cependant, cette approche implique que vous ne pouvez pas voir directement quels arguments doivent être envoyés à un méthode (sauf si vous regardez dans l'objet argument), et nécessite une validation supplémentaire pour s'assurer que votre objet personnalisé est correctement rempli. Pour cette raison, je recommanderais d'utiliser des constantes.

+1

Si vous avez déjà utilisé 'GridBagConstraints' avec Swing, vous savez à quel point cette technique est ridiculement ennuyante. Haha – asteri

+0

Haha, je n'ai jamais été un grand fan de 'GridBagConstraints', il me semblait une interface utilisateur" codée ". Je l'ai vu à l'école, mais j'ai préféré des dispositions plus dynamiques aussi. –

2

La réponse directe est que les constantes nommées sont le seul moyen d'éviter d'avoir des nombres magiques dans votre code.


Mais le revers de la médaille est qu'il est discutable si les nombres magiques sont nuisibles (ou dans la mesure où elles sont nuisibles). Et dans ce cas particulier, il est discutable de savoir si ceux-ci sont réellement qualifiés de numéros "magiques" ... au moins, l'OMI.

Illustrons ceci:

// Alternative #1 

private final int PLACE_1_X = 5; 
private final int PLACE_1_Y = 5; 
... 
drawOval(PLACE_1_X, PLACE_1_Y, width, height); 

// Alternative #2 
drawOval(5, 5, width, height); 

Lequel d'entre eux est en fait plus lisible? Est-ce que la définition de constantes nommées (qui sont probablement à un autre point du code source!) Facilite la compréhension de ce qui se passe? N'avez-vous pas maintenant le problème que vous devez regarder dans deux endroits pas un pour comprendre ce qu'un appel drawOval va dessiner?


L'essentiel est que « aucun chiffre magique » dogme ne vaut vraiment quand il signification des nombres est pas de soi dans le contexte ... ou lorsque le nombre est en fait un utilisé à plusieurs reprises constant. (Comme si nous allions utiliser PLACE_1 beaucoup de fois dans la même "image".)

Vous devez penser au contexte, pas seulement appliquer aveuglément le dogme.

Questions connexes