0

Why can't we have a normal class with empty methods in it, and then sub-classes which override the base-class' empty methods, instead of an abstract class? For example:

class Base {
    
    void methodA() {
        //empty
    }
    
    void methodB() {
        //empty
    }
}
    
class Sub extends Base {

    void methodA() {
        //implementation
    }
    
    void methodB() {
        //implementation
    }
}
Henry Twist
  • 5,666
  • 3
  • 19
  • 44
hamal
  • 55
  • 6
  • 3
    Who says you can't? – khelwood May 17 '21 at 15:24
  • so what's the point of abstract class? – hamal May 17 '21 at 15:25
  • so you can't create a new object of that class, which might confuse people since they might think that it should be used. if you have an abstract class, it is telling users that you can't use it. they might be confused if they call a method and nothing happens – null_awe May 17 '21 at 15:25
  • You can. Nothing is stopping you from doing that if the code is structured the way it is in your example, but it won't always work. Declaring a class as abstract gives a potential instantiator of the class a very strong indication (a compiler error) that it absolutely does not make sense to instantiate `Base` in its own right, and that a child class must be instantiated instead. In plenty of cases involving inheritance, this additional restriction is not just desirable, it is necessary. – Michael May 17 '21 at 15:26
  • The point of abstract classes and methods is that abstract classes cannot be instantiated and abstract methods have to be overridden in a subclass. It's quite simply a tool to make code more manageable and reduce errors. When I create a subclass i don't want to check the super-class source code for empty methods and comments of the original author to see what i need to override. I instead want the compiler to tell me what i need to override. – OH GOD SPIDERS May 17 '21 at 15:27
  • Does this answer your question? [Abstract class in Java](https://stackoverflow.com/questions/1320745/abstract-class-in-java) – Gautham M May 17 '21 at 17:00

2 Answers2

3

I assume that what you really ask is "Why do we need abstract classes/methods, when we can just have a normal class with empty methods instead".

And the answer to that question is that with the abstract method, the sub class MUST provide an implementation. If the method is not in parent is not abstract, then nothing requires the sub to provide an implementation at all.

This is important in cases where an empty implementation of a method makes no sense, because then the compiler can give you an error, because your sub class have not implemented all required methods.

MTilsted
  • 5,425
  • 9
  • 44
  • 76
1

In your specific case, where you have 2 methods which don't return anything, it may be alright to do what you're doing. It's kind of flirting on the edges of the null object pattern, but not quite. There's nothing stopping you from doing it that way; it will compile. In some designs, it may even be a good choice. Your example is too contrived to say whether or not it's a good idea.

Suppose you have a method which returns a value, though. You can't just put a comment //do nothing because you need a return to satisfy the compiler. So you add a sentinel value. This is pretty error prone, as it relies on callers being aware of the values which have special meanings. It may even be the case that no suitable sentinel value even exists, if the set of genuine results contains every possible value.

class Base {
    void methodA() {
        //empty
    }
    
    int getFoo() {
        // Don't do this, just an example
        return -1;
    }
}

Someone might instantiate new Base() and not realise that their code is destined to be useless, and that the class's author intended for them to instantiate Sub or another child class. They might not know they're supposed to check sentinel values, etc.

It would be better in this case if they couldn't do that. It would be better to mark Base as an incomplete implementation, and tell the compiler that it must be completed to be any use. This is precisely what abstract classes are for.

By marking a class as abstract, you are telling the compiler that users are not allowed to instantiate this class because, for whatever reason, doing so does not make sense.

By marking a method as abstract, you are telling the compiler that a child class must provide an implementation in order to itself be instantiable (the child class could also be abstract, kicking the can down the road to child class of itself to provide an implementation).

abstract class Base {
    void methodA() {
        //empty
    }
    
    abstract int getFoo();
}

TL;DR your one specific example does not prove that abstract classes have no utility.

Michael
  • 41,989
  • 11
  • 82
  • 128