At first glance it sounds reasonable to use inheritance to separate different types of entities: this is the "real-world" approach to OOAD that most colleges teach in CS101. In other words, classes are named based on real-world objects that we can see: desk, dresser, door, etc.
However, that makes little sense in the context of a video game. There are really two categories of concern with the objects you are modeling:
The objects appear on screen and need to be drawn, so it makes sense to model them using classes. After all they have both properties (a sprite or 3D model) and behavior (e.g. movement) which make them candidates for classes.
The objects interact. A player object might interact with a brick block (this is a Mario clone, after all) by standing on it or smashing it. The object might interact with an enemy by stomping on it.
When I analyze these potential classes, I see a lot of the same concerns. Some object move, some do not. Some have "intelligence" behind them (AI or human), some do not. I do not see much value in the hierarchy you presented: the concerns are spread out too much.
I recommend moving the concerns about object control outside of the objects themselves. Here is how I would design it, based loosely on MVC.
Actor would replace Object in your hierarchy. The idea is an actor has some role on the game field. That role might be "do nothing" in the case of a brick that is unsmashable and performs no actions. It might be able to remove itself from the game field (brick gets smashed). It might move: this could be a platform that patrols on a loop, an enemy with an AI, or a player that receives input from a hardware device.
ActorView is passed in to an Actor and controls how it is displayed. This could be as simple as "always display this sprite" or "render this 3D model based on certain criteria."
ActorController is the "brain" of the Actor. One could have a "do nothing" implementation that never changes state (e.g. an unbreakable brick), a simple implementation that can remove the actor (e.g. a breakable brick), a more complex implementation (e.g. a platform that patrols back and forth), an AI implementation (e.g. an enemy), or a player (use hardware input).
Now you can use composition: Actor should really just be one class that takes a view and a controller. The ActorView might have a small number of subclasses that can be reused. Do you really need a different view for each static brick? No, you can simply reuse one class and pass a different bitmap in each time. ActorController could have a small number of subclasses for each broad type of Actor: static, scripted (moves, breaks), AI, player.