Abstract Class vs Interface

The deciding factor is whether the subclasses share state and shared implementation. Here the abstract class holds the collection, and the shared find method is written once against it. Neither of those is possible through an interface, because interfaces carry no instance state.

public class Main {
    public static void main(String[] args) {
        Repository r = new InMemoryRepository();
        r.save("a");
        r.save("b");
        System.out.println(r.count());
        System.out.println(r.find("a"));
    }
}

abstract class Repository {
    protected final java.util.List<String> store = new java.util.ArrayList<>();
    abstract void save(String item);
    abstract int count();
    String find(String item) { return store.contains(item) ? "found" : "missing"; }
}

class InMemoryRepository extends Repository {
    void save(String item) { store.add(item); }
    int count() { return store.size(); }
}

The output shows what that buys. The in-memory repository only has to implement save and count, and it inherits the find behaviour and the storage. The caller still programs against the abstract type, so it can be swapped for a database-backed implementation later without the caller changing.

There is a second reason to prefer an abstract class, which is visibility. Members of an abstract class can be protected or package-private, so the hierarchy can share internals without exposing them to the world. Interface members are always public, so anything you put in an interface becomes part of everyone's API.

The tie-breaker to state in an interview is this: a class can extend only one abstract class but implement any number of interfaces, so composition through interfaces scales better. Use an abstract class when the subclasses are variations of one thing that genuinely share state, and use interfaces when you are describing capabilities that unrelated classes may have.

Four differences come up repeatedly. First, state: an abstract class can have instance fields, an interface cannot. Second, implementation: an abstract class can provide concrete methods that subclasses inherit, whereas an interface's methods are abstract unless they are default methods. Third, inheritance count: a class extends one class but implements many interfaces. Fourth, visibility: class members can be protected or package-private, while interface members are public.

Those differences produce different design habits. An abstract class is a base for a family of related types, where the base owns the shared state and algorithm. An interface is a role or a capability, which a class can play alongside other roles.

There is also a practical consequence about change. Because an interface is a promise to every implementor, adding a method to it breaks every implementation and every caller. An abstract class can be extended more freely, because you control the whole hierarchy and can add a concrete method with a sensible default without breaking anyone.

None of this makes one of them better. A class can extend an abstract class and implement several interfaces at the same time, and plenty of well-designed frameworks use both. The question to ask is whether the thing you are modelling shares state and code, or whether it is a capability that unrelated things might have.