Dev Easy Notes

Я тут слегка пропал, по причине того, что моя критика кода, медленно выросла в целый рофельный доклад на прошлой неделе. На весь доклад в сумме я убил часов 16. Где 6 часов это основная работа, а остальные 10 – боль от мучительных воспоминаний о чистом коде. Это было локальное мероприятие, но надеюсь в этом году я лишусь докладческой девственности и уже выступлю хоть на какой-то конфе.

Идем дальше, а дальше у нас объекты и структура данных. Вот тут вообще глава начинается с такой штуки, которая повлияла на целое поколение Java разработчиков. На меня, в том числе. Я уже упоминал, что немного работал бекендером на Java, и вот на бэке принято делать такие классы как DTO. Просто объекты для отправки результата, мы на мобилки такие делаем когда хотим получить какие-то данные от бэка.

DTO классы всегда делались с методами. Задумайтесь об этом на пару минут: есть класс, он используется исключительно для передачи данных, по факту он просто структура.  Однако мы для доступа к данным все равно делаем геттеры, даже если значения не меняются (т.е final)  и даже если нет никакой логики.

И вот только думая над этим сейчас, я не могу ответить себе на вопрос нахуя? После того как я попробовал go, python, typescript, kotlin я не могу понять, нахера джависты страдали и продолжают страдать этой херней? Почему нельзя напрямую к полю обратиться? Да например в kotlin под капотом как бы генерятся методы, но как часто вы в data классах вы getter подменяете на что-то другое?

И возможно я ошибаюсь, но складывается такое ощущение, что это эта дичь с книги Мартина и пошла. Мы решаем выдуманную проблему, а вдруг нужно будет реализацию подменить в поле. Знаете сколько раз мне такое пришлось делать? 0 раз. А знаете сколько такое нужно было сделать коллегам по бэку? Ответ вы уже знаете.

И это доходит до вообще забавных вещей. У нас есть loombok, что означает что всем было впадлу генерить этот лишний код, однако мыши плакались, кололись, но все равно продолжали кушать кактус.

Мало того, что мы делаем лишние методы, он в книге еще и предлагает все интерфейсом закрывать. Поняли да, типо не класс Point, а интерфейс Point и потом еще реализация PointImpl...

Ну ладно, все что я написал выше уже давно не проблема. В kotlin мы и так обращаемся к полям напрямую (ну почти), а в современной java появились record те же data class из kotlin. Радует что развитие языков убивает странные практики.

www.tgoop.com/dev_easy_notes/291

5.0K viewsNikita, edited  Mar 5, 2024 at 17:55

Я тут слегка пропал, по причине того, что моя критика кода, медленно выросла в целый рофельный доклад на прошлой неделе. На весь доклад в сумме я убил часов 16. Где 6 часов это основная работа, а остальные 10 – боль от мучительных воспоминаний о чистом коде. Это было локальное мероприятие, но надеюсь в этом году я лишусь докладческой девственности и уже выступлю хоть на какой-то конфе.

Идем дальше, а дальше у нас объекты и структура данных. Вот тут вообще глава начинается с такой штуки, которая повлияла на целое поколение Java разработчиков. На меня, в том числе. Я уже упоминал, что немного работал бекендером на Java, и вот на бэке принято делать такие классы как DTO. Просто объекты для отправки результата, мы на мобилки такие делаем когда хотим получить какие-то данные от бэка.

DTO классы всегда делались с методами. Задумайтесь об этом на пару минут: есть класс, он используется исключительно для передачи данных, по факту он просто структура.  Однако мы для доступа к данным все равно делаем геттеры, даже если значения не меняются (т.е final)  и даже если нет никакой логики.

И вот только думая над этим сейчас, я не могу ответить себе на вопрос нахуя? После того как я попробовал go, python, typescript, kotlin я не могу понять, нахера джависты страдали и продолжают страдать этой херней? Почему нельзя напрямую к полю обратиться? Да например в kotlin под капотом как бы генерятся методы, но как часто вы в data классах вы getter подменяете на что-то другое?

И возможно я ошибаюсь, но складывается такое ощущение, что это эта дичь с книги Мартина и пошла. Мы решаем выдуманную проблему, а вдруг нужно будет реализацию подменить в поле. Знаете сколько раз мне такое пришлось делать? 0 раз. А знаете сколько такое нужно было сделать коллегам по бэку? Ответ вы уже знаете.

И это доходит до вообще забавных вещей. У нас есть loombok, что означает что всем было впадлу генерить этот лишний код, однако мыши плакались, кололись, но все равно продолжали кушать кактус.

Мало того, что мы делаем лишние методы, он в книге еще и предлагает все интерфейсом закрывать. Поняли да, типо не класс Point, а интерфейс Point и потом еще реализация PointImpl...

Ну ладно, все что я написал выше уже давно не проблема. В kotlin мы и так обращаемся к полям напрямую (ну почти), а в современной java появились record те же data class из kotlin. Радует что развитие языков убивает странные практики.

BY Dev Easy Notes