Design Advice su Getter o Const per String in Classes - cosa stanno facendo gli altri?

Question

Sto cercando qualche consiglio su quale sia il metodo consigliato per utilizzare le stringhe "costanti" all'interno delle mie classi, ad es.

public string EmployeesString { get { return "Employees"; } } 

const string EmployeeString = "Employee"; 

La ragione per cui mi piacerebbe implementare questi, cioè o tramite un const o tramite un getter, è perché in tutta la mia classe (es), ho metodi e costruttori che utilizzano queste stringhe come parametri e pensavo per evitare errori di battitura e anche per evitare l'uso di stringhe (debolmente tipizzate?), volevo farvi riferimento con forza, ad es

DoSomething(this.EmployeeString, employee); 

Cosa fanno gli altri? Qualsiasi consiglio sarà molto apprezzato! Questo è buono/cattivo?

Answer 1

La risposta "giusta", a mio parere, dipende da come e perché si sta utilizzando la stringa.

Se la stringa viene utilizzata per la visualizzazione o presentata a un utente, la proprietà è un design migliore. Ciò rende molto più semplice aggiungere la localizzazione in seguito spostando la costante in file di risorse, senza dover modificare l'API. Questo rende anche più facile adattare la tua classe senza infrangere altro codice, dato che sei libero di cambiare la "costante" in qualsiasi momento senza rompere gli altri assiemi.

Raramente ho trovato usi appropriati per il secondo caso - pochissime stringhe sono veramente costanti, e quando lo sono, credo che in genere siano meglio rappresentate come un'enumerazione anziché una stringa. Questo è quasi sempre meglio di "stringhe magiche" nel tuo codice.

Le rare eccezioni sono in genere quando si interagisce con il codice legacy - se si ha a che fare con un'API distinta che si aspetta una stringa e la stringa è veramente costante, che utilizzare una costante è potenzialmente "migliore", in quanto è più efficiente e molto chiaro nel suo intento.

Inoltre, ricorda che i due approcci possono essere usati insieme:

private const string employeeString = "Employee"; 

public string EmployeeString { get { return employeeString; } } 

Questo consente di utilizzare la costante, rendendo è chiaro intento, ma facilmente modificare questa più tardi senza rompere altro codice o cambiare la tua API . (Personalmente preferisco questa opzione alla seconda opzione, poiché la stringa magica nella proprietà getter è un odore di codice per me - mi piacciono le costanti come costanti ovvie, ma preferisco comunque le proprietà.)

Answer 2

Di cosa stai parlando, almeno in questo esempio sarebbe una "costante". Quindi il secondo metodo sarebbe il "più appropriato" almeno secondo me.

Answer 3

Qualsiasi stringa che verrà utilizzata per la visualizzazione o l'interfaccia utente dovrebbe essere inserita nei file di risorse. Ciò consente una chiave fortemente tipizzata, ma consente anche una facile internazionalizzazione dell'applicazione, in quanto è possibile ottenere il file di risorse tradotto in una nuova lingua e verrà automaticamente applicato agli utenti di tale cultura.

Ad esempio, se si inserisce un nuovo file .resx nel progetto denominato "ApplicationStrings" e si aggiunge una coppia chiave/valore di "EmployeeString"/"Employee", è possibile chiamarlo nella propria applicazione come questa :

DoSomething(ApplicationStrings.EmployeeString, employee); 

Se avete creato una versione tradotta di queste stringhe, diciamo per spagnolo messicano, si sarebbe solo creare un nuovo file chiamato ApplicationStrings.es-mx.resx. Quando le persone con l'impostazione cultura es-mx hanno usato il tuo programma, utilizzerebbero automaticamente la versione tradotta!

Quindi i vantaggi sono piuttosto chiari: valori fortemente referenziati, facile localizzazione e gestione centralizzata delle stringhe magiche nella vostra applicazione.

Anche per stringhe che non verranno visualizzate, in genere creo file di risorse per loro, come "InternalStrings.resx". In questo modo puoi usare i riferimenti fortemente tipizzati alle "stringhe magiche" interne di cui il tuo programma potrebbe aver bisogno, e se devi cambiarli, devi solo cambiare il valore in un posto.

Answer 4

Se le stringhe potrebbero mai cambiare in futuro, devi essere un po 'cauto nel renderle costanti, almeno se sono accessibili ad altri assiemi, altrimenti gli altri gruppi potrebbero non raccogliere il nuovo valore se crea una nuova versione dell'assembly.

Edit: Aggiunto parole mancanti

Answer 5

campo const è corretto

Answer 6

Se è veramente una costante faccio questo:

const string EmployeeString = "Employee"; 

È di gran lunga il modo più semplice di raccontare altri programmatori, "Questo non cambierà".

public string EmployeesString { get { return "Employees"; } } 

Senza vedere all'interno del codice, non so cosa accadrà all'accessorio. So solo che esiste una funzione di accesso e sto recuperando una stringa. Più avanti in questo esempio, qualcuno potrebbe aggiungere una proprietà set ecc. E modificare il valore della proprietà in fase di runtime. Non puoi farlo con una costante.