Of course you can, I'm just wondering if it's rational to design in such a way.I'm making a breakout clone and was doing some class design. I wanted to use inheritance, even though I don't have to, to apply what I've learned in C++. I was thinking about class design and came up with something like this:GameObject -> base class (consists of data members like x and y offsets, and a vector of SDL_Surface*MovableObject : GameObject -> abstract class + derived class of GameObject (one method void move() = 0; )NonMovableObject : GameObject -> empty class...no methods or data members other than constructor and destructor(at least for now?).Later I was planning to derive a class from NonMovableObject, like Tileset : NonMovableObject. I was just wondering if empty abstract classes or just empty classes are often used...I notice that the way I'm doing this, I'm just creating the class NonMovableObject just for sake of categorization.I know I'm overthinking things just to make a breakout clone, but my focus is less on the game and more on using inheritance and designing some sort of game framework.
Can You Have Empty Abstract/Classes?
class design
In C++ you have Multiple Inheritance so there is literally no benefit to having those empty classes. If you want to have Ball inheriting from GameObject and MovableObject later (say, for example, you want to hold an array of GameObjects and call a Tick method every nth of a second to make them all move), that's easy enough to do.But, in that situation, I would personally suggest that you remember the axiom prefer composition (encapsulation) over inheritance instead and look at the State pattern. If you want each object to have its movement state later, pass it to the GameObject. For example: DiagonalBouncingMovementState for the ball, HoriazontalControlledMovementState for the paddle, NoMovementState for a brick. 1) This will make it easier for you to write unit tests, if you choose to (which, again, I would recommend) - because you can test GameObject and each of your states independently.2) Say you have tokens dropping from the bricks but then you want to change one of them so that they move diagonally - rather than shifting it around some complex hierarchy of class inheritance, you can just change the hardcoded movement state which gets passed to it.3) Most importantly: When you want to start changing in-game how the ball and/or paddle move based on those tokens, you just keep changing its movement state (DiagonalMovementState becomes DiagonalWithGravityMovementState).Now, none of this was to suggest that inheritance is always bad, just to demonstrate why we prefer encapsulation over inheritance. You may still want to derive each type of object from GameObject and have those classes understand their initial Movement State. You will almost certainly want to derive each of your movement states from an abstract MovementState class because C++ doesn't have interfaces.$0.02