Java - po co używać klasy abstrakcyjnych, skoro są interfejsy?

Question

Cześć, uczę się Javy i mam pytanie co do pisania kodu - w najnowszej Javie z tego co zdążyłem się dowiedzieć klasy abstrakcyjne i interfejsy nie różnią się niczym (różnica zatarła się po wprowadzeniu metod domyślnych), za to interfejsy mają ogromną zaletę w postaci braku ograniczenia co do dziedziczenia jednokrotnego i tutaj się pojawia moje pytanie:

Czy jest jakakolwiek sytuacja, gdzie używacie klas abstrakcyjnych zamiast interfejsów?

Answer 1

W interfejsie nie zrobisz zmiennych skladowych ani konstruktorów a wszystkie metody sa publiczne.

Dodatkowl mimo wszystko maja sporo roznic niepisanych. Interfejs to kontrakt - zbior metod publicznych ktore klasa ma implementować, a klasa abstrakcyjna to niekompletna klasa.

Comments

abstrakcyjna to niekompletna klasa.

Ciekawie to ująłeś. Jakoś nigdy do głowy mi nie przyszło, żeby tak o tym pomyśleć. 

---

a wszystkie metody sa publiczne.

Od Java 9 można robić w interfejsach metody prywatne.

---

no tak ale to nie zmienia faktu że pacage-private jest jeszcze , bo w Javie nie określenie zasięgu zmiennej jest takim własnie typem zmiennej. A to nie do końca protected jest, ani private. Takie pomiędzy

Answer 2

Interfejsy mają pokazywać bardziej zachowanie danego obiektu, natomiast klasa abstrakcyjna daje dodatkową semantykę dla obiektu. Np. Node w JavaFx nie bardzo pasuje pod interfejs bo przechowuje jakiś stan i tworzenie bezpośrednio instancji tego obiektu też było by bez sensu. Zadaniem klasy jest własnie też podtrzymanie jakiegoś stanu, interfejs raczej nie bardzo się do tego nadaje, bo nie można w nim tworzyć pól.

Abstrakcyjna klasa może przydać się np. we wzorcu Metoda szablonowa.

Z bardziej technicznych rzeczy to, w interfejsie nie zablokujesz sobie nadpisania metody:

interface Inter
{
    public default void method()
    {
        System.out.println("default");
    };
}

abstract class AbstClass
{
    public final void method() //mozna uzyc final
    {
        System.out.println("default");
    }
}

class A extends AbstClass
{
    @Override
    public void method(){} //bład, ta metoda jest finalna i nie można jej nadpisać
}

class B implements Inter
{
    @Override
    public void method() //działa
    {

    }
}

Answer 3

Chociażby protected modyfikator. Inne semantyczne użycie jednego a drugiego. Interfejsy nie mają pól instancyjnych.

Comments

Przykład:

Masz Kwadrat, Prostokąt i Figura. Prostokąt i Kwadrat dziedziczą/implementują Figura.

No właśnie co byś wybrał? załóżmy że nam w programie potrzebne są metody obliczPole i obliczObwód oraz pola "pole" i "obwod". Takich pol nie dasz w interfejsie. Przy 20 klasach dziedziczących masz 38 powtórzonych pól (2x40-2)

Interfejsu użyłbym jedynie gdyby mój kwadrat np miał dziedziczyć jeszcze po czymś.

 

Co jeszcze. Interfejs to kontrakt tak jak napisał RafałS. A klasę abstrakcyjną często zobaczysz jak nadklase w JPA albo w DTO dla pól wspólnych. Użyjesz jej jako części wspólnej i tu użyłbym słowa "smietnik" na różne metody utility. Natomiast klasy abstrakcyjnej nie użyj wystawiając api na zewnątrz.

---

obliczPole i obliczObwód oraz pola "pole" i "obwod". Takich pol nie dasz w interfejsi

to fajnie bo w Javie masz coś takiego jak Interfejs Shape... :) 

Bzdura - własnie tutaj przydaje się interfejs, bo sa to pewne "niezmienne"  zachowania dla tych obiektów właśnie :), a różnią się tylko implementacją. 

---

I co masz w tym interfejsie Shape pola: "pole" i "obwod" ? <sarkazm>

Gdzie, co bzdura? Można dać interfejs z metodami a pod nią dać klasę abstrakcyjną z polami "pole" i "obwod".

---

w interfejsie pole i obwód być mogą też :) w obecnej specyfikacji, ja wiem że może to pewną konwencje łamać:  ale funkcjonalności możesz zachowac

---

Że niby jak? Nie możesz mieć pól w interfejsie, nawet prywatnych z tego co wiem. Jedynie stałe i pola lokalne.