It seems that an abstract class means the definition of the class is not complete and hence cannot be instantiated.
And I saw some simple Java code which has an abstract
It is possible that even though all the methods had a default implementations, these implementations weren't actually meaningful in the context of the application. The methods might only do internal bookkeeping while the actually useful implementation must be provided by a derived class which does what it needs to do and then calls the superclass method.
However, this is just speculation. You would have to show an actual example to tell what could be the reason for this design.
As an example, let's take a simple game engine. I have lot's of different GameObject
s in my game.
Some are visible, so my basic class gets a draw()
method. But there might be invisible objects like trigger areas which don't show up at all, so I implement it as a no-op in the base class.
Some do something when they collide with something, so each one gets a collide(other)
method. But some don't do anything when they collide like a purely visual particle effect, so I also provide a no-op in the base class.
Some do something every game tick, so they get a update()
method. But some objects, like a wall, might not do anything at all on their own. So I also provide a no-op for this.
So what do I do when I have an object which is invisible, doesn't do anything on its own and doesn't interact with anything? There is no reason to have this in the game. So I make this basic class abstract
. Theoretically you could instance it because all methods have an implementation, but practically you have no reason to ever do this, and when you try, you misunderstood how my game engine works.