newbie: How to use global constants?

[deko]

I have WinForms app that uses a lot of constants. The same constants are
often required by different classes - on the different forms, on subclassed
controls, etc.

How do I avoid repeating the declaration of these constants in each class?

Should I put them all in an enumeration? Then I would have to cast every
time I wanted to use them?

 

[Tim Wilson]

You can expose the constants as consts or statics from a dedicated class.
See the section entitled "Static Classes" at the link below.
http://msdn.microsoft.com/msdnmag/issues/06/00/C20/default.aspx

 

[deko]

You can expose the constants as consts or statics from a dedicated class.

See the section entitled "Static Classes" at the link below.
http://msdn.microsoft.com/msdnmag/issues/06/00/C20/default.aspx

That appears to be the only way to go for global accessibility in C#.

But I don't which is worse...

For now I think I'll just repeat the member-level constants...

 

[Jon Skeet [C# MVP]]

That appears to be the only way to go for global accessibility in C#.

But I don't which is worse...
Why?

For now I think I'll just repeat the member-level constants...

No, that's definitely a bad way to go. You're just asking for trouble
when you do this, as whenever you change a value, you've got to
remember to change it in multiple places.

I would group the constants into logical groups, and name the static
classes appropriately. Alternatively, they may well logically be
constants which belong in existing "normal" classes, and should just be
referenced from other places.

 

[deko]

You can expose the constants as consts or statics from a dedicated class.

Why?

The nice thing about a private const is that it's part of the object. If I want
a public const, I need a public object (not an option). So the way to fake a
public const (or make anything globally accessible) is to use a singleton
pattern. If I have a lot of iteration that need these consts, there's got to be
some price to pay. That price has to be weighed against the chore of manually
updating const definitions in different classes.

 

[Tim Wilson]

If I want a public const, I need a public

object (not an option).

You can just use the class name to access the public const or public static.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/vclrfconstpg.asp

 

[Jon Skeet [C# MVP]]

The nice thing about a private const is that it's part of the object. If I want
a public const, I need a public object (not an option).

No you don't. If something is constant, it *shouldn't* be an instance
field/property - by definition, it can't be something dependent on one
particular instance if it's constant.

Note that the "const" modifier automatically implies "static".

 

[deko]

The nice thing about a private const is that it's part of the object. If I

No you don't. If something is constant, it *shouldn't* be an instance
field/property - by definition, it can't be something dependent on one
particular instance if it's constant.

Note that the "const" modifier automatically implies "static".

I guess that wasn't a good analogy, but isn't the problem the same? In an OO
environment, how do you have things that belong to more than one object at
compile time?

As I understand it, a const becomes "constant" at compile time. So if I go and
fetch a const at runtime, why bother with a const?

 

[Jon Skeet [C# MVP]]

I guess that wasn't a good analogy, but isn't the problem the same? In an OO
environment, how do you have things that belong to more than one object at
compile time?

You make them static. At that point they don't belong to more than one
object - they don't belong to *any* object. They belong to the type
itself, effectively.

As I understand it, a const becomes "constant" at compile time. So if I go and
fetch a const at runtime, why bother with a const?

I don't see what your issue with using const is, I'm afraid.

 

[deko]

I guess that wasn't a good analogy, but isn't the problem the same? In an OO

You make them static. At that point they don't belong to more than one
object - they don't belong to *any* object. They belong to the type
itself, effectively.

Yes, but only that type. Accessing a const from another type obviates the need
for a const. It could just as well be any static member.

 

[Jon Skeet [C# MVP]]

Yes, but only that type. Accessing a const from another type obviates the need
for a const. It could just as well be any static member.

I'm not sure what you're getting at. The difference between const and a
readonly static member is only in terms of whether the value is baked
into the compiled code or whether it does a runtime reference - this is
rarely a big difference.

The important things are:
1) You only have to specify the constant once
2) You can place the constants logically, because the name is still
effectively scoped by the type.

I just don't see what problem you're trying to solve which isn't
already solved by const or public static readonly fields/properties.