Wszystko mi się kiełbasi.

Kiedy używać interfejsu a kiedy abstrakcji?

Niby mówią, że różnica na korzyść interfejsów jest taka, że można dziedziczyć (implementować) wiele interfejsów do interfejsu. Za to minusem jest, że nie można deklarować ciała metod. A przecież można z przedrostkiem default.

// interfejs
public interface Czlowiek {
	public default void getImie() {
		System.out.println("3twtwat");
	};
	public void f2();

}


// to samo abstrakcją
public abstract class Czlowiek {
	public void getImie(){
		System.out.println("3twtwat");
	}
	public abstract void f2();
}

Wobec tego nie widzę sensu używania abstrakcji poza sytuacją, gdy chcemy by abstrakcja też dziedziczyła (bo interfejs chyba nie moze dziedziczyć po klasie?).

Mnie tam bawią posty Żuliana xD tag kiełbasa pozamiatał :V ale swoją droga, z chęcią usłyszę odpowiedź, bo też zacząłem naukę Javy i w sumie nie do końca rozumiem po co interfejsy.

główną różnicą jest więc to że w klasie możesz użyć "super.getName()" i wywołać wspólną logikę z klasy nadrzędnej, default w interfejsie to tylko "szablon" tworzenia klasy, nie da się z tego co wiem wywołać domyślnej implementacji jeśli ją nadpiszemy

Otóż sens stosowania międzymordzia jest taki że jedna klasa może implementować wiele interfejsów a dziedziczyć tylko po 1 klasie. I na razie interfejsy mogą mieć tylko publiczne i statyczne zmienne :)
Nie mówiąc już o @FunctionalInterface i programowaniu funkcyjnym :P

Metoda default w interfejsie jest przydatna w takiej sytuacji:
Mamy Interfejs MyInterface ze zbiorem metod kopiuj(), dodaj(), usuń().
Mamy N implementacji tego interfejsu.
Nagle okazuje się ,że interfejs powinien dostarczać metodę scal().
Teraz tak, dodajemy metodę do interfejsu i musimy ją implementować w tych N klasach (np. w 25), albo robimy ją jako default, a nadpisujemy tylko w tych klasach gdzie faktycznie jest potrzebna specyficzna implementacja.

Za to minusem jest, że nie można deklarować ciała metod.

To nie jest „minus”, to jest (a raczej: było) założenie.

A przecież można z przedrostkiem default.

Bo kiedyś nie można było, a potem wymyślono żeby było można.

A klasy abstrakcyjne są po to żeby np. mieć jakiś wspólną część danych. Interfejsy bardziej określają abstrakcyjne metody,a klasy abstrakcyjne bardziej wspólne cechy, jest ściślejsze powiązanie między obiektami dziedziczącymi po klasie abstrakcyjnej niż pomiędzy implementującymi interface

EDIT:
typowym przykładem może być np. interface UserDAO - nie ważne skąd implementacja pobiera dane i jak to robi, po prostu pobiera.
A to klasy abstrakcyjnej dobrym przykładem może być AbstractEmployee po którym np. dziedziczy pracownik na UOP i na B2B :D

aha, @scibi92 czyli na swoje potrzeby początkującego mogę ogólnie przyjąć, że jak chcę mieć podobne metody dla wielu klas to pykam raczej interfejs. A jak chcę wspólne cechy klas (prywatne, niestatyczne i niefinalne, bo publiczne i statyczne i finalne mogę w interfejsie) to pykam klasę abstrakcji?

Prywatne będa tylko w klasie bazowej widoczne :)
Ale tak jeśli np. masz jakiś stan bazowy czyli część pól pokrywa się w kilku klasach to wtedy lepsza jest klasa abstrakcyjna :)

Dobrym przykładem wykorzystania klasy abstrakcyjnej jest wzorzec Metoda Szablonowa. Tworzysz klasę, która opisuje pewien algorytm, ale chcesz zezwolić na zdefiniowanie cześci algorytmu podklasom. W tym celu deklarujesz funkcje abstrakcyjnych, ktore wywołujesz w danej metodzie klasy bazowej, a które klasa pochodna musi napisać.

Klasa abstrakcyjna potrzebna jest jeśli masz pewną grupę operacji wspólną dla wszystkich podklas, jednocześnie nie chcesz pozwolić, aby ktoś tworzył instancje tej klasy, a wymuszasz jej dziedziczenie.

OK, to może mały przykład jeszcze.
Załóżmy, że mamy abstrakcyjną klasę Vechicle, która ma pewne typowe dla pojazdów własności enginePower, maxSpeed itp. Rozszerza ją klasa FlyingVechicle w klasycznym modelu dziedziczenia powiemy FlyingVechicle is a Vechicle czyli jest typu Vechicle Teraz anlogicznie mamy rodzinę klas z bazową klasą Animal, która ma zupełnie inne właściwości niż obiekty klasy Vechicle i próbowanie łączenia pojazdów i zwierząt w hierachie klas w sposób oczywisty jest niemożliwe, tudzież prowadzi to katastrofy.

Z klasy Animal dziedziczy dlaej FlyingAnimal, znowu powiemy FlyingAnimal is an Animal.
Obiekty typu FlyingAnimal i FlyingVechicle mają jednak jedną wspólną cechę - latają (poz tym nic je nie łączy). Teraz powiedzmy, że chcielibyśmy żeby te latające obiekty miały ze sobą coś wspólnego. Z pomocą przychodzą tu interfejsy. Zróbmy sobie interfejs Flyable, który zaimplementujemy w naszych latających klasach FlyingAnimal i FlyingVechicle.

public interface Flyable {

	default void fly(){
		System.out.println("fly baby");
	}
}

Interfejs to umowa, mówi do swojego klienta - "masz latać", a klient mówi "ok będę latał, umowa stoi."
W naszych klasach możemy przedefniować metodę fly, albo zostawić ją domyślną tj bez konieczności implementacji.
Ponieważ interfejs jest również typem nadrzędnym, dla klas, które go implementują zatem możemy to wykorzystać i na przykład zrobić sobie kolekcję typu Flyable.

FlyingAnimal flyinAnimal= new FlyingAnimal();
FlyingVechicle flyingVechicle = new FlyingVechicle();
		
List<Flyable> flyables = new ArrayList<>();
flyables.add(flyingVechicle);
flyables.add(flyinAnimal);
//latajcie
flyables.forEach(f -> f.fly());