Hay varios problemas con este código, que, por cierto, se pueden acortar de la siguiente manera:
public List<Money> getMoneyByPersons() {
return persons.size() == 1 ?
moneyService.getMoneyIfHasOnePerson() :
moneyService.getMoney();
}
-
No está claro por qué una persona es un caso especial. Supongo que hay una regla comercial específica que dice que obtener dinero de una persona es radicalmente diferente de obtener dinero de varias personas. Sin embargo, tengo que buscar tanto getMoneyIfHasOnePerson
como getMoney
, esperando entender por qué hay casos distintos.
-
El nombre getMoneyIfHasOnePerson
no se ve bien. Por el nombre, esperaría el método para verificar si hay una sola persona y, si este es el caso, obtener dinero de él; de lo contrario, no hacer nada. Desde tu código, esto no es lo que está sucediendo (o estás haciendo la condición dos veces).
-
¿Hay alguna razón para devolver un List<Money>
en lugar de una colección?
Volviendo a tu pregunta, porque no está claro por qué hay un tratamiento especial para una persona, el dígito uno debe reemplazarse por una constante, a menos que haya otra. Manera de hacer las reglas explícitas. Aquí, uno no es muy diferente de cualquier otro número mágico. Podría tener reglas comerciales que indiquen que el tratamiento especial se aplica a una, dos o tres personas, o solo a más de doce personas.
¿Cómo puedo distinguir el contexto para elegir la mejor solución?
Usted hace lo que hace que su código sea más explícito.
Ejemplo 1
Imagina el siguiente fragmento de código:
if (sequence.size() == 0) {
return null;
}
return this.processSequence(sequence);
¿Es cero aquí un valor mágico? El código es bastante claro: si no hay elementos en la secuencia, no lo procesemos y devolvamos un valor especial. Pero este código también se puede reescribir así:
if (sequence.isEmpty()) {
return null;
}
return this.processSequence(sequence);
Aquí, no más constante, y el código es aún más claro.
Ejemplo 2
Toma otra pieza de código:
const result = Math.round(input * 1000) / 1000;
No lleva mucho tiempo entender lo que hace en lenguajes como JavaScript que no tienen una sobrecarga de round(value, precision)
.
Ahora, si quieres introducir una constante, ¿cómo se llamará? El término más cercano que puede obtener es Precision
. Entonces:
const precision = 1000;
const result = Math.round(input * precision) / precision;
¿Mejora la legibilidad? Puede ser. Aquí, el valor de una constante es bastante limitado, y puede preguntarse si realmente necesita realizar la refactorización. Lo bueno aquí es que ahora, la precisión se declara solo una vez, por lo que si cambia, no se arriesgue a cometer un error como:
const result = Math.round(input * 100) / 1000;
cambiando el valor en una ubicación, y olvidando hacerlo en la otra.
Ejemplo 3
De esos ejemplos, puede tener la impresión de que los números deben reemplazarse por constantes en cada caso . Esto no es verdad. En algunas situaciones, tener una constante no conduce a la mejora del código.
Toma el siguiente fragmento de código:
class Point
{
...
public void Reset()
{
x, y = (0, 0);
}
}
Si intenta reemplazar los ceros por una variable, la dificultad sería encontrar un nombre significativo. ¿Cómo lo llamarías? %código%? %código%? %código%? Introducir una constante aquí no mejoraría el código de ninguna manera. Lo haría un poco más largo, y solo eso.
Sin embargo, estos casos son raros. Por lo tanto, cada vez que encuentre un número en el código, intente encontrar la manera de refactorizar el código. Pregúntese si hay un significado comercial para el número. Si es así, una constante es obligatoria. Si no, ¿cómo nombrarías el número? Si encuentras un nombre significativo, eso es genial. De lo contrario, es probable que encuentre un caso en el que la constante no sea necesaria.