Abstraction (Abstract Classes & Interfaces)

An abstract class is a class marked with the abstract keyword that you cannot create objects from directly. It can mix finished methods with unfinished (abstract) methods that subclasses must complete. It can also hold normal fields and constructors.

You write interface Name { ... }. An interface lists method signatures (no bodies) that implementing classes must provide, and it can hold constants. A class uses implements Name to promise it provides those methods.

A default method is an interface method with a body, marked with the default keyword. Classes that implement the interface inherit it for free, so you can add new methods to an interface without breaking existing implementers.

A functional interface is an interface with exactly one abstract method, so it can be implemented by a lambda. @FunctionalInterface is an optional annotation that makes the compiler check that the interface really has just one abstract method.

An interface describes what a class can do (a contract of methods); an abstract class is a partly-finished base class you extend. A class can implement many interfaces but extend only one class. Use an interface for a capability shared by unrelated types; use an abstract class when subclasses share state and code.

In an interface, abstract methods are automatically public abstract, and fields are automatically public static final (constants). You don't have to write those modifiers; the compiler adds them.

List several interfaces separated by commas: class Car implements Drivable, Serviceable. The class must provide methods for all of them. A class can implement many interfaces but can extends only one class.

Ask: is this a capability many unrelated types can have (use an interface), or a family of related types that share data and code (use an abstract class)? If types are unrelated or already extend something, choose an interface. If they're a real is-a family with shared fields, choose an abstract class — or expose an interface and back it with an abstract base.

An abstract class can have instance fields and a constructor, so it can store shared data per object and set it up when the object is created. An interface can't hold per-object data or have a constructor, so it can't manage shared mutable state.

If two interfaces give the same default method, the class won't compile until you resolve the clash. You override the method in the class, and you can pick one parent's version with InterfaceName.super.method().

A marker interface is an empty interface with no methods. A class implements it just to 'tag' itself with a property, like being serializable. Code elsewhere checks 'instanceof' to see if the tag is present and behaves differently. Serializable and Cloneable are examples.

You can't use new on an abstract class because it may have unfinished (abstract) methods, so the object would be incomplete. Its constructor and fields still exist to set up the shared state that subclasses inherit; the subclass constructor calls super(...) to run them.

Since Java 9 an interface can have private methods (and private static methods). They are internal helpers that hold shared logic used by the interface's default or static methods, without exposing that logic to implementing classes.

A static interface method belongs to the interface itself, not to any instance. You call it as Interface.method(...). Unlike a default method, it is not inherited by implementing classes and cannot be overridden.

The abstract class writes the overall algorithm once in a concrete method, but leaves the varying steps as abstract methods it calls. Subclasses fill in only those steps. The base controls the order and structure; subclasses control the details.

A functional interface has exactly one abstract method, so it can be implemented with a lambda (e.g. Runnable). A marker interface has no methods at all; it just tags a class with a capability (e.g. Serializable).

Use an interface to define a capability that unrelated types can share, since a class can implement many interfaces. Use an abstract class when you need shared state, constructors, or partial implementation across closely related types.

A lambda has no type of its own. The compiler looks at the context where the lambda is used — the variable type, the method parameter, or the return type — to find the expected functional interface, then checks the lambda matches that interface's single method. The same lambda fits any interface whose method has a compatible shape.

A marker interface tags a type and gives you a real type the compiler can use (e.g. require it as a method parameter). An annotation can tag types, methods, or fields and can carry data, but doesn't create a type for compile-time checks. Use a marker for type-level guarantees; an annotation for richer metadata.

If two interfaces give the same default method, Java won't pick for you — the class must override that method, and inside it can call a chosen one with InterfaceName.super.method(). With classes there's only one superclass, so no such conflict arises.

Adding a default method lets existing implementers keep compiling, but the default might not be correct for every implementation, and it can clash with methods those classes already have. Use default/static/private methods to evolve and organize an interface, but don't put real state or business logic in them.

An interface is a flexible public contract: clients can implement it freely and you can add new methods later via default methods without breaking them. An abstract class lets you share code but locks implementers into your single-inheritance hierarchy. For public APIs, prefer an interface and optionally ship an abstract 'skeleton' class for reuse.

Use an abstract class when subclasses share real state and implementation under a single 'is-a' hierarchy. Prefer an interface when you only need a contract or multiple inheritance of type. Exposing an abstract class in a public API locks you into its structure, so favor composition where you can.

Serializable looks like a harmless empty tag, but implementing it secretly makes your object's private fields part of a public, long-lived format. That makes the class hard to change later, opens security holes when reading untrusted bytes, and weakens encapsulation. So you should add it deliberately, not by habit.