Tworzenie listy

Odpowiedz Nowy wątek
2019-02-02 14:58
0

Czy tworząc listę np w klasie MyClass

lepiej tworzyć taką listę od razu przy deklaracji pola w klasie MyClass,

private LinkedList<String> myList = new LinkedList<>();

czy tworzyć najpierw pole

private LinkedList<String> myList;

i dopiero w konstruktorze MyClass tworzyć nowy obiekt i przypisac do zmiennej

MyClass(){
myList = new LinkedList<>();
}

Moim daniem druga opcja lepsza, ale nie jestem w stanie wytłumaczyć dlaczego.
A więc która opcja lepsza i dlaczego ?

Pozostało 580 znaków

2019-02-02 15:36
1

Oba podejścia są złe. Z tym, że inicjalizacja pola od razu jest złem mniejszym.
Dlaczego,
bo przynajmniej nie masz sytuacji, że w polu pozostaje jakiś null, który może zostać przypadkiem zapomniany. Można zapomnieć jeśli napiszesz kolejny konstruktor.

Jak to zrobić lepiej:
dodać modyfikator final.

private final LinkedList<String> myList
Wtedy czy to w konstruktorze czy w polu inicjujemy - kompilator zadba abyśmy to zrobili.

Da się to jeszcze lepiej zrobić, ale to kolejny poziom.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 1x, ostatnio: jarekr000000, 2019-02-02 15:37
opisz ten kolejny poziom ;) - Spine 2019-02-02 15:42

Pozostało 580 znaków

2019-02-02 15:41
2

Ja wolę pierwszy sposób. Nie przepisujemy niepotrzebnie nazwy zmiennej.

W konstruktorze najlepiej tworzyć listę lub pobierać ją jako parametr, jeśli chcemy użytkownikom danej klasy pozwolić na taki wybór. Ja wszystkie pola, które nie są parametrem konstruktora inicjuję w ciele klasy, o ile jest to możliwe.

edytowany 1x, ostatnio: Spine, 2019-02-02 15:43

Pozostało 580 znaków

2019-02-02 16:38
0
jarekr000000 napisał(a):

Da się to jeszcze lepiej zrobić, ale to kolejny poziom.

Jak to zrobić jeszcze lepiej ?

Pozostało 580 znaków

2019-02-02 16:43
3

Poziomy zła takie są:

1) finalne pole (niezmienna) do niemutowalnego obiektu. W zasadzie ideał.
W praktyce oczywiście to powinno wyglądać mniej więcej tak:

final io.vavr.collection.List<String>  myList;

MyClass (params)  {
   myList = .... list initialization  from params.
}

Jedynie słuszne podejście w programowaniu funkcyjnym.

2) dużo gorzej:
referencja (zmienna ) do niemutowalnej klasy
io.vavr.collection.List<String> myList = ...initialization ... ;

Jak zmieniamy zawartość to jest to widoczne jako jawne (explicit) podstawienie :
myList = myList.prepend(x);

3) kolejny krok ku złu:
finalna referencja (niezmienna) do mutowalnej klasy
final java.util.List<String> myList = ... initialization ...;

Dlaczego to gorsze od 2?
zmianny nie są jawne (explicit) - czyli możesz wywoałać otherClass.sendMails(myList); a wredna metoda sendMail() w środku np. wywali z listy wszystkie wartości, które nie są poprawnymi emailami.

4) najgorzej - zło wcielone (chaotyczny zły)
nie dość, że zmienna to jeszcze do mutowalnej klasy .
Mamy dwa sposoby zmieniania wartości - chaos i masakra.
java.util.List<String> myList = ..initialization...

Nawet jak olewamy wartości funkcyjne to jest to niepotrzebny chaos.

Uwaga:

Jak się jest początkującym w javie to wystarczy IMO nie robić sobie 4).


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 8x, ostatnio: jarekr000000, 2019-02-02 16:47

Pozostało 580 znaków

2019-02-03 21:25
0

Możesz @jarekr000000 dokładniej powiedzieć co jest nie tak w sposobie:

private LinkedList<String> myList = new LinkedList<>();

według mnie jest to bardzo wygodne, ponieważ nie musimy się martwić o NPE. Takie wydaje mi się to najbardziej naturalne. Przecież później w konstruktorze niekoniecznie trzeba coś z taką listą robić.

Pokaż pozostałe 4 komentarze
To teraz czytaj to - jarekr000000 2019-02-04 09:27
@jarekr000000: to również czytałem. Kilkukrotnie. Czy możesz porzucić na chwilę myślenie o funkcyjności i popatrzeć na to pod kątem standardowego programowania w Javie? Chodzi o praktyczne podejście, które można wykorzystać w projektach już istniejących (a chociażby takich napisanych jeszcze w Javie 6, bo jest ich multum). Chyba, że rzeczywiście twój post omawia i ten scenariusz, ale kompletnie nie potrafię zrozumieć co chciałeś przekazać. No offence. - teez 2019-02-04 09:33
najprościej ujmując - jak nie ma tam final przy deklaracji - to jest mocno kijowo. nawet w javie 1.3 - jarekr000000 2019-02-04 09:38
a kiedy sie powinno dawac final? ja sie dopiero ucze i ciekawią mnie ta smaczki (troche tutków przejrzałem kiedys i nie kojarze zeby ktos omawiał kiedy dawac final a kiedy nie ) - m123 2019-02-04 09:52
Czemu mocno kijowo kiedy nie ma final przy deklaracji? Jakie to może mieć skutki? Jestem ciekaw jakie to może mieć konsekwencje? - teez 2019-02-04 10:04

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