-1

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?

Improve this question
3
  • 1
    There's a good explanation over on the software engineering stack. Commented Dec 18, 2017 at 16:44
  • 1
    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. Commented Dec 18, 2017 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. Commented Dec 18, 2017 at 17:06

2 Answers 2

Reset to default
1

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

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.

Improve this answer

3 Comments

Even in a single programmer project abstract classes make sense, they are a behavioral template, where the implementing subclass 'fills in the blanks'.
Why would you do that to yourself? :)
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.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.