Ci sono diversi problemi con questo pezzo di codice che, a proposito, può essere abbreviato in questo modo:
public List<Money> getMoneyByPersons() {
return persons.size() == 1 ?
moneyService.getMoneyIfHasOnePerson() :
moneyService.getMoney();
}
Non è chiaro perché una persona sia un caso speciale. Suppongo che ci sia una regola aziendale specifica che dice che ottenere denaro da una persona è radicalmente diverso dall'ottenere denaro da più persone. Tuttavia, devo andare a guardare dentro entrambi getMoneyIfHasOnePerson
e getMoney
, nella speranza di capire perché ci sono casi distinti.
Il nome getMoneyIfHasOnePerson
non sembra giusto. Dal nome, mi aspetterei che il metodo verifichi se esiste una sola persona e, in tal caso, ottenere denaro da lui; altrimenti, non fare nulla. Dal tuo codice, questo non è ciò che sta accadendo (o stai facendo la condizione due volte).
C'è qualche motivo per restituire una List<Money>
piuttosto che una raccolta?
Tornando alla tua domanda, poiché non è chiaro il motivo per cui esiste un trattamento speciale per una persona, il numero uno dovrebbe essere sostituito da una costante, a meno che non ci sia un altro modo per rendere esplicite le regole. Qui, uno non è molto diverso da qualsiasi altro numero magico. Potresti avere regole commerciali che affermano che il trattamento speciale si applica a una, due o tre persone o solo a più di dodici persone.
Come posso distinguere il contesto per scegliere la soluzione migliore?
Fai qualunque cosa renda il tuo codice più esplicito.
Esempio 1
Immagina il seguente codice:
if (sequence.size() == 0) {
return null;
}
return this.processSequence(sequence);
Lo zero qui è un valore magico? Il codice è piuttosto chiaro: se non ci sono elementi nella sequenza, non elaboriamolo e restituiamo un valore speciale. Ma questo codice può anche essere riscritto in questo modo:
if (sequence.isEmpty()) {
return null;
}
return this.processSequence(sequence);
Qui, non più costante e il codice è ancora più chiaro.
Esempio 2
Prendi un altro pezzo di codice:
const result = Math.round(input * 1000) / 1000;
Non ci vuole troppo tempo per capire cosa fa in linguaggi come JavaScript che non hanno round(value, precision)
sovraccarico.
Ora, se vuoi introdurre una costante, come verrebbe chiamata? Il termine più vicino che puoi ottenere è Precision
. Così:
const precision = 1000;
const result = Math.round(input * precision) / precision;
Migliora la leggibilità? Può essere. Qui, il valore di una costante è piuttosto limitato e potresti chiederti se hai davvero bisogno di eseguire il refactoring. La cosa bella qui è che ora la precisione viene dichiarata una sola volta, quindi se cambia, non rischi di fare un errore come:
const result = Math.round(input * 100) / 1000;
cambiando il valore in una posizione e dimenticando di farlo nell'altra.
Esempio 3
Da quegli esempi, potresti avere l'impressione che i numeri debbano essere sostituiti da costanti in ogni caso . Questo non è vero. In alcune situazioni, avere una costante non porta al miglioramento del codice.
Prendi il seguente codice:
class Point
{
...
public void Reset()
{
x, y = (0, 0);
}
}
Se si tenta di sostituire gli zeri con una variabile, la difficoltà sarebbe quella di trovare un nome significativo. Come lo chiameresti? ZeroPosition
? Base
? Default
? Introdurre una costante qui non migliorerebbe il codice in alcun modo. Lo renderebbe leggermente più lungo, e proprio quello.
Tali casi sono tuttavia rari. Quindi ogni volta che trovi un numero nel codice, fai lo sforzo cercando di trovare come il codice può essere refactored. Chiediti se esiste un significato commerciale per il numero. Se sì, una costante è obbligatoria. Se no, come chiameresti il numero? Se trovi un nome significativo, va benissimo. In caso contrario, è probabile che tu abbia trovato un caso in cui la costante non è necessaria.
persons
viene e cosa descrive? Il tuo codice non ha alcun commento, quindi è difficile indovinare cosa sta facendo.