Sign in to follow this  

Would you consider this an invariant?

This topic is 4865 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Bjarne Stroustrup says:
Quote:
My rule of thumb is that you should have a real class with an interface and a hidden representation if and only if you can consider an invariant for the class.
Quote:
An invariant allows you to say when the object's representation is good and when it isn't.
So let's say that your program has some data type that represents, say, different levels of players. You might do this: enum PlayerLevel { beginner, intermediate, advanced }; The only valid player levels are beginner, intermediate, and advanced. Anything else isn't valid. Would you consider this an invariant to be maintained? Would you create a class for this and similar situations where all you want is an int that can only have certain values? If you would consider this an invariant to be maintained, and create a class for it, how would you go about it? I have tried creating individual classes that accomplish this, but I end up writing the same int wrapper class over and over with only small variations. I've also created a template class that allows you to do something like this:
// Here, 'i' will be internally implemented as an unsigned long
// and will cause an error of some kind if the value is outside
// the range of [0,100].
BoundedInt<0, 100, unsigned long> i;

// Then I can do something like this...
class PlayerLevel : public BoundedInt<0, 2> {
    // ...
};

// Or this...
class PlayerLevel
{
    BoundedInt<0, 2> level_;
    // ...
};

I would probably use asserts to enforce the invariant inside BoundedInt<>, so the bounded int would still operate with almost no overhead. What do you think about handling this situation? Invariant or not? Class or something else?

Share this post


Link to post
Share on other sites
Well i think the invariant you need could be described something like:
"Belongs to collection: Playerlevel"

Meaning that your variable should be part of the range of vars that are included in the collection: Playerlevel.

I think that a enum enforces this invariant pretty good. Because thanks to C++'s strong typing, any "variable" of the enumarate Playerlevel is guarenteed to be part of that collection.

To put it in a few words: just use a enum. :)


Edit: i just realized that this invariant only works at compile-time of course. So if you are reading in a PlayerLevel value from eg. a file. Then you indeed need to have some runtime way of checking that it is a valid value.

Share this post


Link to post
Share on other sites
The enum idea sounds good for most situations. However (IMHO), the invariant should not only be enforced, but also add readability/accessibility to your code. To this end, adding a simple interface (LevelUp or LevelDown) would probably serve you better in the long run.

Share this post


Link to post
Share on other sites

This topic is 4865 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this