Aktywne Wpisy
Johny_Lepa +1
Mam pytanie dotyczące ruletki. Mam znajomego, który twierdzi, że potrafi osiągać długie serie wygranych, nawet powyżej 20 rzutów. Mówi, że dzięki analizie historycznych danych o tym, kiedy wypadały czarne i czerwone pola, mógł przewidywać wyniki i osiągać takie serie. Tłumaczył to na przykładzie rzutu monetą, mówiąc, że jeśli 10 razy z rzędu wypadnie orzeł, to prawdopodobieństwo, że przy następnym rzucie znowu wypadnie orzeł, maleje i wtedy należy obstawiać przerwanie serii i że
lunaria +2
https://github.com/Sampeteq/cinema-app
#java #naukaprogramowania #programowanie
*
domain/Room.java
nie powinien mieć w sobie bazodanowego śmiecia. Powinieneś mieć osobny "czysty" typ domenowy zwracany przez repozytorium a to co masz teraz powinno iść tam gdzie jest implementacja* brak serwisów domenowych
* dwustrona relacja pomiędzy appllication a domain: application używa domain a domain oczekuje całą tranzakcyjność od
Klasy które mają po jednej metodzie? Pakiety, podpakiety, podpodpodpakiety a w środku po 3 pliki? Klasy, które nic nie robią a tylko przekazują sterowanie gdzieś dalej? Po ch*j to? Nie cierpię takiego stylu kodowania.
Projekt tej wielkości powinien być płaski. Jeden pakiet, kilka klas reprezentujących dane wyciągane z bazy, jeden serwis zawierający całą logikę.
1. UserPasswordResetHandlerService
log.info("Mail sent");
Ten logger niczego nie mówi, dodaj kontekst (np. typ
@Krolik: ma to sens jak chcesz sobie pocwiczyć. W praktyce taki kod nie ma sensu przy tej skali i zerowej logice
Nie lepiej po prostu zrobić jeden serwis dla danej funkcjonalności, np. ogólny UserService w którym możesz zrobić tworzenie, pobieranie, edytowanie usera i jego składowych
@
jak gdzieś w klasie używasz pola to nie musisz pisać this.pole tylko samo pole