Abstract classes

• As we move up the class hierarchy, classes typically change from being concrete to being abstract
• A concrete class is meant to have objects instantiated from it
• An abstract class cannot be instantiated, and is defined using the keyword abstract

  abstract class Animal {
                      
  }

• The following will now give a compile-time error:

  Animal a = new Animal("Centipede");

Abstract methods

• Concrete classes must have implementations (bodies) for all methods
• Abstract classes do not have to provide bodies for all methods
• Methods without bodies are abstract methods, e.g.:

  public abstract void talk();

• We use abstract methods as placeholders for methods that can sensibly be mentioned at superclass level, but which are going to properly implemented in a variety of ways at subclass level
  • better than a 'dummy' implementation in the superclass
• You must override the abstract method in every concrete subclass
  • otherwise, you get a compile-time error

Example of an abstract class

abstract class Animal {
            
    protected String breed;
    
    public Animal(String breed) {
        this.breed = breed;
    }
    
    public String getBreed() {
        return breed;
    }
    
    public abstract void talk();
    
}

An incorrect alternative

• You might be tempted instead to altogether omit the talk method from the superclass:

  abstract class Animal {
              
      protected String breed;
      
      public Animal(String breed) {
          this.breed = breed;
      }
      
      public String getBreed() {
          return breed;
      }
      
  }

• But now SingAlong.java will give a compile-time error

Why won't it compile?

• Consider this (which also will no longer compile):

  Animal a = new Cow();
  a.talk();

• The compiler sees that the variable a is of type Animal and complains that this has no talk method
  – even though at run-time it is Cow's talk method that will be executed
• The compiler is being cautious: it wants to be sure that whatever a ends up containing will definitely have a talk method
• It knows that if Animal had a talk method, then whatever a ends up containing will have one (if only by inheritance)
  • so omitting talk from Animal is not possible
  • you must either include a 'dummy' method or an abstract one

Another example, cont'd

• Suppose we also want to ensure that all subclasses of Shape (current and future) will have a getArea method
• We could define a 'dummy' version in Shape, which will be inherited, e.g.

  public double getArea() {
      return 0.0;
  }

  This isn't satisfactory
  1. it's a hack, and
  2. there's a risk that you will forget to override it with sensible definitions in subclasses
• The solution is to have an abstract method in Shape

Shape, an abstract class

class abstract Shape {
       
       protected int x;
       protected int y;
       
       public Shape(int x, int y) {
           this.x = x;
           this.y = y;
       }
       
       public void move(int xChange, int yChange) {
           x = x + xChange;
           y = y + yChange;
       }
       
       public abstract double getArea();
}

One of the subclasses

class Circle extends Shape {

    private int radius;
    
    public Circle(int x, int y, int radius) {
        super(x, y);
        this.radius = radius;
    }
    
    public double getArea() {
        return 3.142 * radius * radius;
    }
              
}