Review przykładowego kodu serwera REST

6

Cześć!

Czasem się tu wymądrzam jaki to Spring / JavaEE jest do bani etc. A bazy danych durne.
Od jakiegoś czasu w wolnych chwilach pracowałem nad przykładem takiego serwera, żeby można było ogarnąć o co mi chodzi.
Więc oto jest:
https://github.com/javaFunAgain/ratpong

To serwer do gry w PONG opary o bibliotekę Ratpack.

(Zawiera też kod klienta więc powinien działać (sorry klient jest bardzo brzydki :-). Można się nad nim popastwić tutaj: https://github.com/jarekratajski/scalajspounk, ale to React i ScalaJS - zupełnie inna historia).

Proszę o przyjrzenie się krytykę, uwagi. Moim celem jest zrobienie kompletnego przykładu z jasnym opisem.

0

takie mam pytanie, czy trzymanie Userów w repo to nie jest overkill?

2

Tak na pierwszy rzut oka nie podobają mi się te długie lambdy w serwisach choćby tu:
https://github.com/javaFunAgain/ratpong/blob/master/src/main/java/pl/setblack/pongi/games/GamesService.java#L128
ale jest ich sporo w tym kodzie w serwisach.

A tego zapisu trochę nie rozumiem:
https://github.com/javaFunAgain/ratpong/blob/master/src/main/java/pl/setblack/pongi/games/GamesService.java#L97

Po co tworzysz w lambdzie zmienną lokalną żeby ją zaraz zwrócić?

Moim zdaniem znacznie czytelniej byłoby jednak zrobić prywatną metodę zamiast tych długich lambd a tam dać method reference, bo teraz masz tam czasem jakieś 3 levele kilkulinijkowych lambd i moim zdaniem jest to równie słabe co klasyczne wiele poziomów zagłębienia w metodzie.

3

Nie chce się jakoś specjalnie czepiać, ale dla mnie np. nieczytelne są tuple (nie lubię). Sam kiedyś próbowałem ich używać (tyle, że korzystając z implementacji Apache Commons Lang) uznałem, że czytelniej odwzorować domenę za pomocą immutable klasy o dobrej nazwie: to czytelniejsze niż tuple. Wszystko było ok póki miałem pary. Potem jednak domena zaczęła się komplikować (drzewa) i prościej było zbudować dobre domenowe klasy (zrezygnowałem z tupli). Tuple wydają mi się takim brudnym przyspieszaczem pracy, gdzie dla bardzo prostych przypadków nie chce nam się definiować klas. Jednak jak potem coś się "w praniu" skomplikuje to IMO kosztują więcej niż oszczędzają: mam na myśli modyfikacje w przyszłości.

Mam na myśli coś takiego:
https://github.com/javaFunAgain/ratpong/blob/master/src/main/java/pl/setblack/pongi/games/api/Ball.java

    private Tuple2<Ball, Tuple2<Player,Player>> bouncePlayer1(Tuple2<Player, Player> players, final Random rnd) {
        if ( this.x < 0 && speed.x < 0) {
            if (isTouchingPaddle(players._1.paddle, this.y)){
                return Tuple.of(new Ball(0f, this.y, this.speed.bounceX()), players);
            } else {
                return Tuple.of(Ball.randomDirection(rnd), players.map(pl1->pl1, pl2->pl2.score()));
            }
        }
        return Tuple.of(this, players);
    }

Ja rozumiem, że taka konstrukcja odwołuje się do składowej tupla:

players._1

można się domyślić o co chodzi, jednak wolałbym się odwoływać po polu z nazwą dla człowieka.

1

O przeoczyłem to :) Ja jestem przeciwny w ogóle stosowaniu takich tasiemiastych typów które nie wiadomo za bardzo co oznaczają. Bo co "biznesowo" oznacza Tuple2<Player,Player>? A już Tuple2<Ball, Tuple2<Player,Player>> to masakra. Trochę w stylu jakiegoś Map<String, Map<String, List<Integer>>> które bez komentarza na temat przechowywane zawartości trudno ogarnąć.
Wiem ze to zwykle upierdliwe żeby robić sobie takie wydmuszkowe wrappery na jakiś względnie prosty typ, ale kod czyta się potem dużo wygodniej kiedy mamy jakiś konkretny nazwany typ a nie luźną krotkę. Wyklucza to też jakieś głupie błędy w stylu: jaka jest kolejność playerów w tej krotce? albo jeśli są tam jakieś klasy podstawowe to wyklucza pomylenie parametrów tego samego typu.

0

Bardzo dziękuję za uwagi. Miałem mało czasu i dopiero teraz wrzucam poprawki.
Wszystkie uwagi są sensowne i perspektywiczne - to znaczy, że wiem dodatkowo w jakim dalej kierunku poprawiać. Niestety refaktor nigdy się nie kończy (a wyszło, że jeszcze część kodu niepokryta testami (zaszłość copy-paste z wcześniejszej wersji).

Największa zwała pod względem wpływu na kod została odkryta przez @margor90 więc dlatego tą odpowiedź akceptuję (bo chyba tylko jedną mogę).

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