Come dicono gli altri, certo, è ancora una pura funzione.
Tuttavia, parliamo dei problemi di progettazione. Hai ragione a provare a fare qualcosa per mantenere il codice DRY, inserendo il valore solo una volta. Inoltre, ciò che penso dovrebbe essere considerato è anche il livello di accoppiamento appropriato.
L'uso di una funzione offre una maggiore flessibilità per modificare l'implementazione, vale a dire che l'approccio della funzione offre un accoppiamento più flessibile rispetto a una variabile globale.
La domanda è se uno ne ha bisogno o no?
Se i consumatori e il provider si trovano nello stesso modulo e il provider è privato del modulo, è difficile sostenere che questo livello di accoppiamento libero sia necessario, a causa del fatto che se il provider richiede l'aggiornamento da una variabile privata a un metodo privato, un semplice refactoring all'interno del modulo può essere applicato contemporaneamente ai consumatori. L'uso di un metodo / funzione prima che sia realmente necessario potrebbe rientrare in YAGNI.
Anche se il consumatore (i) e il fornitore si trovano in moduli diversi, tuttavia i moduli sono sottoposti a versione insieme (ad esempio, si utilizza un minificatore, in modo che i moduli dei consumatori e del fornitore si trovino nello stesso file), potrebbe applicarsi anche YAGNI.
D'altra parte, se, ad esempio, il produttore si trova in una libreria o in un pacchetto API o modulo con versione separata dal / i consumatore / i, l'utilizzo della funzione potrebbe essere appropriato. In tal caso dovremmo considerare la longevità dell'API e principi come OCP.
(In un'altra nota, se il tuo codice ha dimensioni significative, incoraggerei l'uso di moduli con campi e metodi piuttosto che variabili e funzioni globali.)