[D.....e]

Utwierdzam się w przekonaniu, że Java to język prymitywny.

Nie ma propert. Właściwości. Jest za to wszędzie używane coś takiego jak poniżej. Nie chodzi nawet o pisanie tego bo może pomóc snippet ale czytanie i rozmiar klas.

JAVA:
private String name;

public String getName() { return this.name; }
public void setName(String name) { this.name = name; }
C#:
private string Name { get; set; }

#java #programowanie #csharp

[fegwegw]

public String name;

@DylematyMoralne: szach-mat.

[Myzreal]

@DylematyMoralne: To pozostałość z dawnych czasów, C# to jednak język młodszy od Javy. Jest to jedna z bolączek Javy, ukrócona chociażby przez Kotlina czy Scalę. Jest też rozpisany JEP z propozycją wprowadzenia do Javy data classes, gdzie nie trzeba będzie ani getterów, ani setterów, ani equals ani hashcode ani nic. Nie pamiętam czy celowany na najbliższy release czy na późniejszy. Ewentualnie, na dzień dzisiejszy może zainteresować cię Project Lombok, który oszczędzi

[D.....e]

@fegwegw: Tragedia. Ogranicz ustawianie z zewnątrz? Zrób tak, żeby kod był przy tym jednolity a nie raz metodami raz polami?

[leoha]

prowadzenia do Javy data classes

@Myzreal: przecież to jest w zupełnie innym celu niż, dodanie "właściwości".

[fegwegw]

Ogranicz ustawianie z zewnątrz?

@DylematyMoralne: publiczny setter też niewiele ogranicza.

roject Lombok, który oszczędzi ci getterów i setterów choć sam go nie lubię bo to hack.

@Myzreal: polecam AutoValue, to już nie jest hack.

[tell_me_more]

@DylematyMoralne: nikt normalny nie broni braku własności w Javie. Z drugiej strony IMHO settery i gettery (nieważne, czy zrobione ładnie, czy brzydko) to głupie rozwiązanie tworzące więcej problemów, niż rozwiązują.

Podstawowym problemem jest programowanie obiektowe, reszta problemów wynika z tego :)

[D.....e]

@Myzreal: Wylewam tylko żale mojego poznawania Javy. Jak wspomniałem problem dla mnie nie tylko pisanie a chodzi głównie o wertowanie dziesiątek klas które muszę przejrzeć a są między innymi przez powyższy przykład nieczytelne.
Zostałem demokratycznym wyborem głosem prezesa zmuszony do używania Javy w firmie która nie ma programistów Javy ale na szczęście tylko przez kilka tygodnia raz na parę miesięcy ( ͡° ͜ʖ ͡°)

[D.....e]

@fegwegw:

C#:
private string Name { get; }

I już gotowe. Mając kila pól jeden pod drugim może to wyglądać tak:

private string NameA { get; set; }
private string NameB { set; }
private string NameC { get; }
private string NameD
{
set
{
//operacje
}
}

W Javie to by było niezłe spaghetti mieszanka metod publicznych pól,

[D.....e]

@tell_me_more:

IMHO settery i gettery (nieważne, czy zrobione ładnie, czy brzydko) to głupie rozwiązanie tworzące więcej problemów, niż rozwiązują.

A ciekawe jakie tworzą problemy. To przecież są tak naprawdę metody, które jedynie ułatwiają czytanie i przyspieszają pisanie. Nic poza tym.

[witajswiecie]

@DylematyMoralne nie żeby coś ale ładowanie jakiejkolwiek logiki w settery i gettery samo w sobie jest przejawem spagetti(tak a propo tego set //operacje ) , po kiego diabła czytać cały kod dtosów

[tell_me_more]

@DylematyMoralne: settery to ściema umożliwiająca ludziom programującym strukturalnie twierdzić, że programują obiektowo. Mają plusy - bo pozwalają zrobić cokolwiek, w przeciwieństwie do czystego OO, ale mają też minusy - bo po #!$%@? się tak bawić w udawanie przed samym sobą?

Główna zasada programowania obiektowego: nie rób if (x.getCośtam == cośtam) x.setCośtam, tylko x.zróbCośtam i niech on się oto troszczy. Widzisz, jak settery to psują?

Do tego settery i gettery utrudniają programowanie

[D.....e]

@witajswiecie: Są pewne standardy co tam można umieścić. Ewentualne sprawdzanie nulla albo jakieś proste sumowanie. Ale skomplikowanej logiki połączeń do bazy wywołań innych klas tam się nie robi.

po kiego diabła czytać cały kod dtosów

Po kiego diabła w ogóle czytać kod ( ͡° ͜ʖ ͡°)

[D.....e]

@tell_me_more: Może zastosowania do których używasz faktycznie nie są zbyt kompatybilne z OOP. Programowanie obiektowe ma dać dużą czytelność i ułatwić programowanie w większych zespołach skomplikowanych systemów z dużą logiką biznesową. Wydajność to często kompromisy. Czas pisania w OOP też może być dłuższy.
Pisanie jakiegoś migratora danych, który będzie użyty raz albo dwa w porządnym OOP i jeszcze przy trzymaniu się standardów jak SOLID to głupota i zrobią tak początkujący i

[witajswiecie]

@DylematyMoralne w mojej opinii w takim razie są to kiepskie standardy, po to się tworzy klasy modelowe by były one odseparowane od logiki, ładowanie tam czegokolwiek więcej to proszenie się o problemy (chociażby przy serializacji) ( ͡° ʖ̯ ͡°) jak dla mnie propercje są rozwiązaniem problemu który nie istnieje (albo raczej istnieje na poziomie projektowania aplikacji nie języka )

z resztą żeby nie być gołosłownym wystarczy czasem rzucić

[fhsdjklvgnasiogfy]

@DylematyMoralne: Settery i gettery dla DTO nie mają sensu, ale na przykład w obiektach biznesowych możesz mieć rzeczy które są lazy-loaded, albo po prostu wyliczane z innych pól. W tym przypadku enkapsulacja jak najbardziej ma sens.

[Myzreal]

@DylematyMoralne: Współczuję bycia zmuszonym do pisania w języku, w którym normalnie nie piszesz. Jeśli używasz IntelliJ do tego to spróbuj po prostu zadeklarować zmienne a potem Alt+Insert i tam ejst opcja Getter+Setter, samo ci wygeneruje.

[D.....e]

@fhsdjklvgnasiogfy: W C# to standard. Użyto ich to usprawnienia serializacji i wiele innych.
W Javie nie wiem czy to standard ale zarówno w kodzie, który mam jak i w większości przykładów jest dużo takich seterów i geterów w formie metod. A ja to muszę czytać :( Faktycznie wolałbym żeby nie było. I tak ja robię swoje klasy.

[zolwixx]

@DylematyMoralne: jest jakieś rozszerzenie, czy inna biblioteka, że po prostu deklarujesz

@Getter @Setter

private String zmienna;

[D.....e]

@zolwixx: Noo to bym musiał jeszcze zrefaktoryzować ten cały kod co to go dostałem ( ͡° ͜ʖ ͡°)

[I.....e]

@zolwixx: lombok, rozwiązuje masę problemów javy dodając do niej drugie tyle własnych xd