codegen?

[singalen]

Мне стыдно у вас такое спрашивать... но я всё равно спрошу.

Зачем нужна кодогенерация?
Разве это не автоматизированный копи-пейст?
Ну, исключая случаи, выходящие за пределы возможностей инструмента: там, сериализация в C++ или сгенерировать Data Object по XML-ю.

И просьбочка: если видите что-то полезное в моём аглицком блоге про .NET, немного Java, WiX, OOP, OOD и немного всё остальное - поставьте на него ссылку, пожалуйста.

Comments

[singalen]

О кодогенерации "вообще". Я понимаю, широкая тема, и "случаи бывают разные".
Да, луче автоматически, но ещё лучше написать единожды.

В целом, моя мысль та же - либо дефект/неспособность платформы, либо программиста.

О статье.
"избавиться от нее штатными средствами ООП не удается" - хи-хи.
"отсутствием в языках .NET generic" - уже неактуально. Дженерики нас спасут.
Пройдёмся по примерам:
* "типизированных коллекций" - generics уже есть;
* "бизнес-классов" - это и есть Data Objects. Поведение всё равно не сгенерируешь.
* "прокси для удаленных объектов" - это и есть сериализация. Если в платформе нет reflection-а. Пример в статье - сериализация в XML, мнэ, удивляет.

Кодогенерация в typed datasets в .NET меня убивает. А есть люди, которые её хвалят - удобно, говорят, к хранимым процедурам обращаться... А я и процедуры не люблю, лишние сущности.

[aamonster.livejournal.com]

Ну вот задачка, которую мне довелось решать.
- Дельфи (насколько я могу судить, использование C# или еще какого .net языка ситуацию принципиально не меняет).
- Предопределенный формат файла (лежат поля данных в определенном порядке)
- Есть несколько версий формата файла (различаются по первому полю version)
- Значения полей соответствуют полям или свойствам некоторой формы (включая массивы и биты для boolean-полей).

- Решение "в лоб" #1: написать чтение/запись для каждой версии.
- Решение "в лоб" #2: создать тип данных вроде struct (по типу на каждую версию), написать процедуры переписывания данных из полей/свойств в эту структуру (для каждой версии) и сериализовать ее как массив байт.
- Решение "в духе ООП": создать классы-обвязки для основных типов полей/свойств (с общим предком), создать для каждой версии объект-контейнер (который хранит ссылки на все сериализуемые поля/методы в нужном порядке), в нужный момент создавать такой объект и дергать его методы Load/Save/Import
- Решение, которое выбрал я:
-- Создать для каждой из версий файл, в котором все сериализуемые поля/свойства записаны как строки типа int Form1.Property1
-- Генерить простой код сериализации по этим файлам и включать его директивой include в качестве процедуры.

По сути похоже на ООП-метод, но явно проще.

[singalen]

Я бы сделал маппинги вроде гибернейтовских, для каждой версии. Подгружал бы соответствующий маппинг и заполнял поля объекта через reflection.

[aamonster.livejournal.com]

Если я правильно понял, это как раз примерно соответствует предпоследнему (ООП) варианту? (можно подробнее про гибернейтовские маппинги? сойдет ссылка)
Вот только:
1. reflection под рукой не было.
2. кодогенерация в данном случае была _очень_ простой и порождала столь же простой (и достаточно оптимальный - нет нужды раскручивать reflection на каждое сериализуемое поле) код.

Ну и главный вопрос: будет ли при этом описание формата файла не сложнее такого:
--- cut ---
integer TrackBarBrightness.Position
integer TrackBarContrast.Position
integer TrackBarGamma.Position
integer TrackBarScaleX.Position
integer TrackBarScaleY.Position
integer TrackBarVolume.Position
integer TrackBarGain.Position
BeginFlags
Bit SpeedButtonSpectrum.Down
Bit SpeedButtonCurve.Down
Bit SpeedButtonEdge.Down
Bit SpeedButtonFilter.Down
Bit SpeedButtonMirror.Down
Bit SpeedButtonUpsideDown.Down
Bit SpeedButtonMicro.Down
EndFlags
integer Selection1
integer Selection2
integer SpectrumPos
--- cut ---
(что немаловажно, часть integer'ов - поля, часть - свойства, причем не всегда свойства непосредственно сериализуемого объекта)

[singalen]

http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html, разделы 1.2.2, 1.3.1.

Описание могло бы быть в XML или текстом вроде:
---
Version 1.1
Class Form1
field TrackBarBrightness.Position=BrightnessValue
...
---
Да, сам код будет посложнее, но он будет единым и не будет усложнять процедуру сборки продукта.

[aamonster.livejournal.com]

Дык не осложнял... В дельфовской проге у меня было всего 3 версии файла - так что мне понадобилось три раза прогнать генерацию, и все. А так - выткается в make-файл (в общем случае) или в build rules (для visual studio) правило для обработки файлов-шаблонов (ну там, что lex-файлы надо скармливать lex'у), и все.

Да, что я не понял из описания гибернейта: оно генерит оптимальный код или просто работает с объектами через reflection? Так-то, кажется, имеем ровно ту же кодогенерацию, но в рантайме...

[singalen]

Вы уже защищаете генерацию? :)

Гибернейт, да, работает через reflection. Но он оптимизирован, так что генерит всё, что надо, и даже больше.

[aamonster.livejournal.com]

Выступаю в роли адвоката дьявола :-).

Да, а "оптимизирован" - в смысле, когда мы грузим мапу, она один раз получает ссылки на требуемые поля/методы свойств через reflection, а дальше уже работает напрямую?

На самом деле, грань между кодогенерацией и другими подходами достаточно зыбкая. Можно ведь и генерацию объекта по XML-описанию считать кодогенерацией =).

P.S. А уж что считать кодогенерацией в функциональных языках - просто непонятно =)