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-31 11:05
0

"UnassignedIssue i AssignedIssue" - Assigned/Unassigned jak dla mnie stan Issue (z jakiegoś mniej lub bardziej wydumanego lifecycle encji), zaś fakt do kogo jest Issue przypisane, to informacja dodatkowa. Później ktoś może pójść za ciosem i nastąpi eksplozja ResolvedIssue/RejectedIssue/... ;)

edytowany 1x, ostatnio: yarel, 2019-10-31 11:05

Pozostało 580 znaków

2019-10-31 11:06
1
yarel napisał(a):

Później ktoś może pójść za ciosem i nastąpi eksplozja ResolvedIssue/RejectedIssue/... ;)

A to aż tak złe? ;)


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ
Haste - mała biblioteka do testów z czasem.

Pozostało 580 znaków

2019-10-31 11:12
1
yarel napisał(a):

"UnassignedIssue i AssignedIssue" - Assigned/Unassigned jak dla mnie stan Issue (z jakiegoś mniej lub bardziej wydumanego lifecycle encji), zaś fakt do kogo jest Issue przypisane, to informacja dodatkowa. Później ktoś może pójść za ciosem i nastąpi eksplozja ResolvedIssue/RejectedIssue/... ;)

To teraz pójdźmy w drugą skrajność, zostawmy ten userId czy tam email jako Option / Optional / @Nullable bo przecież mamy tylko stany assigned / unassigned, co może pójść źle? ;)

A pół roku później jest już 10 różnych możliwych stanów tego Issue (assigned / unassigned / suspended / blocked / pending / overdue / rejected / cokolwiek) i w zależności od tego który to jest stan 20 różnych property może być puste lub nie, używane lub nie etc. To dopiero będzie eksplozja


Nie znam się, ale się wypowiem
edytowany 1x, ostatnio: superdurszlak, 2019-10-31 11:13

Pozostało 580 znaków

2019-10-31 11:17
0
danek napisał(a):
yarel napisał(a):

Później ktoś może pójść za ciosem i nastąpi eksplozja ResolvedIssue/RejectedIssue/... ;)

A to aż tak złe? ;)

Kotlina nie znam, więc może tam to ma uzasadnienie. Staram się patrzeć z perspektywy modelu, bez wchodzenia w technologię. Co mi wniosą osobne encje? Co jeśli chciałbym dynamicznie definiować cykl życia dla Issue? (stany + przejścia między nimi, np. flow w JIRA).

Nie wiem, może w przypadku konkretnego problemu ma to uzasadnienie i jest bardzo dobrym rozwiązaniem :-)

Pozostało 580 znaków

2019-10-31 11:18
1

Tak teraz myślę, że daje to jeszcze jedno fajne zabezpieczenie. Porównaj te dwie sygnatury:

fun close(task:Task)
fun close(task:OpenTask)

Aczkolwiek bez jakiegoś konkretnego przypadku to niewiele wymyślimy ;)


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ
Haste - mała biblioteka do testów z czasem.
edytowany 1x, ostatnio: danek, 2019-10-31 11:19
W programach na 100 linii to w sumie fajny pomysl. - vpiotr 2019-10-31 11:23
własnie mam wrażenie, że im większy program, tym bardziej system typów pomaga, zamiast przeszkadzać - danek 2019-10-31 11:24
albo i openTask.close(), który zwraca ClosedTask z metodą open :D - baant 2019-10-31 11:30
okej, nazwa close faktycznie niefortunna, ale chodzi o zasadę :p - danek 2019-10-31 11:30
wtedy kompilator testuje ci aplikacje, bo nie nabruzdzisz se za wiele jak masz taki system typow - baant 2019-10-31 11:31
dokładnie o to chodzi - danek 2019-10-31 11:33

Pozostało 580 znaków

2019-10-31 11:40
0
yarel napisał(a):

