Option(ale) jako pola zamiast nulli?

Odpowiedz Nowy wątek
2019-10-30 14:55
0

Załóżmy że mamy klasę (dataclass Kotlinowa) np. Issue które ma opcjonalne pole assignedTo typu UserId które może być puste - czy najlepszym sposobem nie jest po prostu stosowanie Option/Optionala jako typu tego opcjonalnego pola ?. W czystym Kotlinie nie mamy co prawda Optiona,ale są biblioteki


data class Issue(val assignedTo: Option<UserId> = Option.none()) {} 

Nie pomagam przez PM. Pytania zadaje się na forum.
edytowany 1x, ostatnio: scibi92, 2019-10-30 14:55

Pozostało 580 znaków

2019-10-30 15:04
5

Nie lepiej zrobić AssignedIssue i UnassignedIssue? Opcjonalne parametry zalatują troche antypatternem imo :)

edytowany 1x, ostatnio: baant, 2019-10-30 15:05
Pokaż pozostałe 2 komentarze
Szkoda ze tak malo ludzi rozroznia obiekty od encji albo struktur. - vpiotr 2019-10-30 15:13
ale on nie napisał tu nic o żadnej encji ani strukturze - baant 2019-10-30 15:14
DataClass to jest generalnie taka niby-struktura zwykle, ale to nie zmienia faktu że trudno mi sobie wyobrazić że masz 100 pól na "tym samym poziomie abstrakcji" których nie da się po ludzku zgrupować. - Shalom 2019-10-30 15:17
a data class to co? Taki DTOs :P - scibi92 2019-10-30 15:17
U mnie podstawowy produkt ma 104 pola na jednym poziomie abstrakcji. Może dałoby się to inaczej pogrupować, ale nikt raczej nie zmieni funkcjonującego od kilkudziesięciu lat standardu. - somekind 2019-10-30 15:45

Pozostało 580 znaków

2019-10-30 15:11
0

Też wydaje mi się że lepiej zrobić tutaj jakieś sealed Class z tymi 2 opcjami zamiast takiego opcjonalnego parametru, szczególnie że kotlin ma sensowny pattern matching do tego.


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...

Pozostało 580 znaków

2019-10-30 15:12
1

Dla pół nie powinno się używać Optional. Jest na ten temat trochę w sieci. Itp
https://dzone.com/articles/optional-anti-patterns

BTW, null jest zły? Załóżmy, że customer_mail = null zastąpimy optionalem, np
https://www.baeldung.com/java-optional-or-else-vs-or-else-get
Niech zwraca [email protected]
albo coś innego w stylu 'purge twoja-stara' - było coś podobnego na 4p w jokes

nulla przynajmniej wychwycisz, radośnie wstawionego dziwnego default z optional nie zlokalizujesz przez 5 lat.

IMHO optional np. dla reduce sum/concatenate dla pustej kolekcji jest ok, ale dla user_ID ja bym go nie stosował, tylko po ludzku przemyślał co, dlaczego i po co dzieje się kiedy user_ID jest nieokreślony (piszę nieokreślony żeby się zastanowić zamiast na szybko dać null). Np. domyślnie jakiś typ/wartość undefinedYet zamiast null, wartość undefinedYet będzie ustawiana na sensowną wartość dopiero kiedy będzie ona znana albo wcale kiedy nie będzie takiej informacji dostarczonej.


"Ktoś sobie uświadomił, że pisał pod pseudonimem rzeczy, które lepiej żeby w firmie nie wypatrzyli :-)"

"- Ledwo na studiach 3 tydzień się kończy i już ciężko?
- Niestety prowadzący jest dziwny i robi kartkówki"

Pozostało 580 znaków

2019-10-30 15:16
3

nulla przynajmniej wychwycisz, radośnie wstawionego dziwnego default z optional nie zlokalizujesz przez 5 lat.

Nie nie nie. Nie wychwycisz default value! To nie optional w twoim przykładzie jest błędem, tylko użycie domyślnej wartości. W praktyce to nulle są właśnie niewidzialne bo typesystem ich nie wychwyci. Optional widać gołym okiem i wiesz że to pole może mieć wartość albo nie i musisz explicite coś z tym zrobić.


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...

