Usage of abstract methods and classes unclear

Question

I am learning the concepts of object-oriented programming. One of them is abstraction. I understand that any class containing an abstract method should be abstract as well and that an abstract class cannot be instantiated. To use an abstract class I have to inherit it from another.

So far so good. Let's take the following code:

public abstract class Games {

   public abstract void start();

   public void stop(){
       System.out.println("Stopping game in abstract class");
   }
}

class GameA extends Games{
   public void start(){
       System.out.println("Starting Game A");
   }
}

class GameB extends Games{

   public void start(){
       System.out.println("Starting Game B");
   }
}

And then we have a class with a main method:

public class AbstractExample {

   public static void main(String[] args){
       Games A = new GameA();
       Games B = new GameB();

       A.start();
       A.stop();

       B.start();
       B.stop();
   }
}

But I could have written the following in class Games:

public void start(){
   System.out.print("");
}

Then it wouldn't have to be abstract, the output would be the same and I would even be able to instantiate the Games class. So what is the key of making abstract methods and classes?

There's a [good explanation](https://softwareengineering.stackexchange.com/questions/96947/why-should-i-declare-a-class-as-an-abstract-class) over on the software engineering stack. — azurefrog, Dec 18 '17 at 16:44
If you can think of a reason to make `Games` a concrete class, then by all means go ahead and implement that method. Abstraction is for classes that it wouldn't make sense to have instances of. — jsheeran, Dec 18 '17 at 16:44
Ask yourself, would the `start()` method as you propose make any sense, if not, that is why you can mark it abstract: when it makes no sense to provide a dummy implementation, and to make absolutely clear that sub-classes **must** implement it. — Mark Rotteveel, Dec 18 '17 at 17:06

score 1 · Accepted Answer · answered Dec 18 '17 at 16:49

Right, so in a sense abstract class / interfaces are contracts that require you to provide your own implementation of the contract. For instance you're writing a logging library that can write to a file, database, etc. Consider how would you mandate any one to implement the functionality to persist to the underlying io. To achieve this you make your code to work with an instance of your interface / abstract class. Now the difference between those two is as simple as interfaces have no implementation. Well, up until Java 8, but nevermind, that's not something to be concerned about ATM. Your abstract class can have certain methods implemented. Such as retry if your write attempt did not succeed. But the actual write operation will only exist in the one implementing it. The interface can not.

score 0 · Answer 2 · answered Dec 18 '17 at 16:49

0

Abstract classes don't make much sense on a single programmer project. You can see them as a commitment acquired by the programmer who inherits from that class of implementing some method/s.

answered Dec 18 '17 at 16:49

Andres

10,561
4
45
63

Even in a single programmer project abstract classes make sense, they are a behavioral template, where the implementing subclass 'fills in the blanks'. – Mark Rotteveel Dec 18 '17 at 17:04
Why would you do that to yourself? :) – Andres Dec 18 '17 at 17:06
Why not? It doesn't make it 'harder' and it provides a form of self-documentation that might be helpful when you revisit that code months if not years later. – Mark Rotteveel Dec 18 '17 at 17:08

Usage of abstract methods and classes unclear

2 Answers2