Information Technology Reference
In-Depth Information
If you run your little test, you see the following obvious output:
Value is 5
Value is 6
...
Value is 9
Time passes, and you release a new version of the Infrastructure assembly
with the following changes:
public class
UsefulValues
{
public static readonly int
StartValue =
105
;
public const int
EndValue =
120
;
}
Yo u d i s t r i b u t e t h e I n f r a s t r u c t u r e a s s e m b l y w i t h o u t r e b u i l d i n g y o u r A p p l i -
cation assembly. You expect to get this:
Value is 105
Value is 106
...
Value is 119
In fact, you get no output at all. The loop now uses the value 105 for its
start and 10 for its end condition. The C# compiler placed the
const
value
of 10 into the Application assembly instead of a reference to the storage
used by EndValue. Contrast that with the StartValue value. It was declared
as
readonly
: It gets resolved at runtime. Therefore, the Application assem-
bly makes use of the new value without even recompiling the Application
assembly; simply installing an updated version of the Infrastructure assem-
bly is enough to change the behavior of all clients using that value. Updat-
ing the value of a public constant should be viewed as an interface change.
Yo u m u s t r e c o m p i l e a l l c o d e t h a t r e f e r e n c e s t h a t c o n s t a n t . U p d a t i n g t h e
value of a read-only constant is an implementation change; it is binary
compatible with existing client code.
On the other hand, sometimes you really mean for a value to be deter-
mined at compile time. For example, consider a set of constants to mark
different versions of an object in its serialized form (see Item 27). Persist-
ent values that mark specific versions should be compile-time constants;
they never change. The current version should be a runtime constant,
changing with each release.
