Is creating an empty class purely to distinguish it from another class good practice?

Question

I have a class CardStack. I have several classes that inherit from CardStack e.g. Cascade, Deck, Foundation etc.

Foundation doesn't need to add any functionality to CardStack, but for display purposes my app needs to know which of the CardStacks are actually Foundations.

Incidentally, I have no such function CardStack.Display() (I'm using a model-view-controller pattern where the View object simply queries the Model to find out what type of objects it's dealing with).

It seems OK to me, but is there any reason not to do this?

class Foundation : public CardStack
{

};

class Model
{
    Cascade cascade[10];
    Foundation foundations[10];
    ...
};

Answer 1

Nothing wrong with this.

Do it all the time.

In the future, there may be a difference in structure, behavior or implementation. For now, they happen to share a lot of common features.

Answer 2

I don't see any technical problem with it, so maybe you're doing this for semantic reasons. In that case, make sure you document the reason it VERY CLEARLY so maintenance programmers later on don't try and change things.

Answer 3

Yep, this is valid and useful. An empty class can act as placeholder for future functionality (as example). Of course, a bit of documentation is in order if the class in question is "connected" to the program in any way ;-)

In your case above, the C++ code generated won't be burdened... but readability of your code is increased.

Answer 4

Nothing wrong with it, I do this often. I like it better than empty "marker" interfaces (in Java). As others have mentioned, you should probably comment on the fact that the implementation is supposed to be empty (or perhaps "reserved for future use"), but otherwise IMHO you're fine.

Answer 5

I do it all the time for lists

public class MyObjects : List<MyObject> { }

Answer 6

It's good practice, since it is semantically clearer with nearly, with nearly no cost associated and allows for modifications, when the need arises for subclasses do behave differently.

Answer 7

The way you did it the Model class it seems to me that typedef will suffice to distinguish names (and readability!): http://en.wikipedia.org/wiki/Typedef