0

I know about the conceptual use behind creating an abstract class, i.e. defining a common interface for its subclasses where some of the implementation is left to the individual subclasses.

Am I correct in my assumption that there is technically no necessary need for abstract classes, since you can overwrite a superclass method anyway? Were abstract classes just created to make the intention of the classes clearer to the developer?

Example of what I mean:

// Using an abstract class
abstract class Car
{
    int fuel;

    int getFuel()
    {
         return this.fuel;
    }

    abstract String getColor();
}

class RedCar extends Car
{
    String getColor()
    {
        return "red";
    }
}


// Without an abstract class
class Car
{
    int fuel;

    int getFuel()
    {
         return this.fuel;
    }

    String getColor()
    {
         return "defaultColor";
    }

class RedCar extends Car
{
    String getColor()
    {
        return "red";
    }
}
user3545063
  • 681
  • 8
  • 17
  • Before default methods were added to interfaces, the abstract class was one way to allow classes to share common functionality (and code). If your abstract class consisted of only abstract methods, then an interface was always a better choice. – Elliott Frisch Jan 04 '19 at 00:14
  • 2
    There is "technically" no reason to have anything except bytecode, so that argument goes right out the window. Abstract classes let you define the underlying common functionality of a set of objects, without the common aspects themselves constituting a sensible class that should be instantiable. For instance, a bank account is an abstract concept: it's tied to a person, it can be use for deposits and withdrawals, but "a bank account" is nothing, and allowing code to make "a bank account" rather than "a chequeing account" or "a savings account", etc. makes no sense. So, abstract it is. – Mike 'Pomax' Kamermans Jan 04 '19 at 00:27
  • Also any half-decent website or book that teaches Java will explain why abstract classes are useful. – Mike 'Pomax' Kamermans Jan 04 '19 at 00:27
  • Abstract classes allows to implement algorithms with variable parts, where the variable parts are the abstract methods. An example would be template method design pattern, check [Implementing the Template Method Pattern in Java](https://www.baeldung.com/java-template-method-pattern) for more details –  Jan 04 '19 at 00:34
  • It's like a class-interface hybrid. It must be extended if you want to construct an object from it (like an interface), it can have methods that are already defined (like a regular class), and it can have methods that must be defined by the subclass (like an interface). – Cardinal System Jan 04 '19 at 00:45
  • It may not be important in practice, but method dispatch can sometimes be implemented more efficiently for single inheritance (as for classes) than for multiple inheritance (as for interfaces). – Davis Herring Jan 04 '19 at 00:52

2 Answers2

5

Were abstract classes just created to make the intention of the classes clearer to the developer?

That's right, but it also prevents developers from doing "silly" things.

For example, you cannot create instances of abstract classes. In the context of your code, it does not make sense to create a "general" Car. You can only create a BlueCar or a RedCar or some other subclass. While instances of an anonymous subclass may seem like instances of an abstract classes, they are in the end constructed from subclasses. If you made the Car class abstracted, however, developers will not accidentally create an instance of Car, because the compiler would complain.

Abstract classes also forces developers to implement the abstract methods. With your non-abstract Car class, I can inherit it and forget that I need to override getColor. Now some other parts of the code might call getColor and gets a nonsensical result "defaultcolor". What the heck is a default color? Making the method abstract forces the subclasses to think about implementing the required methods.

Cardinal System
  • 2,749
  • 3
  • 21
  • 42
Sweeper
  • 213,210
  • 22
  • 193
  • 313
  • I believe [this](https://stackoverflow.com/a/13671003/5645656) is worth mentioning in your answer. It could serve some good to future viewers. – Cardinal System Jan 04 '19 at 00:47
  • @CardinalSystem I am not quite sure how to insert that link in a place that feels natural. Feel free to suggest an edit. – Sweeper Jan 04 '19 at 00:54
-1

Most people I know avoid abstract classes. From an application programmers point of view, my opinion is that abstract classes should be avoided. Using interfaces are so much more flexible not forcing your work to adhere to a class hierarchy.

a bit formally: an abstract class is strict inheritance, while interfaces are composition.

An example where abstract classes are useful is when making class libraries. The hierarchy that abstract classes enforces, can make the library more easily understandable for application programmers. However, I do believe this comes at the cost of longer development times of the library.

Stefan Karlsson
  • 1,092
  • 9
  • 21
  • To be fair, abstract classes were a lot more popular in the days before languages supported interfaces. Even so, the use of inheritance to enhance or restrict or refine base classes is still a major reason to use abstract classes. In this regard, interfaces makes abstract classes more powerful as it allows even the changes to classes to be abstracted. – Peter Camilleri Jan 04 '19 at 02:24
  • Almost no one uses abstract classes when writing applications. What often happens in the end, near delivery, is that there is argument around which interfaces should be morphed into abstract classes. If the final deliverable is something like a class library, then I admit that this work is worthwhile. However, if its an application that will likely change a lot in the future, it makes more sense to keep all the interfaces as is. – Stefan Karlsson Jan 04 '19 at 09:39