What is the point of using abstract methods?

Say you have three printers that you need to write drivers for, Lexmark, Canon, and HP.

All three printers will have the print() and getSystemResource() methods.

However, print() will be different for each printer, and getSystemResource() remains the same for all three printers. You also have another concern, you would like to apply polymorphism.

Since getSystemResource() is the same for all three printers, you can push this up to the super class to be implemented, and let the subclasses implement print(). In Java, this is done by making print() abstract in the super class. Note: when making a method abstract in a class, the class itself needs to be abstract as well.

public abstract class Printer{
  public void getSystemResource(){
     // real implementation of getting system resources
  }
  
  public abstract void print();
}

public class Canon extends Printer{
  public void print(){
    // here you will provide the implementation of print pertaining to Canon
  }
}

public class HP extends Printer{
  public void print(){
    // here you will provide the implementation of print pertaining to HP
  }
}

public class Lexmark extends Printer{
  public void print(){
    // here you will provide the implementation of print pertaining to Lexmark
  }
}

Notice that HP, Canon and Lexmark classes do not provide the implementation of getSystemResource().

Finally, in your main class, you can do the following:

public static void main(String args[]){
  Printer printer = new HP();
  printer.getSystemResource();
  printer.print();
}

Besides the reminder that you have to implement it, the big advantage is that anyone who references the object by its abstract class type (including this in the abstract class itself) can use the method.

For instance, let's say we have a class responsible for taking state and manipulating it in some way. The abstract class is going to be responsible for getting the input, converting it to a long (for instance) and combining that value with the previous value in some way -- that "some way" is the abstract method. The abstract class may look something like:

public abstract class StateAccumulator {
    protected abstract long accumulate(long oldState, long newState);

    public handleInput(SomeInputObject input) {
        long inputLong = input.getLong();
        state = accumulate(state, inputLong);
    }

    private long state = SOME_INITIAL_STATE;
}

Now you can define an addition accumulator:

public class AdditionAccumulator extends StateAccumulator {
    @Override
    protected long accumulate(long oldState, long newState) {
        return oldState + newState;
    }
}

Without that abstract method, the base class would have no way to say "handle this state somehow." We don't want to provide a default implementation in the base class, though, because it wouldn't mean much -- how do you define a default implementation for "someone else will implement this"?

Note that there's more than one way to skin a cat. The strategy pattern would involve declaring an interface that declares the accumulate pattern, and passing an instance of that interface to the no-longer-abstract base class. In lingo terms, that's using composition instead of inheritance (you've composed an addition aggregator out of two objects, an aggregator and an adder).