Было пару мелких игр типа quiz (угадай объект по фотографии), суммарно установок было около миллиона. Авторы фотографий начали кидать жалобы и после бана третей игры был закрыт аккаунт.
В первых письмах я на них наезжал за беспредел, в последнем раскаялся и признал вину что я фотографии получал без согласий их авторов.
Мне как-то заблокировали мой аккаунт и все приложения. Опеляции не помогали и я забил на все это. Через год написал еще одно письмо мол все осознал и был не прав, так они разблокировали аккаунт со всеми приложениями. Такой вот хеппи энд :)
В вашем случае, на сколько я понял, это обертка возвращается вашим контроллером, по сути ничего, кроме эстетического момента меня не смущает.
Если же вы проектируете api какой-либо библиотеки, которую будут использовать сторонние разработчики, то тут я бы воздержался от таких конструкций. Разработчик может вызывать такой код в различных циклах миллионы раз, зачем провоцировать GC на лишнюю работу за зря?
Для меня лично не приемлем тот факт что без специального плагина для IDE с этим самым Lombok невозможно нормально работать. Это главная причина того, почему я не буду использовать это в своих проектах.
Нужно конечно видеть код, что бы подсказать альтернативный путь для решения этой задачи без дополнительных объектов-оберток.
Возможно что ваш подход хорошо подходит именно в вашем случае. Тут я спорить не буду.
Немного необычный подход с оберткой над объектом для генерации json.
Обычно делаются статические методы в хелпер-классе, например EntityHelper.toJson(myEntity)
В вашем случае идет совершенно ненужное создание +1 объекта обертки к каждой операции конвертации объекта в Json
Не буду спорить что ваш подход выглядит короче, круче :)
Не согласен, так можно было вообще писать на Java 5 или Java 3. Язык вполне гибкая штука, в Java огромное количество открытых библиотек, которые тоже расширяют возможности. По такой логики их тоже не стоит использовать.
Вы передергиваете :) Речь ведь о языке в целом, а не конкретно какой-то её версии.
Генерация кода для DI вынужденная мера, тут я согласен.
В остальном, не западло прописать getter/setter потому что это Java, тут так принято.
Хотите нормальную аргументацию?
Для нормальной работы этого чудо модуля нужно ставить расширение для IntelliJ IDEA
Все эти генерации могут усложнить/замедлить скорость сборки проекта
Все эта магия вгонит в ступор первого же человека кто начнет разбираться в таком коде.
Ненужно пытаться нагнать всевдо-читаемость такими плагинами.
Если что, есть много других языков где ненужно писать getter/setter :)
Никогда не понимал людей кто юзает эту либу.
Для нового продукта можно выбрать лаконичные scala или koltin.
А в бородатый энтерпрайз вряд ли кто то станет это внедрять.
Нужно принимать язык таким как каким он есть.
Автор большой молодец!
Я выпускал простые игрушки на Android лет 5 назад, тогда для попадания в топы нужно было около 500 установок.
С играми сейчас сложнее, если при старте не стрельнуло, дальше будет только тяжелее.
С программами немного проще в том плане что понемногу можно набирать аудиторию которую можно потом переводить на платную подписку.
Кто то знает может существует телеграмм канал где собираются инди разработчики? Было бы интересно делится опытом там в режиме чата.
Кстати можно наследовать активити и фрагменты от DaggerAppCompatActivity и DaggerFragment из пакета dagger.android.support что бы уйти от ручной инъекции.
В первых письмах я на них наезжал за беспредел, в последнем раскаялся и признал вину что я фотографии получал без согласий их авторов.
Если же вы проектируете api какой-либо библиотеки, которую будут использовать сторонние разработчики, то тут я бы воздержался от таких конструкций. Разработчик может вызывать такой код в различных циклах миллионы раз, зачем провоцировать GC на лишнюю работу за зря?
Возможно что ваш подход хорошо подходит именно в вашем случае. Тут я спорить не буду.
Обычно делаются статические методы в хелпер-классе, например EntityHelper.toJson(myEntity)
В вашем случае идет совершенно ненужное создание +1 объекта обертки к каждой операции конвертации объекта в Json
Не буду спорить что ваш подход выглядит короче, круче :)
Вы передергиваете :) Речь ведь о языке в целом, а не конкретно какой-то её версии.
Генерация кода для DI вынужденная мера, тут я согласен.
В остальном, не западло прописать getter/setter потому что это Java, тут так принято.
Хотите нормальную аргументацию?
Для нормальной работы этого чудо модуля нужно ставить расширение для IntelliJ IDEA
Все эти генерации могут усложнить/замедлить скорость сборки проекта
Все эта магия вгонит в ступор первого же человека кто начнет разбираться в таком коде.
Ненужно пытаться нагнать всевдо-читаемость такими плагинами.
Если что, есть много других языков где ненужно писать getter/setter :)
Для нового продукта можно выбрать лаконичные scala или koltin.
А в бородатый энтерпрайз вряд ли кто то станет это внедрять.
Нужно принимать язык таким как каким он есть.
Я выпускал простые игрушки на Android лет 5 назад, тогда для попадания в топы нужно было около 500 установок.
С играми сейчас сложнее, если при старте не стрельнуло, дальше будет только тяжелее.
С программами немного проще в том плане что понемногу можно набирать аудиторию которую можно потом переводить на платную подписку.
Кто то знает может существует телеграмм канал где собираются инди разработчики? Было бы интересно делится опытом там в режиме чата.
Повторю, автор большой молодец!