Jak się pisze teraz POJO?

0

Jaka jest teraz moda:

1:

class MyMessage {
    private final long id;
    private final String content;

    public MyMessage(long id, String content) {
        this.id = id;
        this.content = content;
    }

    public long getId() {
        return id;
    }

    public String getContent() {
        return content;
    }
}

2:

class MyMessage {
    public final long id;
    public final String content;

    public MyMessage(long id, String content) {
        this.id = id;
        this.content = content;
    }
}

3:

class MyMessage {
    @Getter
    private final long id;
    @Getter
    private final String content;

    public MyMessage(long id, String content) {
        this.id = id;
        this.content = content;
    }
}
2

Nie programuję w Javie, ale najbardziej podoba mi się ten trzeci z opisanych przez Ciebie sposóbów. W C# zrobiłbym to tak:

class MyMessage
{
    public long Id { get; }
    public string Content { get; }

    public MyMessage(long id, string content)
    {
        Id = id;
        Content = content;
    }
}

Albo { get; private set; } lub { get; protected set; } w zależności od potrzeby.

3
class MyMessage(val id: Long,  val content: String) {}

Scala :)

2
data class MyMessage(val id:Long, val content:String)

Kotlin

4

JavaScript

var myMessage = {id:1, content:'klasy? A komu to potrzebne?'}
0

Jaki jest racjonalny powód żeby tworzyć mutowalne DTOsy albo obiekty domenowe?
Mutowalny może być InputStream albo Connection do bazy danych...

6

Wersja 4:

import lombok.Builder;
import lombok.Data;

@Data
@Builder
class MyMessage {
    private final long id;
    private final String content;
}

Użycie:

System.out.println("Message: "+MyMessage.builder().id(2L).content("Hello world!").build());

Wynik:

Message: MyMessage(id=2, content=Hello world!)
0

Ej, bez przesady z tymi innymi językami. Ja wspomniałem o C#, bo trzeci sposób w javie wygląda tak, jak obecnie pisze się w C# (mam nadzieję, że prywatne pole z tym dziwnym atrybutem @Getter ma publiczny getter). Liczyłem na odpowiedź na pytanie Juliana i poznanie trendów w podobnym do C# języku. Ostatnio słyszałem, że używanie getterów i setterów w javie nie jest najlepszą praktyką, ale zastanawiam się, czy może coś źle zrozumiałem, bo nie rozumiem, co jest z nimi nie tak. Ale może chodzi o metody get...() i set...(), a nie o automatyczne właściwości.

5

Najlepiej pisać tak jak koledzy z zespołu, by utrzymać spójność w projekcie.

0

Jesli przez 'wlasciwosci' masz na mysli properties to w javie takich nie ma

0

W Javie 14 wchodzą rekordy w wersji preview https://openjdk.java.net/jeps/359 przy czym nie ma wprost propertiesów:

Non-Goals
It is not a goal to declare "war on boilerplate"; in particular, it is not a goal to address the problems of mutable classes using the JavaBean naming conventions. It is not a goal to add features such as properties, metaprogramming, and annotation-driven code generation, even though they are frequently proposed as "solutions" to this problem.

Rekordy są niemutowalne:

Records provide a compact syntax for declaring classes which are transparent holders for shallowly immutable data.

Składnia jest zwięzła:

record Point(int x, int y) { } // tadam! tylko tyle wystarczy

Z automatu generowane są pola, gettery, konstruktor, equals, hashCode, toString i jeszcze jakieś dodatkowe rzeczy:

a record acquires many standard members automatically:

  • A private final field for each component of the state description;
  • A public read accessor method for each component of the state description, with the same name and type as the component;
  • A public constructor, whose signature is the same as the state description, which initializes each field from the corresponding argument;
  • Implementations of equals and hashCode that say two records are equal if they are of the same type and contain the same state; and
  • An implementation of toString that includes the string representation of all the record components, with their names.

Reflection API
The following public methods will be added to java.lang.Class:

  • RecordComponent[] getRecordComponents()
  • boolean isRecord()

Docelowo mogą być wykorzystane do pattern matchingu (chodzi o dekonstrukcję klas, nie regexy) w Javie: https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html

0

Chciałbym, żeby więcej się pisało w wersji 2, ale w praktyce zazwyczaj jest wersja 4

1

Ostatnio się zastanawiałem, dlaczego mimo w miarę dokładnego przerobienia podstaw i bardzo dobrej oceny z Javy na studiach spodobał mi się i rzucił na mnie urok C# poznany w późniejszym czasie i używany obowiązkowo tylko na laborkach z grafiki komputerowej. Po przeczytaniu tego wątku chyba już wiem, co mną kierowało (oprócz bardzo wygodnego IDE).

1
vpiotr napisał(a):

Wersja 4:

import lombok.Builder;
import lombok.Data;

@Data
@Builder
class MyMessage {
    private final long id;
    private final String content;
}

Użycie:

System.out.println("Message: "+MyMessage.builder().id(2L).content("Hello world!").build());

Wynik:

