abstract class vs interface

Jól látod. Szinte mindenkinek ez jut az eszébe és a gyakorlat közben letisztul.

Talán életszerű lesz:
Képzelj el két absztrakció szinten teljesen különálló fogalmat. Legyen az egyik élőlény a másik egy jármű. Nevetséges lenne közös ős, de nem nevetséges közös interface.
Pl
GetCountry()
GetAge()

"A probléma az, hogy az implements List az nem deklarálja hogy lesz állapota az osztálynak."

Disclaimer: tekintsünk el az emptyList()-től, mert a metódusok nagy része használhatatlan.

https://docs.oracle.com/javase/8/docs/api/java/util/List.html

* "The user of this interface has precise control over where in the list each element is inserted."
* "The List interface provides two methods to efficiently insert and remove multiple elements at an arbitrary point in the list."
* "Sorts this list according to the order induced by the specified Comparator."
* ...

Ha te ezeket tudod állapot nélkül, értelmesen implementálni, akkor kérek rá egy példát.

Tudom, hogy szintaktikailag az inteface csak metódusok létét írja elő. De van ám javadoc is, és van szemantika is.

Egy így felkommentezett interface igencsak előírja, hogy a tipikus implementációnak lesz állapota.

És habár az add, remove stb. a komment szerint opcionális, ez arról szól, hogy léteznek read-only listák (pl. com.google.common.collect.ImmutableList), de egy read-only listának is tipikusan van állapota, ami csak annyiban különleges, hogy csak létrehozáskor lehet módosítani.

Disclaimer: ez egy elméleti gondolatkísérlet, hogy egy interface-szel és egy abstract class-szal mit *lehet* megtenni (mert ugye én azt állítottam hogy kb. ugyanaz a kifejező erejük ami nem tetszik egyeseknek). Az pedig, hogy melyik mire való, nem mindig egyértelmű és kissé még szubjektív is. Még akkor is, ha 99%-ban az összes programozó egyetért (még mi ketten is egyetértenénk), akkor is van olyan, amikor nem egyértelmű. Lenne rá példa, hogy nem értenénk egyet, és arra is lenne példa, hogy mindkettő jó (lásd List és AbstractList).

"Az emptyList() az szerinted nem állapot?"

Mi az állapot? Alapvetően a Wikipédián leírt mondattal értek egyet: "Similarly, a computer program stores data in variables, which represent storage locations in the computer's memory. The contents of these memory locations, at any given point in the program's execution, is called the program's state." Ezt lehet kiegészíteni avval, hogy egy osztálynak akkor is van kvázi állapota, ha statikus metódusokon keresztül egy adatbázissal vagy egy bármilyen CRUD API-val beszélget. Ezek alapján az emptyList()-nek nincs állapota, be van drótozva, hogy üresnek tetteti magát, sem konstruktor paraméterrel, sem setFoo() metódusokkal, sem semmivel nem tudod módosítani.

"Két lista implementáció (mondjuk egy egyszeresen láncolt és egy kétszeresen láncolt az szerinted egyforma? Akkor is ha üres? Nem egyforma."

Nem tudom ez miért jön ide, és mi az "egyforma" definíciója. A List.equals() igazat fog adni bármilyen két listára, ha ugyanazok az elemek vannak bennük, akkor is, ha nem ugyanaz az implementáció. De én szerintem semmi olyat nem írtam, ami ezen múlik.

Vegyük ezt a kódot:

interface Value1 {
  void set(int x);
  int get();
}

abstract class Value2 {
  public abstract void set(int x);
  public abstract int get();
}

A dokumentációt képzeld oda. Akármelyiket implementálod, valószínűleg lesz egy private int x benne (vagy bármi, ami állaptot tárol a fenti definíció szerint), ugye? Azon kívül, hogy esetenként változik, hogy interface vagy abstract class a célravezetőbb, ez a két dolog kb. egyforma. Erre gondoltam, hogy az interface-nek direktben tényleg nincs állapota, de az interface kb. kikötheti, hogy az őt implementáló osztálynak már legyen.

Továbbgondolva:

abstract class Value2 {
  protected int x;
  public void set(int x) { this.x = x; }
  public int get() { return x; }
}

Franko erre gondolhatott, hogy egy abstract osztálynak lehet állapota, mert ennek tényleg van. Ha több metódusod van, amik közül némelyik boilerplate, akkor lehet értelme, hogy a boilerplate közös helyen van implementálva (a példában x/set/get). Illetve az abstract osztály lekorlátozza, hogy az x mező mellett már nem kell más állapot, pl. nem fogod adatbázisban tárolni a cuccot (jó, lehet ott is, cache-eléssel, stb.).

És most jön az, amiről előre látom, hogy bele fogtok kötni, de képzeljük el az alábbi képzeletbeli szintaxist a fentebbi helyett:

interface Value1 {
  int x;
}

abstract class Value2 {
  public int x;
}

Ha az előző példákban láttad a párhuzamot Value1 és Value2 között, akkor itt is látod. Igen igen, publikus mezőt kiajánlani nem szép dolog. Igen igen, az előbbit a javac és a JVM egyáltalán nem is támogatja. Ez csak egy gondolatkísérlet. Lehetne írni olyan javac-t és JVM-et, ami ezt támogatja? Lehetne. Az, hogy most ez nem működik, az szintaxis kérdése (azon felül, hogy csúnya, és ez miatt valószínűleg soha nem is lesz támogatva).

Hogy legyen min csámcsogni, bedobom ezt is: a javac simán megengedhetné, hogy ha egy interface-ben az összes metódusnak van default-ja, akkor a new Interface() jelentse ugyanazt, mint a new Interface() {}, és hoppá, sikerült példányosítani az interface-t. *Elsősorban* azért nem lehet példányosítani abstract dolgokat, mert hiányzik belőlük néhány implementáció. Az kb. önkényesség/szépség/értelmesség kérdése, hogy még egy hiányzó metódusok nélküli interface-t sem lehet példányosítani.