È una cattiva idea non memorizzare i dati in un archivio persistente? per esempio. Banca dati; file ecc

Queste denominazioni di valuta sono costanti - cioè quei valori stabili e in continua evoluzione che nessuno si aspetta di cambiare tranne in rare circostanze, simili a Pi, la costante gravitazionale, ecc.

Ovviamente , alcune costanti inevitabilmente a volte cambiano nel mondo reale, ma il costo commerciale del codice di ricompilazione per queste rare occorrenze (e la distribuzione di un aggiornamento software) è in genere basso / insignificante.

È completamente normale che costanti di questo tipo esistano in un dominio, quindi anche normali costanti del codice fisso nel programma piuttosto che tenerle in un archivio persistente esterno / recupero da un servizio / ecc.

Relativo al tuo esempio: due potenziali problemi con la parola chiave yield :

1. Potenziale violazione del Princple of Almstatonment
2. Non supporta accesso casuale - che può o non può essere un problema, ma non vedo alcuna ragione per consentire questo

Come possibile alternativa a yield , potresti prendere in considerazione un array - ad es.

public class EnglishCurrency 
{
    private static readonly decimal[] _values = 
    {
         0.01M,  0.02M,  0.05M, 
         0.10M,  0.20M,  0.50M,
         1.00M,  2.00M,  5.00M,
        10.00M, 20.00M, 50.00M,
    };

    public override IEnumerable<decimal> Values() => _values;
}

Modifica - Il codice sopra riportato utilizza la sintassi C # 6.0 per il metodo Values() . Se ciò non funziona a causa dell'esecuzione di una versione precedente di Visual Studio o di una versione precedente del compilatore C #, utilizzare invece:

    public override IEnumerable<decimal> Values()
    {
        return _values;
    }

Ogni cosa ha un costo, ea volte i benefici non valgono quello che devi pagare per loro. Tutte le astrazioni hanno un costo, in termini di velocità di esecuzione, velocità di sviluppo o richieste di cellule cerebrali. Parte del mestiere dello sviluppo del software sta avendo un occhio chiave in cui ne valgono la pena.

Le cose hardcoding sono i mezzi più semplici per mettere i dati in un programma. È semplice da fare, ma il suo costo è la difficoltà di cambiare il codice. Fondamentalmente è anche il modo più rapido per ottenere i dati, ed è praticamente garantito lavorare ogni volta senza eccezioni. Solo le persone che programmano sonde spaziali e pacemaker devono preoccuparsi che non funzioni.

D'altra parte, diciamo che hai messo i dati in un file o database. Ora hai una quantità relativa del lavoro aggiuntivo di capire come ottenere quei dati. Se stai usando un file di configurazione, ora devi gestire il file mancante e gestirlo. Cosa succede se gli utenti vogliono valori predefiniti se non hanno una configurazione? Dove memorizzi le impostazioni predefinite? Dove memorizzi i dati che dicono dove trovare il file? La tana del coniglio può davvero fare in profondità. Tutte queste domande devono essere risolte. Hardcoding non ha nessuno di questi.

Più astrazioni si accumulano in più luoghi in cui i bug possono essere in agguato, più difficile è testare e più difficile è pensare a capire cosa sta accadendo nel tuo programma.

Certo, librerie DB, OEM, librerie di file di configurazione possono semplificare un po 'di tutto questo, ma saranno senza dubbio più lavoro, più codice e più posti in cui andare male di un array hardcoded.

Quindi devi valutare cosa è appropriato. Non posso darti una risposta che puoi testare meccanicamente perché finora è un giudizio che solo noi umani possiamo fare. È necessario valutare la probabilità di cambiamento dei dati, il costo di gestione di tale cambiamento rispetto al costo di gestione delle astrazioni. Come molti programmi, troverai una combinazione di dati hardcoded, in file flat e in un database, per qualsiasi programma ragionevolmente definito.

Il tuo codice di esempio che usa una serie di dichiarazioni di rendimento è uno degli esempi più estremi di "quando tutto ciò che hai è un martello, tutto sembra un chiodo" che ho visto da molto tempo. Quando arrivano le risposte, penso che dovresti leggerle e riflettere seriamente sul fatto che una determinata astrazione che stai utilizzando sia appropriata per il compito in questione, dal momento che il tuo utilizzo e la difesa di tale design significa che hai ancora bisogno di sviluppare questo senso.

Avere un file separato facilita l'aggiornamento (specialmente se si tratta solo di testo) e la distribuzione per gli aggiornamenti, ma non sembra che questi valori possano cambiare. Metterlo nel codice sorgente richiede una ricompilazione e una possibile distribuzione. Ancora una volta, non pensi che cambierà, quindi niente di tutto ciò è importante fino a quando non lo fa.

Hai creato uno scenario in cui probabilmente non ha importanza. Come un altro sviluppatore che potrebbe dover supportare questa app in seguito (Ordinamento di giocare Devil's Advocate qui.), Non mi aspetto di avere questo nel codice sorgente. Se esistesse un database, sarei alla ricerca di una sorta di tabella / nodo di valuta. Sapere da dove provengono i valori è una parte importante della risoluzione dei problemi e del mantenimento del codice. Se questa è l'unica ragione, è abbastanza buono per me.

Se hai già avuto il problema di avere un database per la tua app, perché non usarlo?