Sta avendo costanti pubbliche "cattive"?

In C # è pessimo per nessuno dei motivi menzionati in questa discussione.

Le costanti pubbliche in C # vengono trasformate in assembly di riferimento. Significato, se hai un oggetto SomeOtherClass in un assembly separato che fa riferimento a SomeString in MyClass, il CIL generato per SomeOtherClass conterrà una stringa "SomeValue" con hardcoded.

Se vai a ridistribuire la DLL che contiene MyClass ma non SomeOtherClass e cambia il const, SomeOtherClass non conterrà ciò che pensi che - esso conterrà il valore originale.

Se sei positivo al 100%, è una costante universale come Pi, impazzisci; altrimenti calpesti attentamente.

Ecco una spiegazione migliore: link

La modifica di un campo in una proprietà è una interruzione delle modifiche. Si perde la compatibilità binaria, di origine e di riflessione.

Inoltre:

• There's more fine-grained access control with properties. Need it to be publicly gettable but really only want it set with protected access? No problem (from C# 2 onwards, at least).
• Want to break into the debugger whenever the value changes? Just add a breakpoint in the setter.
• Want to log all access? Just add logging to the getter.
• Properties are used for data binding; fields aren't.

link

Tutto ciò che ho detto, non vedo come le costanti siano realmente influenzate da questo (specialmente se non hai bisogno di nessuna delle caratteristiche di cui sopra), a meno che la tua API non cambi in modo tale che non siano più costanti. / p>     

I pericoli dei campi pubblici sono nel fatto che sono mutabili e che l'implementazione sottostante è soggetta a modifiche.

Quando si tratta di un const questo normalmente non è un problema (analogamente alle enumerazioni pubbliche) - a meno che tu pensi che il const finirà per essere mutabile e che richiedi l'incapsulamento attorno all'accessorio in un dato momento ( per registrare quante volte è stato consultato), potresti anche tenerlo come pubblico const .

Una costante è dati. Le proprietà implicano la possibilità di comportamento quando si "guarda" il valore.

Il comportamento di raggruppamento (o la sua futura possibilità) con dati costanti non è corretto. Per la maggior parte dei sistemi non importa, ma può.

Diciamo che il valore è "PI" e ampiamente utilizzato nei calcoli del sistema. Metterlo dietro le proprietà costringerà i programmatori client a programmare in modo difensivo. Devono assegnare il valore in una costante duplicata. Se non ingannano, la versione successiva della libreria potrebbe avere un "comportamento" indesiderato introdotto dietro la proprietà. Il comportamento della proprietà (se si trova in una libreria compilata) è sconosciuto. Forse funziona bene in fase di test, ma potrebbe esserci un codice nascosto che viene eseguito se viene soddisfatta una condizione speciale. Questa non è un'ottimizzazione pre-matura. Soprattutto per un sistema in tempo reale, la vita delle persone dipende da.

I programmatori client potrebbero persino perdere la sicurezza di una costante poiché la lingua potrebbe non consentire loro di assegnare un valore di proprietà alla loro costante duplicata.

Inoltre, quando i programmatori sono costretti ad assegnare il valore della proprietà alla propria costante, annullano efficacemente qualsiasi comportamento si sperava di ottenere con la proprietà.

I dati della costante costante non richiedono o vogliono l'incapsulamento.