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
Java LinkedList to nie ma zmiłuj i już tego potem nie zmienisz.var zmienna =... nie podając typu.Pierwszy punkt dla mnie został nie zrozumiały, jeżeli objaśnisz, to jesteś Bogiem
Zakładaj ten sam temat co 8h, masz szansę, że zobaczy go całe community Javowe ;)
https://stackoverflow.com/questions/147468/why-should-the-interface-for-a-java-class-be-preferred
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).
No to szersze objaśnienie:
List żeby sobie wpoić żeby wszędzie tak robić i ja też to zalecam. Ale z praktycznego punktu widzenia niewiele to zmieni.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ć.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
Władyslaw Parchomenko