Dlaczego przy tworzeniu nowego obiektu, z reguły deklarujemy referencję z typu nadklasy?

Question

Witam! 

Być może w temacie niezbyt jasno się wyraziłem dlatego może jakiś przykład:

1. Chcemy stworzyć obiekt typu LinkedList. W literaturze, najczęściej spotykany zapis tego procesu to:

List<String> list = new LinkedList<String>();

2. Chcemy stworzyć obiekt typu HashSet. W literaturze spotkamy to:

Set<Integer, String> list = new HashSet<Integer, String>();

Teraz jest już chyba jasne o co chodzi. Dlaczego referencja jest deklarowana z nadklasy obiektu który tworzymy? Czy odnosimy z tego tytułu jakąś korzyść? Bo moim zdaniem przysparza to raczej problemów. Jak wiadomo kompilator nie patrzy na obiekt tylko na referencje. W związku z tym gdy w nadklasie nie będzie metody którą wywołujemy dostaniemy ComplieError. Skoro tak to logika podpowiada żeby deklarować jak "najniższe" referencje (najbliższe albo po prostu te same względem obiektu który tworzymy).

Dlaczego więc tego nie robimy i dlaczego warto deklarować typ postawiony wyżej w hierarchii dziedziczenia?

Dziękuję :)

Comments

List czy Set nie jest nadklasa tylko interfejsem

---

jej....no fajnie, przeciez kazdy wie o co chodzi... Bardziej byłbym wdzięczny za pomoc polegającą na odpowiedzeniu na pytanie a nie czepianiu się słówka, który w kontekscie w jakim go użyłem i tak jest zrozumialy dla kazdego...

---

Dlatego uzylem komentarza, a nie pelnej odpowiedzi, by nie zwracac az tak na to uwagi, po to zostaly stworzone komentarze. Po za tym daje Ci to juz pewien punkt zaczepienia by porownac sobie stosowanie interfejsow i dziedziczenia w celu znalezienia odpowiedzi na postawione pytanie.

Jednym z plusow jest uniwersalnosc kodu, mozna bezproblemu uzywac ArrayList, czy innego cuda, np. gdybys oddal klase komus, dalbys tej osobie mozliwosc wyboru, ktorej implementacji ma uzyc bo np. jedna implementacja jest mniej wydajna, a inna wygodniejsza w obsludze, a jeszcze inna zapewnia sortowanie elementow po dodaniu.

Moze tez to posluzyc sprawdzeniu czy dana implementacja klasy rzeczywiscie implementuje taki interfejs.

Byc moze chodzi tez o czytelnosc kodu - aha ta zmienna jest lista ok, a wiec mozna z nia zrobic to, to i tamto - niekoniecznie trzeba znac wszystkie implementacje, trzeba przede wszystkim znac ogolna zasade.

Answer 1

Daje nam to możliwość przypisania do zmiennej dowolnej podklasy. Można sobie wyobrazić na przykład:

List<Object> nieWiemKtoraImplementacjaLepsza;

if(lepszaJestTablica) {
    nieWiemKtoraImplementacjaLepsza = new ArrayList<Object>();
} else {
    nieWiemKtoraImplementacjaLepsza = new LinkedList<Object>();
}

 

Comments

uuuu faktycznie  To jest świetna zaleta niewątpliwie  Są jeszcze jakieś inne, równie lub mniej ciekawe?

A co w takim razie z problemem kompilatora który opisałem? Czy w praktyce jest to na tyle mało istotny problem, że warto się na niego godzić?

Answer 2

Powiedzmy ze robisz Polaczenie z jakas baza danych robisz interfejs DataSource w nim metody get bla bla.. i implementacje DataSourceFlat DataSourceSQL 

DataSource src;

if(config.typedatabase.equals(sql))
{
DataSource src = new DataSourceSQL
}

 

Comments

no dobra...niby wszystko spoko. Ale tak naprawdę....taki przykład nie tłumaczy dlaczego warto dawać referencje z klasy wyższej (lub interfejsu!!  )  tworząc obiekt typu podklasowego. Np ten przykład powyżej da się przecież zastąpić czymś takim:

 
if(config.typedatabase.equals(sql))
{
DataSourceSQL src = new DataSourceSQL
}
else {
DataaSourceDefault src = new DataSourceDefault
}

i tak dalej... nie ma przecież potrzeby deklarować DataSource src; przed ifem.

To samo tyczy się wcześniejszego przykładu. Jak na moje rozumowanie nie ma nic złego aby zastąpić kod @ribeiro:

List<Object> nieWiemKtoraImplementacjaLepsza;
 
if(lepszaJestTablica) {
    nieWiemKtoraImplementacjaLepsza = new ArrayList<Object>();
} else {
    nieWiemKtoraImplementacjaLepsza = new LinkedList<Object>();
}

takim kodem:

if(lepszaJestTablica) {
    ArrayList<Object> nieWiemKtoraImplementacjaLepsza = new ArrayList<Object>();
} else {
   LinkedList<Object>  nieWiemKtoraImplementacjaLepsza = new LinkedList<Object>();
}

Przecież tylko zadelarowanie że jakaś struktura danych będzie istnieć zupełnie nic nam nie daje. Nie możemy z nią nic zrobić dopóki jej nie zainicjujemy.

A może coś daje ale o tym nie wiem??

---

Nie panie, tak tego nie zastąpisz, bo przy użyciu tego poza ifem dostaniesz błąd kompilatora:

Cannot resolve symbol 'blablabla'.

---

ahhh no jasne, teraz czaje!!!!! Dziękuję ci bardzo 

Answer 3

W Javie programujemy obiektowo, a założeniami takiego programowania są:

• Hermetyzacja,
• Dziedziczenie,
• Abstrakcja
• Polimorfizm.

To o czym piszesz, to użycie polimorfizmu.

Można o tym poczytać na wielu stronach np. tu.

Comments

wiem czym jest polimorfizm i że to o czym pisze to przykład polimorfizmu. Jednak moje pytanie nie miało na celu dowiedziec się z jakiego założenia korzystam deklarujac w ten sposób daną strukturę danych, tylko dowiedziec się po co robi się to w tym konkretnym przypadku. Po co stosuje sie polimorfizm tez wiem ale nie widzę aby w tym przypadku on coś znacząco ułatwiał

---

W małych aplikacjach to nie ma większego znaczenia. Bardziej ma to znaczenie przy pracy w ogromnych aplikacjach.

Czysty kod zaleca używanie polimorfizmu i takiego deklarowania zmiennych. Odnoszenie się do metod poprzez interfejs, a implementację wybierać podczas działania programu w sposób dynamiczny.

Możesz pisać jak Ci się podoba.

---

Interfejsy mają za zadanie deklarowanie czystego, abstrakcyjnego zachowania klas, które będą go implementowały.

Gdy wywołujesz:

list.add(entity);

nie obchodzi Cię implementacja (w jaki sposób to zostanie zrobione), tylko efekt końcowy (do listy zostanie dodany nowy obiekt).

W związku z tym, deklarujemy zmienne poprzez podawanie typu interfejsu. Implementacja jest w tym przypadku mniej ważna.