Polimorfizm albo nie polimorfizm, w tym rzecz. Collection.

Odpowiedz Nowy wątek
2019-07-15 00:15
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

Pozostało 580 znaków

2019-07-15 00:27
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.

Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
Szczerze, żadnego twego komenta nie zrozumiałem za te wszystkie 10-15 postów, kiedy coś pytałem, w porównaniu do innych - Władyslaw Parchomenko 2019-07-15 11:31
w takim razie nie wiem jakim językiem należałoby Ci to wytłumaczyć żebyś zrozumiał. Shalom wyczerpał temat - w dodatku wydaje się, że w przystępny dla każdego sposób. - m4ck 2019-07-15 11:46

Pozostało 580 znaków

2019-07-15 11:49
0

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

Pozostało 580 znaków

2019-07-15 12:00
0

Zakładaj ten sam temat co 8h, masz szansę, że zobaczy go całe community Javowe ;)

https://stackoverflow.com/que[...]for-a-java-class-be-preferred

https://stackoverflow.com/que[...]d-of-arraylist-list-n/9861123

edytowany 1x, ostatnio: kixe52, 2019-07-15 12:00

Pozostało 580 znaków

2019-07-15 12:26
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).

Pozostało 580 znaków

2019-07-15 13:11

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żywaszSortedSet<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


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
Raczej Set<e> a nie Set<t> :P - scibi92 2019-07-15 15:56
<T> jest bardziej uniwersalne. - Shalom 2019-07-15 15:59
No niby tak ale zgodnie z konwencja to E powinno być w kolekcjach ;p - scibi92 2019-07-15 16:50
Proszę o stosowny cytat ze specyfikacji. - Shalom 2019-07-15 16:52
Wielkie ci dzięki, już understand - Władyslaw Parchomenko 2019-07-15 23:56

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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