Undvik public const i libraries

Dagens läxa: använd public static readonly istället för public const.

I korthet: det är oftast bättre med run-time class constants (konstanta klassvariabler) än compile time constants (inkompilerade konstanter), eftersom de senare kompileras som fasta värden in i assemblies.

Om du använder inkompilerade konstanter i ett library, och har ett annat assembly som är beroenda av ditt library, så kommer även detta andra assembly att kompilera in dina konstanta värden. Effekten blir att alla assemblies som refererar till ditt library måste kompileras om igen när du ändrar på en konstants värde. Använder du istället konstanta klassvariabler (public static readonly) slipper du denna effekt eftersom konstanternas värden sätts i run-time istället för vid kompilering. Sammanfattningsvis, om du vill ha flexibilitet för konstanter som kan komma att ändras så är det detta som gäller:

public static readonly type identifier

Enumerationer då? Ja, enum resulterar också i inkomplilerade konstanter och lider följaktligen av samma fenomen. Även här måste du alltså vara försiktig om det finns andra assemblies som är beroende av din kod. Microsoft formulerar det så här:

Assigning additional values [to] new versions of enums, or changing the values of the enum members in a new version, can cause problems for dependant source code. It is often the case that enum values are used in switch statements, and if additional elements have been added to the enum type, the test for default values can return true unexpectedly.

If other developers will be using your code, it is important to provide guidelines on how their code should react if new elements are added to any enum types. [enum (C# Reference)]

Nåja, på det stora hela är väl det här inget stort problem; enums brukar ju vara hållbara över tiden och med lite versionshantering av dina assemblies så fixar det sig även med andra inkomplierade konstanter.

Mer detaljer och resonemang här: Constant Comprehension

Technorati tags: .net, development