Question

After making an abstract superclass, when you get to the first concrete subclass, you’ve got to implement all your abstract methods, even if some of those methods aren’t going to be used in that concrete class. SO! Why doesn’t an abstract superclass just make those abstract methods into “fake” methods, like:

public void doThis() { 
     if (1 < 0){ 
          int x = 34
     }
}

it does nothing, since 1 is never less than 0. And then when you get to your concrete subclass, you don’t have to implement ALL those abstract methods, but for the ones that you WANT to implement you can just rewrite into a method you need it to be:

public void doThis() {
      //does "this".
}

Both ways would allow for polymorphism, right? So what are the real advantages of abstract methods that I’m missing?

Thanks!

Answer 1

the idea is to enforce a policy that when you use an abstract class:

a) the class that is abstract cannot be instantiated
and
b) you must “fill in the blanks” for how the abstract stuff is done — in other words, you need to make the abstract stuff concrete.

We don’t need these things, but it makes design intent clear, and clean. It reduces errors. If we were to follow your approach, there would be no compile time check to make sure the ‘rules’ are being followed.

Note that many languages, like javascript, have no notion of ‘abstract’, and people still write good software with javascript.