Message: MyMessage(id=2, content=Hello world!)

Po co tak? Jaką przewagę ma takie rozwiązanie nad wersją 2? Rozumiem że Lombok stara się zakryć ułomność języka ale w tym przypadku nie ma potrzeby używania go.

4

dlaczego programujecie adnotacjami, a nie kodem?

0
WeiXiao napisał(a):

dlaczego programujecie adnotacjami, a nie kodem?

Uważaj z takimi pytaniami.
Ja zacząłem ( od niedawna) zadawać to pytanie) i okazuje się, że jestem obrazoburcą, nie rozumiem abstrakcji i nienawidzę javy.

A tak serio - 15 lat temu ( 1500 latte temu) my javowcy pisaliśmy wszystko w XMLu, były na ten temat fajne dowcipy (tylko, że to nie było dowcipy...).
Ludzie, którzy wtedy pisali te XML dziś są architektami. Co ciekawe, po latach przyjęli do wiadomości, że to było zło i nie piszą już XMLi.
Tylko pisza je w adnotacjach :-) ważne, żeby nie pisać kodu w javie - od lat nikt tego nie próbował, nie wiadomo co by sie mogło stać,
sądząc po pytaniach z sali (do moich prezentacji) to nie wiadomo czy to nawet jest production ready.

Ale jest nadzieja, od jakiegoś czasu coraz więcej rzeczy w springu nie robi się adnotacjami.

Teraz się pisze YAMLe.

0
WeiXiao napisał(a):

dlaczego programujecie adnotacjami, a nie kodem?

Trochę przesadzacie. W tym wygenerowanym przez Lomboka kodzie jest dokładnie 0 logiki biznesowej. Adnotacje są ułomne, ale czy copy paste jest zawsze lepsze?

0

Ostatnio na pewnej konferencji brałem udział w konkursie z Javy. Zaznaczyłem odpowiedzi w taki sposób, jakby to był .NET, bo przecież kompilator powinien zwrócić błąd nie czekając na oczywisty exception, który wystąpi na 100% po uruchomieniu programu, ale koledzy powiedzieli, że Java jest dziwna i nie mogę tego tak porównywać. Dla mnie to jest lekko niezrozumiałe.

11
jarekr000000 napisał(a):

Uważaj z takimi pytaniami.
Ja zacząłem ( od niedawna) zadawać to pytanie) i okazuje się, że jestem obrazoburcą, nie rozumiem abstrakcji i nienawidzę javy.

TTZWJ1B.jpg
0

@Data robi settery więc raczej odpada.
Ja robię w Javie tak:

@FieldDefaults(makeFinal = true, access = PRIVATE)
@RequiredArgsConstructor
@Getter
class MyMessage {
    long id;
    String content;
}

Można zdefiniować plik lomok.config i ustawić globalnie dla wszystkich klas FieldDefaults, dodatkowo od Springa 4.3 w którym to już nie trzeba używać adnotacji @Autowired jeśli wstrzykujemy przez konstruktor to możemy klepać tak (zakładając, że mamy lombok.config) :


@RequiredArgsConstructor
class MyMessage {
    MyService1 myService;
    MyService2 myService;
    MyService3 myService;
}

Ktoś powie że pisanie w adnotacjach ale szczerze wolę to niż 3/4 klasy składającej się z boilerplate'u

2

nie wiem czy tak sie robi „teraz” ale nie uzywam setterow w ogole, getterow praktycznie tez nie a pojo uwazam za zbedne. btw adnotacje to zlo

0

Co do POJO to jest jeszcze spór ineterpretacyjny. Część uważa, że to takie javabeany, a część, że to kazdy normalny, nie-popsuty jakimiś magiami i konwencjami obiekt javowy.

0

Jak patrzę na to pytanie, to cholera mnie bierze, że przez lata swojego istnienia Java nie znalazła dobrego sposobu na napisanie DTO'sa. Albo pisanie getterów z d....y, albo brnięcie w wynalazki typu Lombok.

1

Jak to nie wynalazła?
Java wynalazła Scalę (albo Kotlina) - gdzie takie problemy i tony innych są rozwiązane.

0
jarekr000000 napisał(a):

Co do POJO to jest jeszcze spór ineterpretacyjny. Część uważa, że to takie javabeany, a część, że to kazdy normalny, nie-popsuty jakimiś magiami i konwencjami obiekt javowy.

piotrpo napisał(a):

Jak patrzę na to pytanie, to cholera mnie bierze, że przez lata swojego istnienia Java nie znalazła dobrego sposobu na napisanie DTO'sa. Albo pisanie getterów z d....y, albo brnięcie w wynalazki typu Lombok.

Podejrzewam, że tutaj zostało wypaczone pojęcie DTOsa :] DTO, jak sama nazwa wskazuje, służy do pchania po kablu (czy ogólnie do komunikacji międzyprocesowej), a nie do używania go w logice biznesowej. DTOsy są takie dość jednorazowe, nie widzę nawet sensu wpychania tam akcesorów, propertiesów czy czegokolwiek wygenerowanego.

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