Pozostało 580 znaków

2019-10-30 15:21
1

To że jakiś baeldung czy dzone coś pisze to nie znaczy że trzeba tak robić. Anyway, +1 dla sealed class, tak by było najbardziej 'funkcyjnie'

Pozostało 580 znaków

2019-10-30 15:23
0

Optional może siedzieć ukryty w implementacji z której tylko korzystasz, może nie być wzmianki o tym, że jest użyty.
Na przykładzie 'opcjonalnego' maila już wolałbym nula niż ukrytego w implementacji opcjonalnego maila do programisty albo admina. I javadoc z info, że może dać null.
Póki klient nie zgłosi bugów to optional przykryje ewentualny problem.


"Ktoś sobie uświadomił, że pisał pod pseudonimem rzeczy, które lepiej żeby w firmie nie wypatrzyli :-)"

"- Ledwo na studiach 3 tydzień się kończy i już ciężko?
- Niestety prowadzący jest dziwny i robi kartkówki"

Pozostało 580 znaków

2019-10-30 15:27
1

@scibi92, a co jest nie tak z @Nullable?
Option(al) jest niezalecany jako pole AFAIK.


Szacuje się, że w Polsce brakuje 50 tys. programistów
edytowany 2x, ostatnio: vpiotr, 2019-10-30 15:34

Pozostało 580 znaków

2019-10-30 16:09
2

@Shalom: faktycznie, dawno nie korzystałem z Kotlina i zapomniałem że przeciez są sealed classy...
@vpiotr - chodziło o Kotlina nie Jave. A po za tym ten Optional nie jest zalecany w Javie bo nie jest serializowany, za to taki Option w Vavrze jest ;)

EDIT:
no ale w sumie co jesli mamy klasę NonAssignedIssue i chcemy zrobić kopię która będzie AssignedIssue albo odwrotnie i użyemy sealed class?


Nie pomagam przez PM. Pytania zadaje się na forum.
edytowany 1x, ostatnio: scibi92, 2019-10-30 16:32
To tworzysz nowy obiekt? ;] - Shalom 2019-10-30 16:37
No w sumie :D Za bardzo coś wymyslnego niepotrzebnie chciałem wymyślec... - scibi92 2019-10-30 16:50

Pozostało 580 znaków

2019-10-30 16:56
0

co jesli mamy klase NonAssignedIssue i chcemy zrobic kopie ktora bedzie AssignedIssue

NajDDDowniej bedzie pewnie miec metode assign(..) w UnassignedIssue, która zwróci AssignedIssue :)

Nie trzeba tu żadnego DDD, przecież to podstawy OOP. :D - tdudzik 2019-10-30 17:04
Racja, niby podstawy ale malo kto je stosuje. Przynajmniej z tego co widzialem do tej pory w mojej krotkiej karierze :) - baant 2019-10-30 17:08
To nie jest żadne DDD, sam przecież chwale takie podejście tylko za bardzo rozmyslałem się o ficzerach Kotlina że pomyslałem że jest jakiś skrót na to (tak jak metoda copy z data class). - scibi92 2019-10-30 17:15
A chciałbym zastosowac hexagonal architecture (czyli porty i adaptery) - scibi92 2019-10-30 17:16
DDD promuje takie podejscie, wiec nawiazalem do ddd xd - baant 2019-10-30 17:19
ddd srididi :P - scibi92 2019-10-30 17:29

Pozostało 580 znaków

2019-10-30 20:52
4

ten UnassignedIssue i AssignedIssue to dobre rozwiązanie.
Pola Option tez nie są złe.
Ten artykuł o antypatternie Optional z dzone to w połowie bdzura, a w połowie dotyczy bieda Optionala z javy - Option to co innego (bo jest Serializowalny na przykład).

Mnie w kontekście kotlina zawsze zastanawia korzystanie z nullable (?) i generalnie ciągle nie korzystam... (tylko przy odpakowywaniu czegoś z javy na chwilkę).


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 1x, ostatnio: jarekr000000, 2019-10-30 20:54

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