Jak się pisze teraz POJO?

Jak napiszesz POJO?
wersja 1
50%
50% [8]
wersja 2
31%
31% [5]
wersja 3
19%
19% [3]
Odpowiedz Nowy wątek
2019-11-30 02:57
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;
    }
}
edytowany 1x, ostatnio: Julian_, 2019-11-30 11:12
Za brak wielkiej litery na początku klasy karny .... - Burdzi0 2019-11-30 09:50

Pozostało 580 znaków

2019-11-30 06:24
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.

edytowany 6x, ostatnio: Burmistrz, 2019-11-30 06:40

Pozostało 580 znaków

2019-11-30 07:19
3
class MyMessage(val id: Long,  val content: String) {}

Scala :)


edytowany 1x, ostatnio: elwis, 2019-11-30 07:20
Przed class warto dodać case a klamry są niepotrzebne :) - tdudzik 2019-11-30 14:26
Tak, chociaż nie byłem pewny, więc napisałem najprościej i w sumie krócej :) - elwis 2019-11-30 14:56
W zasadzie z case class wyglądałoby tak: case class MyMessage(id: Long, content: String) więc chyba jednak krócej. :D - tdudzik 2019-11-30 15:11
Aaa ,ok.Dobrze wiedzieć. W scali pracowałem w sumie krótko, jednak zawsze doceniałem zwięzłość. - elwis 2019-11-30 15:14
Która czasem jest ogromną zaletą, a czasem przekleństwem. :) - tdudzik 2019-11-30 15:19

Pozostało 580 znaków

2019-11-30 09:49
2
data class MyMessage(val id:Long, val content:String)

Kotlin


Pozostało 580 znaków

2019-11-30 10:42
4

JavaScript

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

Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 1x, ostatnio: jarekr000000, 2019-11-30 10:43
To jest struktura, to raczej Gosling kiedyś musiał stwierdzić "struktury, komu to potrzebne" i tak się pałujemy w Javie od dziesiątek lat z jakimiś namiastkami w rodzaju DTO (bez O na końcu), JavaBeans czy Lombok. - vpiotr 2019-11-30 11:09
Generalnie obiekt bez logiki to nie obiekt tylko właśnie struktura. Obiektówka polega na tym, że istnieje byt (obiekt) łączący dane z kodem operującym na tych danych. To co pokazał OP wygląda na strukturę, bo nie widać logiki. Poza tym normalny obiekt z logiką raczej nie miałby getterów do całego stanu. - Wibowit 2019-11-30 21:12

Pozostało 580 znaków

2019-11-30 11:24
0

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


Nie pomagam przez PM. Pytania zadaje się na forum.
A ktota wersja z tych mouch jest mutowalna? - Julian_ 2019-11-30 14:08

Pozostało 580 znaków

2019-11-30 11:27
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!)

Szacuje się, że w Polsce brakuje 50 tys. programistów

Pozostało 580 znaków

2019-11-30 21:04
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.

edytowany 5x, ostatnio: Burmistrz, 2019-11-30 21:10

Pozostało 580 znaków

2019-11-30 21:13
5

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


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
Oni e javie 5 pisza - Julian_ 2019-11-30 21:52

Pozostało 580 znaków

2019-11-30 21:13
0

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


01010100 01110101 01110100 01100001 01101010 00100000 01101110 01101001 01100101 00100000 01101101 01100001 00100000 01101110 01101001 01100011 00100000 01100011 01101001 01100101 01101011 01100001 01110111 01100101 01100111 01101111 00101110 00100000 01001001 01100011 00100000 01110011 01110100 01101111 01101110 01110100 00101110
Właśnie to miałem na myśli. - Burmistrz 2019-11-30 21:18

Pozostało 580 znaków

2019-11-30 21:18
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/~[...]oetz/amber/pattern-match.html


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 6x, ostatnio: Wibowit, 2019-11-30 21:49

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