Interface vs. Abstract Class

TIL the difference between an interface and an abstract class.

Well…I guess I didn’t really learn this today, but I wrote up some notes for my AP Computer Science class to help clarify differences between the two and when to use each.

Interface

• Declares can-do relationships between classes.
• When classes promise to implement an interface we can treat those classes similarly in our code.
  • Declare an object of reference type <interface_name>
• In Java, classes can implement many interfaces.
• Interface methods are abstract and public, meaning they do not contain any implementation detail.
• You can leave off the public keyword in interface method headers, since they are always public.
• Cannot instantiate an object of type interface
• Can create object references of type interface with actual object types of the class that implements the interface.
  • This way we can achieve polymorphism through the common interface.

Example: Shapes (triangle, circle, rectangle): Common methods getArea and getPerimeter

• It is better to implement this as a Shape interface, because none of the implementation of the common methods is shared between the shapes.
  • Each method has different implementation details. Calculating the area of a square differs from a triangle differs from a circle…
  • Making it an interface also frees up the single inheritance for some other class as appropriate.

Interface Header: interface <interface_name>

Class That Implements: public class <class_name> implements <interface_name>

Abstract class

• Declares is-a relationships between classes.
• A non-instantiatable class that serves as a super class for common data and behaviors.
  • Can declare data fields.
  • Can define implementation details for methods.
• Use this if you don’t want the client code constructing objects out of a class in the hierarchy, but still want to share common data and code between subclasses via inheritance.
• An abstract class can implement interfaces like a normal class
  • Any methods that are not implemented in the abstract class will need to be implemented by a subclass that inherits from it.
• It may or may not actually contain abstract methods…
  • Even if no abstract methods exist in the class, it still can’t be instantiated as a concrete object type.
• Can have class (static) members and methods. Interfaces cannot.
• Code in an abstract class can call any of its abstract methods, even if they don’t have implementation details in the abstract class.
  • We can do this because the abstract class is never instantiated itself, and we can count on concrete classes that inherit from the abstract class to implement the methods.

Abstract Class Header: public abstract class <abstract_class_name>

Class That Extends: public class <class_name> extends <abstract_class_name>

Note: in the class header above, the extending class must provide implementation detail for all abstract methods in the abstract class, otherwise it must be declared as abstract itself.

General Rules

• If the base class has the potential to update frequently, abstract classes are preferred.
  • If an abstract class is updated (implementation detail, method signatures, etc…) then that new functionality will automatically propagate to the rest of the classes that inherit from it.
  • If an interface is updated (method signatures update or a new method is added) then all classes that previously implemented that interface WILL BREAK.
• If you are creating something that provides common functionality to unrelated classes, an interface is a better bet.
  • This way, unrelated entities don’t need to inherit from the same base class (which implies an is-a relationship).

Writing this was actually quite helpful in clarifying some of the finer differences between interfaces and abstract classes in my own understanding. This is one of the reasons I enjoy teaching!