Comments 6
Ну и немного ещё по статье — те же сеттеры генерируются IDE, какие-то необычности внутри так и так нужно писать вручную, а пропускать через генерацию — увеличивать шанс появления ошибок. Даже просто переключение меду проектами ради одного нового класса займёт больше времени, чем по быстрому накидать этот самый класс с дополнениями, которые мог бы делать генератор.
Вижу только узкую нишу для подобных решений, что-то вроде генерации сразу нескольких аналогичных классов для разных частей проекта, тогда действительно можно один раз накидать схему, а потом из неё получится много всего. Но это редкая операция, поэтому затраты на изучение и поддержание проекта Xtend выглядят не окупающимися, разве что для удовольствия разработчиков поковыряться в чём-то новом.
В конце концов, если уж используется Spring Boot, который по сути есть банальный шаблонизатор, то можно было бы эти же самые шаблоны генерировать (и не только «эти же самые»), хотя и здесь опять польза не гарантирована.
Спасибо за развернутый комментарий. Пример в статье лишь для того, чтобы продемонстрировать возможности и конечно его можно расширять с дополнять,
вооружившись пониманием, как все работает на базовом уровне.
В нашем случае, по коду модели генерируется и слой хранения и DTO и код модели на клиенте и ресурсы,
таким образом все это остается консистентным и изменения разработчику надо вносить в одном конкретном месте.
В рамках кодогенерации мы практически никогда не говорим про один конкретный класс, речь идет про типовой код, которого может быть достаточно много,
он должен породжаться по каким-то условиям и который не хочется повторять.
Механика здесь примерно такая — сначала код пишется руками, мы видим закономерность, после пары повторений переносим его в генератор и профит.
Например, нам нужны константы для всех полей сущности с именами, чтобы дальше по коду на них ссылаться при определении отношений, классно же,
если такой код будет генерироваться и оставаться всегда актуальным. Или какие-то простенькие скрипты миграции, мы добавили поле, а у нас уже есть нужный alter table.
Тоже в своё время игрался со всякой кодогенерацией, магией и прочим. И оказалось, что чем меньше такой магии в коде, тем проще его потом поддерживать. ИМХО.
Прекрасно понимаю, что общий опыт скорее негативный, потому и пишу про все это, чтобы показать, что подход может использоваться и во благо и приносить ощутимую пользу.
В генерацию переносится код, который ни писать руками, ни тем более рефакторить никто не собирается, код, который генерируется должен быть понятным и делать конкретные вещи,
в этом смысле магии становится меньше, а не больше, ведь мы не прячем суть за кучей прокси и чего-то еще, что появляется вдруг в рантайме.
Если генератор для себя пишете вы сами, а я пытаюсь показать, что это не так уж и сложно, то вы сами контролируете ситуацию и с тем, как методы называются и как работают.
Рефакторинг и даже багфиксинг в этом случае выглядит немного по другому — вы сначала правите код генератора, проверяете все на тестах, а дальше прикладной код меняется везде,
где этот генератор используется при этом у вас куда больше возможностей, чем просто поиск и замена.
В качетве бонуса, примерно так же происходит миграция на новые версии библиотек и фреймворков, которые в нашем коде используются — смотрим, что поменялось, фиксируем эти изменения в одном месте,
а потом скоупом переезжаем — это куда приятнее и продуктивнее, чем поменяв версию зависимости сначала править ошибки компиляции, а потом и все остальные.
Используем Xtend для прикладной кодогенерации: сеанс чёрной магии с разоблачением