Polimorfizm albo nie polimorfizm, w tym rzecz. Collection.

0

Dobry wieczór wszystkim.
**1. **Mam takie pytanie, w jakiej postaci lepiej pisać kod i czemu? :

LinkedList<Integer> linked = new LinkedList<integer>();

albo

List<Integer> linked = new LinkedList<integer>();

2. Słyszałęm na youtubie, że obecnie nie trzeba pisać z obu stron <Integer>, tylko na początku. Czy to prawda? Czemu
Dzięki

1
  1. Generalnie zakłada się, że używasz interfejsów a nie klas i raczej tak mało specyficznych jak to tylko możliwe, żeby nie wprowadzać nieoczekiwanych ograniczeń w API. Więc twoja opcja 2. Niemniej w samym kodzie metody nie jest to aż tak kluczowe, bo zmiana zwykle byłaby kosmetyczna. Jest to dużo ważniejsze kiedy określasz typy argumentów i typy zwracane przez metody. Bo jak dasz sobie tam LinkedList to nie ma zmiłuj i już tego potem nie zmienisz.
  2. Cukier składniowy, po prostu inferencja typów potrafi rozpoznać jaki typ generyczny jest tam potrzebny. Równie dobrze mógłbyś pytać czemu można w ogóle napisać var zmienna =... nie podając typu.
0

Pierwszy punkt dla mnie został nie zrozumiały, jeżeli objaśnisz, to jesteś Bogiem

1
Władyslaw Parchomenko napisał(a):

Pierwszy punkt dla mnie został nie zrozumiały, jeżeli objaśnisz, to jesteś Bogiem

Chodzi o to, że dobra praktyka zakłada używanie jak najogólniejszego typu. Interfejs List zapewnia Ci metody dodawania, usuwania elementów itd. Jeżeli zmienna jest typu list, to nie ma znaczenia, czy przypiszesz do niej LinkedList, czy ArrayList. We wszystkich miejscach aplikacji, w których odwołasz się do zmiennej typu List będziesz korzystał z ogólnego interfejsu, więc jeżeli nagle uznasz, że LinkedList będzie wydajniejsza od ArrayList, to program Ci się nie wysypie. Inna sprawa, jeżeli będziesz miał konieczność korzystania z metod specyficznych dla danego typu listy - mówię to o bodajże removeFirst, removeLast dla LinkedList. Wtedy typ List musiałbyś rzutować (zła praktyka).

3

No to szersze objaśnienie:

  1. W przypadku kodu wewnątrz metody nie ma to specjalnie znaczenia bo zasięg takiej deklaracji jest bardzo krótki, może kilka linijek. Niektóre osoby powiedzą że lepiej użyć tutaj List żeby sobie wpoić żeby wszędzie tak robić i ja też to zalecam. Ale z praktycznego punktu widzenia niewiele to zmieni.
  2. Ma to bardzo dużo znaczenie kiedy projektujesz API, czyli określasz typy zwracane przez metody oraz argumenty metod. Bo tutaj użycie konkretnego typu tworzy pewien kontrakt którego nie możesz już złamać. Więc jeśli masz metodę np. public TreeSet<T> metoda() to będzie ona musiała zwracać ten tree set po wsze czasy. Bo np. ktoś z tej metody skorzystał i napisał kod w oparciu o to że dostanie posortowany set. Więc nie możesz sobie teraz zmienić tego na HashSet (a może chciałbyś, bo uznałeś że się lepiej nadaje?) bo projekt przestanie się budować. A nawet jak poprawisz żeby sie budował, to nie będzie działał, bo jest jeszcze ten kod kolegi który polega na kolejności elementów w tym secie. Analogicznie przy deklarowaniu typów argumentów, jakie zadeklarujesz takie będą i koniec. Dlatego dobrą praktyką jest używanie najbardziej ogólnych interfejsów jak to tylko możliwe. Więc np. jeśli potrzebujesz posortowany set to używasz SortedSet<T> ale jeśli kolejność elementów jest obojętna to dajesz Set<T>, żeby niepotrzebnie nikogo nie ograniczać.
  3. Ważne jest żeby generalnie używać interfejsów a nie klas, bo nie zamyka nam to drogi do innych implementacji. Może kiedyś napiszesz swój własny Set<T>, ale najpewniej nie będziesz dziedziczyć po żadnym istniejącym, tylko napiszesz go od zera i tylko zaimplementujesz interfejs. W takiej sytuacji nawet jeśli twoja metoda miała w API AbstractSet<T> to nie będziesz mógł jej użyć ze swoim kodem, bo wcale tej klasy nie extendujesz.

tl;dr: dawaj wszędzie najbardziej ogólny interfejs który ma sens

1 użytkowników online, w tym zalogowanych: 0, gości: 1