M
Magnus Lidbom
cody said:
You think it would mean more typing? Maintainability problems?
Let's compare the way you'd expose a piece of state, that must not be
modified, from your class in C# as is, and with const:
A commonly recommended workaround for not having const:
//Write a const interface, an interface exposing only members
//that don't modify an instance
public interface IConstState
{
int MyValue{get;}
}
//Have your state class implement the interface
public class State : IConstState
{
private int myValue;
public int MyValue
{
get{return myValue;}
set{myValue = value;}
}
}
//Have the containg class expose a property that returns the interface
public class MyClass
{
private State myState;
public IConstState MyState
{
get{return myState;}
}
}
With const:
1. The interface disappears
2. You write const four times:
//Correctly use const in your state class.
public class State
{
private int myValue;
public int MyValue
{
//Imaginary syntax saying that the value returned is const and the
//method is const(may be invoked on a const instance)
const get const{return myValue;}
set{myValue = value;}
}
}
//Have the containg class expose a property that returns a const instance.
public class MyClass
{
private State myState;
public State MyState
{
const get const{return myState;}
set{myState = value;}
}
}
So far it's not too big a difference. Const interfaces seem to work. With a
bit more typing, and a bit of obfuscation, but still. But now you find that
you need the ability to set MyState. What do you do? You can't use an
interface for assignment to your property. Properties cannot have different
types for get and set. Ok, so you need two properties, but that would be
very bad for legibility so you'll propably use two methods so you can keep
naming consistent:
public void SetState(State value)
{
myState=value;
}
public IConstState GetState()
{
return myState;
}
Ok, so far so good. It's sort of ugly, but hell it works. But now you
remember, darn I expose instances of MyClass that may not be modified. You
sigh deeply and code this:
public interface IConstMyClass
{
IConstState GetState();
}
and rework MyClass to have separate GetState and SetState methods.
What do you need to do if you have const to make this work? Nothing! The
const MyClass version already supports this. In all of this coding, if you
make a mistake in what you do with the interface workaround you end up with
instances being modified when they must not be. If you make the same mistake
with const your code will not compile.
So what have you?
1. Less code (35 lines agains 21 if you write it all out without the
comments using identical conding style):
2. Clearer code. (Consistent types that express intent.)
3. Safer code. (The compiler guarantees that you don't violate your
promises.)
4. Easier to maintain code(No need to maintain interfaces and very nearly
half the code disappears.)
Const is a bad thing? I don't think so.
/Magnus Lidbom