When to Use Abstract Classes

When and Why to use abstract classes/methods?

I know the basic use of abstract classes
is to create templates for future
classes. But are there any more uses
of them?

Not only can you define a template for children, but Abstract Classes offer the added benefit of letting you define the functionality that your child classes can utilize later.

You could not provide a default method implementation in an Interface prior to Java 8.

When should you prefer them over
interfaces and when not?

Abstract Classes are a good fit if you want to provide implementation details to your children but don't want to allow an instance of your class to be directly instantiated (which allows you to partially define a class).

If you want to simply define a contract for Objects to follow, then use an Interface.

Also when are abstract methods useful?

Abstract methods are useful in the same way that defining methods in an interface is useful. It's a way for the designer of the Abstract class to say "any child of mine MUST implement this method".

When is it necessary to use an abstract class?

In what type of (specific) situation would it be beneficial to use abstract classes?

You would want to use an abstract class when you want to provide some predefined methods in the base class without allowing the user to instantiate the base class as only more specific subclasses that define the rest of the behavior are good enough classes to stand alone and be used.

Also, I have read that you can use them to "partially implement your class." What exactly does this mean?

It means you can if you want only declare methods (label them abstract), in which subclasses have to define them, while also being able to define methods in the abstract class that all subclasses can also make use of.

And my final question is, could extending a regular class achieve similar results?

Only if the objects of the base class are useable by themselves.

When to use abstract classes?

Abstract classes are useful when you need a class for the purpose of inheritance and polymorphism, but it makes no sense to instantiate the class itself, only its subclasses. They are commonly used when you want to define a template for a group of subclasses that share some common implementation code, but you also want to guarantee that the objects of the superclass cannot be created.

For instance, let's say you need to create Dog, Cat, Hamster and Fish objects. They possess similar properties like color, size, and number of legs as well as behavior so you create an Animal superclass. However, what color is an Animal? How many legs does an Animal object have? In this case, it doesn't make much sense to instantiate an object of type Animal but rather only its subclasses.

Abstract classes also have the added benefit in polymorphism–allowing you to use the (abstract) superclass's type as a method argument or a return type. If for example you had a PetOwner class with a train() method you can define it as taking in an object of type Animal e.g. train(Animal a) as opposed to creating a method for every subtype of Animal.

When does it make sense to use an abstract class

Abstract classes and interfaces both allow you to define a method signature that subclasses are expected to implement: name, parameters, exceptions, and return type.

Abstract classes can provide a default implementation if a sensible one exists. This means that subclasses do not have to implement such a method; they can use the default implementation if they choose to.

Interfaces do not have such an option. Classes that implement an interface are required to implement all its methods.

In Java the distinction is clear because the language includes the keyword interface.

C++ interfaces are classes that have all virtual methods plus a pure virtual destructor.

Abstract classes and interfaces are used when you want to decouple interface from implementation. They're useful when you know you'll have several implementations to choose from or when you're writing a framework that lets clients plug in their own implementation. The interface provides a contract that clients are expected to adhere to.

When to use abstract classes and when to use interfaces

Generally speaking, use abstract classes when you want a place to put common logic that can be reused between implementations. Otherwise, use an Interface.

Then there are a number of exception, often closely related to design patterns. But keep it simple.

When do I have to use interfaces instead of abstract classes?

From Java How to Program about abstract classes:

Because they’re used only as superclasses in inheritance hierarchies,
we refer to them as abstract superclasses. These classes cannot be
used to instantiate objects, because abstract classes are incomplete.
Subclasses must declare the “missing pieces” to become “concrete” classes,
from which you can instantiate objects. Otherwise, these subclasses, too,
will be abstract.

To answer your question "What is the reason to use interfaces?":

An abstract class’s purpose is to provide an appropriate superclass
from which other classes can inherit and thus share a common design.

As opposed to an interface:

An interface describes a set of methods that can be called on an
object, but does not provide concrete implementations for all the
methods... Once a class implements an interface, all objects of that class have
an is-a relationship with the interface type, and all objects of the
class are guaranteed to provide the functionality described by the
interface. This is true of all subclasses of that class as well.

So, to answer your question "I was wondering when I should use interfaces", I think you should use interfaces when you want a full implementation and use abstract classes when you want partial pieces for your design (for reusability)

Real world examples when to use Abstract class and when to use Java 8 introduced interface(default and static methods)

By introducing default methods in interface, Java 8 may in some cases removes the need to introduce an intermediary abstract/base class that implements the interface with the default behavior for any subclass.

Sometimes, the abstract/base class is still required for other reasons (legacy, needs to contain fields and so for...) but the subclass of it may still benefit from a default implementation without the need to define it.

So the default implementation defined before Java 8 in the base class may be now defined directly in the interface as default methods.

The stream() method defined in the Collection interface is a good example.
AbstractCollection and its subclasses as ArrayList don't need to define it. It is directly inherited from the interface.

How do you know when a class should be abstract?

In general, a class should be abstract when you have absolutely no reason to create an instance of that class. For example, suppose you have a Shape class that is the superclass of Triangle, Square, Circle, etc. Since "Shape" is so general, there shouldn't be any reason to construct a Shape object, so it should be abstract (or perhaps even an interface).