"UnassignedIssue i AssignedIssue" - Assigned/Unassigned jak dla mnie stan Issue (z jakiegoś mniej lub bardziej wydumanego lifecycle encji), zaś fakt do kogo jest Issue przypisane, to informacja dodatkowa. Później ktoś może pójść za ciosem i nastąpi eksplozja ResolvedIssue/RejectedIssue/... ;)

To robisz enum IssueStatus i to jest pole :)

@danek @jarekr000000 o takich rzeczach (z typami danych) mówił na swej prezentacji na JDD :P


Nie pomagam przez PM. Pytania zadaje się na forum.
edytowany 2x, ostatnio: scibi92, 2019-10-31 12:07
Stąd też moje zdziwienie, żeby robić osobne klasy do czegoś, do czego wystarczy enum (nie znam kotlina, więc może taki enum~data class). Mając IssueState + zdarzenia biznesowe (przypisano issue, zamknięto issue, ...), to aż się prosi o FSMa.. Taki FSM z historią zdarzeń pewnie ucieszyłby jednocześnie zwolenników FP i Event Sourcingu i może nawet idempotentów ;-) - yarel 2019-10-31 12:01
Finite State Machine :-) W kontekści Kotlina google wypluło: https://github.com/Tinder/StateMachine , w Javie -> statefulj, easyfsm , Scala/Java -> akka fsm - yarel 2019-10-31 12:14
A tak mniej więcej zaimplementował jako maszynę stanów, nie wiedziedzialem że tak to się nazywa - scibi92 2019-10-31 12:26

Pozostało 580 znaków

2019-10-31 11:40
0
danek napisał(a):

Tak teraz myślę, że daje to jeszcze jedno fajne zabezpieczenie. Porównaj te dwie sygnatury:

fun close(task:Task)
fun close(task:OpenTask)

Aczkolwiek bez jakiegoś konkretnego przypadku to niewiele wymyślimy ;)

Rozumiem ideę. Tam gdzie masz ustalone i niezmienne reguły biznesowe (np. specyfikację protokołu TCP) jest ok, ale tam gdzie reguły biznesowe mogą się zmieniać (wspomniana elastyczność definiowania flow), to takie podejście pewnie będzie wymagało więcej zachodu.

Pozostało 580 znaków

2019-11-08 00:57
0

Nie no, jak ma być elastycznie, to trzeba zrobić tak:

class Issue
{
    public Map<string, bool> states;
}

Wtedy można zmieniać dynamicznie nie tylko stany, i mieć issue jednocześnie open i closed, ale nawet ich nazwy! I w ogóle jak mamy np. { { "Open": true"}, { "Closed": false } }, to zmienić flow możemy zarówno zmieniając wartości, jak i nazwy kluczy. To jest dopiero elastyczność!

Zresztą, można nawet pójść dalej, bo bool to jednak mocno ograniczający jest, tylko dwie wartości, i zrobić public Map<string, string> states. I wtedy nie ograniczamy się do true i false, ale możemy mieć też "don't care" albo "maybe tommorrow". I oczywiście "null".

UnassignedIssue, AssignedIssue, to złe podejście. Obiektów nie można robić tak dużo, bo zajmują pamięć. No i w ogóle nie mają nic wspólnego z modelem, bo przecież w modelu nie ma czegoś takiego jak przypisane i nieprzypisane zadanie. Absolutnie.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
edytowany 2x, ostatnio: somekind, 2019-11-08 00:57
Widzę że uczysz się tworzyc API od najlepszych -> https://developer.mozilla.org[...]/HTMLMediaElement/canPlayType (patrz na return value) :D - Shalom 2019-11-10 11:47
Nie uczę się, ja uczę innych. ;) - somekind 2019-11-11 22:44

Pozostało 580 znaków

2019-11-08 11:49
0

Pomysł z UnassignedIssue, AssignedIssue to dobre podejście. Można pójść dalej i wymyślić np. TestedIssue albo ImplementedIssue... W encji TestedIssue będą pola odpowiedzialne za dane testowania (kiedy, kto, gdzie testował, itd.


Hey ho!

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