Option(ale) jako pola zamiast nulli?

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ę).

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/... ;)

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? ;)

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

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 :-)

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 ;)

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

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.

1

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.

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.

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

Robot: Semrush