The general age-old principle is: Stick with interfaces until you're forced to write an abstract class.

An interface in Java is a non-instantiable type which defines a public interface that other types can choose to conform to.

• Interfaces can declare public methods, which must be defined by their implementors. All such methods are implicitly abstract, so you don't need to use the word abstract.
• In old versions of Java, interfaces could not have default implementations, so every method was abstract. This is no longer the case, and interfaces can now have default implementations that get used in implementing classes unless replaced.
• In recent versions of Java, interfaces can declare private helper methods. These can help in implementing default implementations.
• Interfaces can never have constructors or instance variables.
• A class can implement several interfaces.

An abstract class is just a class that cannot be instantiated. Abstract classes are not required to define any abstract methods, though you'll usually want to.

• Abstract classes can declare methods with any visibility: public, private, protected, and package-private.
• Abstract classes can implement methods or leave them abstract. Methods in an abstract class are not implicitly abstract and must be marked as such.
• An abstract class can have constructors, which must be called by extending classes in their own constructor using super. An abstract class can have instance variables of any visibility, and these work just like instance variables in any parent class.
• A class can only extend one class, either an abstract one or a concrete one. A class' abstractness does not change the number of superclasses it's allowed to have.

abstract classes should be the exception and not the norm. You should use an abstract class if you need to maintain some internal state while also letting subclasses define your own behavior. A great example of this comes from the Java Swing GUI library: AbstractButton. AbstractButton is the abstract parent of things that behave vaguely like buttons in a window, including buttons, toggle buttons, and items in a menu. Anyone can subclass AbstractButton and implement its members to define a button-like display. But AbstractButton also has to maintain a lot of internal state (much of it coming from JComponent) in order to communicate with the window and with the Swing API as a whole.

If you want to define the public interface for a collection of types, use an interface. If you want to provide default implementations for some of those methods and are using a version of Java released after 2014, use interfaces. If you need default implementations but are stuck in the 2000s, use an abstract class. Regardless of Java version, if you need private state such as instance variables or custom initialization like a constructor, use an abstract class.

In terms of code, they're very similar, which often raises confusion like yours.

Conceptually, I think of it this way. When you inherit from an abstract class, you're saying that you are a type of the class. You have the same attributes.

When you implement an interface, you're saying that you do the things that that interface does.

In one sentence, abstract classes allow you to inherit state/variables/data, interfaces allow you inherit behaviors.

Interfaces

An interface is a contract: The person writing the interface says, "hey, I accept things looking that way", and the person using the interface says "OK, the class I write looks that way".

An interface is an empty shell. There are only the signatures of the methods, which implies that the methods do not have a body. The interface can't do anything. It's just a pattern.

For example (pseudo code):

// I say all motor vehicles should look like this:
interface MotorVehicle
{
    void run();

    int getFuel();
}

// My team mate complies and writes vehicle looking that way
class Car implements MotorVehicle
{

    int fuel;

    void run()
    {
        print("Wrroooooooom");
    }


    int getFuel()
    {
        return this.fuel;
    }
}

Implementing an interface consumes very little CPU, because it's not a class, just a bunch of names, and therefore there isn't any expensive look-up to do. It's great when it matters, such as in embedded devices.

Abstract classes

Abstract classes, unlike interfaces, are classes. They are more expensive to use, because there is a look-up to do when you inherit from them.

Abstract classes look a lot like interfaces, but they have something more: You can define a behavior for them. It's more about a person saying, "these classes should look like that, and they have that in common, so fill in the blanks!".

For example:

// I say all motor vehicles should look like this:
abstract class MotorVehicle
{

    int fuel;

    // They ALL have fuel, so lets implement this for everybody.
    int getFuel()
    {
         return this.fuel;
    }

    // That can be very different, force them to provide their
    // own implementation.
    abstract void run();
}

// My teammate complies and writes vehicle looking that way
class Car extends MotorVehicle
{
    void run()
    {
        print("Wrroooooooom");
    }
}

Implementation

While abstract classes and interfaces are supposed to be different concepts, the implementations make that statement sometimes untrue. Sometimes, they are not even what you think they are.

In Java, this rule is strongly enforced, while in PHP, interfaces are abstract classes with no method declared.

In Python, abstract classes are more a programming trick you can get from the ABC module and is actually using metaclasses, and therefore classes. And interfaces are more related to duck typing in this language and it's a mix between conventions and special methods that call descriptors (the __method__ methods).

As usual with programming, there is theory, practice, and practice in another language

I will give you an example first:

public interface LoginAuth{
   public String encryptPassword(String pass);
   public void checkDBforUser();
}

Suppose you have 3 databases in your application. Then each and every implementation for that database needs to define the above 2 methods:

public class DBMySQL implements LoginAuth{
          // Needs to implement both methods
}
public class DBOracle implements LoginAuth{
          // Needs to implement both methods
}
public class DBAbc implements LoginAuth{
          // Needs to implement both methods
}

But what if encryptPassword() is not database dependent, and it's the same for each class? Then the above would not be a good approach.

Instead, consider this approach:

public abstract class LoginAuth{
   public String encryptPassword(String pass){
            // Implement the same default behavior here 
            // that is shared by all subclasses.
   }

   // Each subclass needs to provide their own implementation of this only:
   public abstract void checkDBforUser();
}

Now in each child class, we only need to implement one method - the method that is database dependent.