Jaka jest różnica między interfejsem a klasą abstrakcyjną?

Question

Accepted Answer

Oba definiują typy abstrakcyjne, których nie można bezpośrednio instancjonować i które mają być implementowane/rozszerzane — ale służą różnym celom projektowym. Kluczowe różnice to **dziedziczenie wielokrotne**, **stan** i relacja, którą modelują.

## Interfejs — umowa ("can-do" / zdolność)

```java
public interface Drawable {
    void draw();                          // abstract method (implicitly public abstract)

default void render() {                // default method — has a body (Java 8+)
        System.out.println("rendering");
    }
    int MAX = 100;                         // implicitly public static final (constant only)
}

class Circle implements Drawable {
    public void draw() { /* must implement */ }
}
```

Interfejs definiuje **kontrakt** zachowania. Klasa może implementować **wiele** interfejsów — w ten sposób Java osiąga formę dziedziczenia wielokrotnego. Interfejsy (tradycyjnie) nie mają stanu instancji.

## Klasa abstrakcyjna — częściowa baza ("is-a" ze wspólnym kodem)

```java
public abstract class Animal {
    protected String name;                 // ✅ can have instance FIELDS (state)

public Animal(String name) {           // ✅ can have a constructor
        this.name = name;
    }
    public abstract void makeSound();      // abstract — subclasses must implement
    public void sleep() {                   // ✅ concrete method with shared logic
        System.out.println(name + " sleeps");
    }
}

class Dog extends Animal {                 // can extend only ONE class
    public Dog(String n) { super(n); }
    public void makeSound() { System.out.println("Woof"); }
}
```

Klasa abstrakcyjna może przechowywać **stan (pola)**, **konstruktory** i konkretne metody ze wspólną implementacją — ale klasa może rozszerzać tylko **jedną** klasę abstrakcyjną (dziedziczenie pojedyncze).

## Kluczowe różnice

```text
                    Interface              Abstract class
Multiple inheritance ✓ (implement many)    ✗ (extend only one)
Instance fields/state ✗ (constants only)   ✓ (fields)
Constructor           ✗                    ✓
Method bodies         default/static only  ✓ (concrete methods)
Models                capability ("can-do") "is-a" with shared base
```

## Dlaczego to ważne

```text
Interface → define a capability multiple unrelated classes can have
            (Comparable, Runnable, Serializable); when you need multiple inheritance
Abstract class → share common state + code among closely related subclasses
            (a base class with fields and partial implementation)
```

## Dlaczego to ważne

Wybór między interfejsem a klasą abstrakcyjną jest fundamentalną decyzją projektową w Javie.

Interfejsy definiują **umowy/zdolności** i umożliwiają klasie implementowanie wielu z nich (odpowiedź Javy na dziedziczenie wielokrotne) — idealne dla możliwości krzyżowych.

Klasy abstrakcyjne zapewniają **wspólną bazę ze stanem i częściową implementacją** dla ściśle powiązanych podklas, ale ograniczają cię do dziedziczenia pojedynczego.

Zrozumienie kompromisów (implementacja wielokrotna vs stan wspólny/konstruktory, zdolność vs relacja is-a) kieruje dobrym projektowaniem API i hierarchii klas.

Z metodami domyślnymi Java 8+ zaciemniającymi granicę, wiedza o tym, kiedy każdy pasuje — i główne ograniczenia (jedna klasa abstrakcyjna, ale wiele interfejsów, stan tylko w klasach abstrakcyjnych) — jest niezbędna do projektowania elastycznego, dobrze ustrukturyzowanego kodu.