Por ejemplo:¿Cuáles son sus pensamientos sobre las constantes del alcance del método?
public void doSomething() {
final double MIN_INTEREST = 0.0;
// ...
}
Personalmente, yo preferiría ver a estas constantes de sustitución declaradas estáticamente a nivel de clase. Supongo que estoy buscando un "punto de vista de la industria" al respecto.
Mi posición inicial es que cada variable o constante debe declararse/inicializarse tan cerca de su primer uso como sea posible/práctico (es decir, no rompa un bloque lógico de código a la mitad, solo para declarar algunas líneas más cerca) , y alcance lo más fuerte posible. - A menos que puedas darme una maldita buena razón por la que debería ser diferente.
Por ejemplo, un método con alcance final no será visible en la API pública. A veces, este poco de información podría dejar de ser útil para los usuarios de su clase y debería moverse hacia arriba.
En el ejemplo que dio en la pregunta, yo diría que MIN_INTEREST es probablemente una de esas piezas de información que un usuario quisiera tener en sus manos, y debe tener el alcance de la clase, no el método. (Aunque no existe un contexto para el código de ejemplo, y mi suposición podría estar completamente equivocada.)
Creo que solo deberías ponerlos en el nivel de clase si son usados por múltiples métodos. Si solo se usa en ese método, eso se ve bien para mí.
Gracias escalofríos. Estaba pensando en esa dirección, pero tenía curiosidad por saber si había alguna razón para evitar la declaración del método. Por ejemplo, encuentro demasiados contstants declarados en el método que distraen de la lógica. – Liggy
Estoy totalmente de acuerdo, creo que es importante mantener el valor constante lo más cerca posible de donde se usa, por lo que con el tiempo, naturalmente, terminas revisando las constantes para asegurarte de que todavía tengan sentido. Como se señaló, si lo usa más de un método, la constante debe ser de nivel de clase. –
Si la constante contiene una información que el usuario desearía tener en sus manos (valores predeterminados), entonces debe tener un alcance en el nivel de clase. En mi respuesta a continuación, mostré que MIN_INTEREST podría necesitar ser accesible a través de la API pública, y por lo tanto, debe tener un alcance en la clase. –
La razón por la que puede definir una variable final a nivel de clase o nivel de método (local) es porque puede anular la constante estática global dentro del método (local).
Ejemplo:
public class Test {
final double MIN_INTEREST = 0.0;
/**
* @param args
*/
public static void main(String[] args) {
Test test = new Test();
test.doSomethingLocal();
test.doSomethingGlobal();
}
public void doSomethingGlobal() {
System.out.println("Global-> " + MIN_INTEREST);
}
public void doSomethingLocal() {
final double MIN_INTEREST = 0.1;
System.out.println("Local-> " + MIN_INTEREST);
}
}
La salida será:
Local-> 0.1
Global-> 0.0
Así que su pregunta no tiene ningún sentido.
Lo siento si la pregunta no está clara. Voy a reformular la pregunta. ¿Son comunes las prácticas de constantes de substiciones de ámbito metodológico? Creo que chills42 brindó una respuesta bastante acertada. – Liggy
He usado este método con las constantes de mi alcance pero de vez en cuando un colega lo modificará durante las revisiones de los códigos. De nuevo, estos colegas no están interesados en leer/escribir en código abierto, pero están acostumbrados al software empresarial.
Les digo que NO tiene sentido utilizar una constante de nivel de clase si se usa con un solo método, pero he encontrado que más de 1 colega insiste en que se mueva hacia ARRIBA. Normalmente lo cumplo porque no soy tan rígido a menos que afecte la legibilidad y/o el rendimiento.
La ocultación y la modularidad de la información son principios clave, y el alcance estrecho es una mejor ocultación de información. Si la constante solo es necesaria por el método, la ocultación es buena. Si y cuando la constante sea útil en otro lugar, llévela a un alcance más amplio, pero solo en la medida que sea necesario.
Probablemente esté preocupado porque es una constante y, por lo tanto, puede parecer pertenecer a alguna tabla de propiedades globales. Quizás sí. Tal vez no. Su preocupación es válida, pero no hay un mejor lugar para todas las constantes.
Técnicamente, no existe una "constante de ámbito de método" en Java. A lo que se refiere es simplemente una variable local final; se crea y se destruye con cada invocación de método.
http://www.java-tips.org/java-se-tips/java.lang/how-do-i-declare-a-constant-in-java.html
que tienen una opinión diferente sobre esto: En mi humilde opinión que es mejor ponerlos al archivo/ámbito de clase, especialmente si se está trabajando en equipo por esta razón: decir que se inicia con una pequeña pieza de código .. .
public void doSomething() {
final double MIN_INTEREST = 0.0;
// ...
}
y otros miembros que se unen ampliar la clase con toda montón de métodos y ahora la clase es una maravillosa 500 lines/50 methods clase gigante. Imagínese la experiencia de un ingeniero que está tratando de agregar un nuevo método con una constante, tendrán que explorar toda la clase 1 buscando constantes que coincidan con su necesidad, 2 mueva la constante al alcance de clase esperando que no haya conflictos con el existente code y 3 también agregan su método.
Si en su lugar agrega todas las constantes en el alcance de archivo/clase, los ingenieros tienen un 1 lugar único para buscar las constantes existentes y 2 derivan algunas constantes de otras donde tiene sentido. (por ejemplo, si tiene una constante para pi, también puede definir una nueva constante con un valor de pi/2).
¿Existe una ventaja de uso de memoria al declarar la constante en el nivel de clase en oposición al nivel de método, si la clase es Singleton? Cualquier pensamiento: @Chris Cudmore – Adam