Are there any reasons to have an abstract class with every method in the class defined?

Question

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

Answer 1

If a Java class is declared abstract yet has all of its methods declared, then they are doing it so it cannot be instantiated, though it may be subclassed.

"Abstract classes cannot be instantiated, but they can be subclassed." See here: https://docs.oracle.com/javase/tutorial/java/IandI/abstract.html

Answer 2

One typical use case is the creation of an adapter class. Think of a callback interface where you could be notified of 10 different events but are normally only interested in some of them. With an adapter class, you can provide empty implementations such that an actual callback only needs to implement those methods that are of interest after extending the adapter. By making the adapter abstract, you express the fact that it makes no sense to instantiate the adapter itself as it does nothing useful.

Since Java 8, you would not longer implement such an adapter but use default methods for the interface.

Answer 3

Yes, there is. Sometimes you know you're creating an abstract class - one that will have to be derived from to make any actual sense, but you want to provide a default implementation to all the methods. This doesn't happen a lot, but it does happen.

UPDATE: I just had a case like this. I'm recording various user generated events. Each event has a TimeSpan and a Description, and they all have other things as well. I've created a base event class:

public abstract class BaseEvent
{
    public TimeSpan EventTime {get; private set;}
    public string Description {get; protected set;}

    public BaseEvent(TimeSpan time, string desc) ...
}

Granted, this is C# and not Java, but had I written this in Java, I would have done exactly the same thing)

Answer 4

You might have some classes that don't make sense in the context of your application but they do in the design. A silly example: Abstract class animal, implement born and die. You don't want an "animal". You want a Dog. This way you don't have to repeat the code each class you add. Now you can have Dog, Cat or whatever you want, this would be a good reason, anyway it's hard to find.

Answer 5

You can have an abstract class that implements several interfaces. You need not implement these methods in an abstract class, but you do need to implement them in a subclass of your abstract class.

E.g.

public interface MyInterface{
    void hello();
}

public abstract class Clazzy implements MyInterface {
//I need not have the interface method.
}

public class MySubclass extends Clazzy {

    @Override
    public void hello() {
        // I need to be here
    }

}

Answer 6

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 GameObjects 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.