Изменение сгенерированного кода или использование наследования? - PullRequest
7 голосов
/ 07 июля 2010

Я работаю над проектом EMF.Одним из проектных решений было не касаться сгенерированного кода и не регистрировать его. Вместо этого, всякий раз, когда что-то необходимо изменить, создается подкласс, содержащий изменения.Структура достаточно гибкая, чтобы справиться с этим.Тем не менее, я испытываю некоторые накладные расходы.

Проектное решение было принято на основе неудачного опыта, связанного с другими средами генерации кода, с целью повторного создания проблем.

Будучи новичком в проекте, я хотел бы оспорить это дизайнерское решение, нохотел бы услышать общее мнение в первую очередь.Я знаю, что команда проекта EMF рекомендует внести изменения в код.Но каков ваш опыт?Насколько хорошо EMF обрабатывает ручные изменения кода в сгенерированном коде?Вы когда-нибудь приходили к тому, что теряли написанный вручную код?Код когда-нибудь входил в необслуживаемое состояние?

Ответы [ 2 ]

7 голосов
/ 07 июля 2010

Но каков ваш опыт?

Я реализовал два отдельных проекта, оба из которых включали модели с 50 или более классами моделей, и в обоих случаях модели развивались в течение всего жизненного цикла проекта; то есть лотов изменений модели. В обоих случаях я изменил сгенерированный код, чтобы обычно реализовывать вычисляемые атрибуты, проверку и настраивать редакторы различными способами.

Насколько хорошо EMF обрабатывает ручные изменения кода в сгенерированном коде?

Работает хорошо. Иногда генератор генерирует код, который не компилируется из-за некоторых изменений в модели, но исправления обычно просты; например удаление классов / интерфейсов Java, неработающий импорт и т. д.

Вы когда-нибудь приходили к тому, что потеряли написанный вручную код?

Только очень редко. Время от времени вы забываете удалить «сгенерированный» маркерный комментарий, и ваш метод блокируется при регенерации модели.

(Полагаю, если бы это было серьезной проблемой, вы могли бы изменить генератор EMF, чтобы всегда делать резервную копию дерева исходных текстов перед объединением изменений.)

Наверное, самым раздражающим было то, что сгенерированный код нужно было отформатировать. К сожалению, форматировщик кода Eclipse довольно груб, но если вы переформатируете вручную, Ваши изменения форматирования будут засорены при следующей регенерации. Но это просто раздражает ... не то, что стоит прыгать через обручи, чтобы избежать.

Был ли когда-нибудь код в необслуживаемом состоянии?

Неа. Не когда-либо.


Чтение ответа consta_a напоминает мне, что я всегда проверял свои сгенерированные EMF-классы в управлении версиями. Это лучший способ избежать потери правок в долгосрочной перспективе.


Обновление в 2018 году: 2 проекта EMF, о которых я говорил, произошли до 2008 года. С тех пор в мире EMF все могло измениться. Я не отслеживал.

0 голосов
/ 14 октября 2011

Я подтверждаю ответ Стивена С. В нашем случае мы обрабатываем около 120 классов в нашей модели, что означает 120 интерфейсов + 120 классов реализации + бесчисленное множество классов редактирования, и регенерация проходит достаточно хорошо (если бы мы только могли легко сгенерировать сгенерированные классы какмы хотим (^ _ ^))

Совет. Если вы боитесь потерять какой-то код, созданный вручную, лучше всего хранить ваш код в хранилище.Каждый раз, когда вы вносите изменения, вы можете легко сравнить с предыдущей версией и посмотреть, что изменилось.

...