Comments 20
чего только не придумают люди, лишь бы не использовать Ruby
А причем тут "не использовать Ruby" и вообще Ruby?
да, дело в том, что смотрю я на примеры кодогенерации и вижу давно реализованные в RoR вещи, простые интуитивные кодогенераторы.
Это так, к слову, холивар не собираюсь разжигать.
Если незнаком с Ruby - советую почитать ради интереса, я сам был сильно удивлен, когда первый раз увидел фишки "кодогенерации" в Ruby.
Это так, к слову, холивар не собираюсь разжигать.
Если незнаком с Ruby - советую почитать ради интереса, я сам был сильно удивлен, когда первый раз увидел фишки "кодогенерации" в Ruby.
как раз руби (точнее рельсы) и реализуют зачастую кодогенерацию.
Прошу меня извинить, что вот я уже на протяжении двух статей докапываюсь к автору, просто я не согласен с его мнением. Дизайн паттерны http://en.wikipedia.org/wiki/Design_patt…(computer_science) заслуживают отдельной ветки, и они не совсем связаны с кодогенерацией.
Мне просто не приятно как разработчику читать такие статьи, когда говориться не зная про что. Чтобы вы не приняли мои слова за пустоту, постараюсь вам объяснить. Я разработчик ПО для ОПСОСов. Одной из моих задач является создание сценариев поведения при звонках, это обработка биллинга, разрешение абоненту звонить/получать и отправлять другие виды траффика. Все сценарии выглядят однотипно, в виде блоков. Блоки это обращение к разным системам за информацией. То есть легче написать приложение, куда выносишь эти блоки граффически, делаешь между ними связи и вперёд, генеришь нужный код, потом его компилишь.
А теперь вернёмся к этой статье.
Кодогенерация по большому счёту создание кода, который схож между собой, но, например, последовательность его разная, или разные стуктуры данных (например код для каждой таблицы в базе данных со своими полями). Вот для этого используется кодогенерация, чтобы не писать почти одно и тоже тысячу раз, а позволить это делать программе.
Автор же в этой статье пытается всунуть Дизайн паттерны, которые имею совсем другой смысл, и не связаны с кодогенерацией. Дизайн паттерны указывают на стиль написания вашего кода, но они никогда не заменяют кодогенерацию или как то связаны с ней, наоборот, в кодогенерации сгенерированный код может быть по какому-то из шаблонов, но рассматривать все стили программирования чтобы объяснить кодогенерацию это бред.
Кто хочет разобраться побольше с Дизайн паттернами советую посмотреть на Spring.NET(http://www.springframework.net).
Возвращаясь к статье, хочу сказать, нет, она в приципе не плохая, ну конечно неполно написано, но в целом нормально, но она не по адресу.
Мне просто не приятно как разработчику читать такие статьи, когда говориться не зная про что. Чтобы вы не приняли мои слова за пустоту, постараюсь вам объяснить. Я разработчик ПО для ОПСОСов. Одной из моих задач является создание сценариев поведения при звонках, это обработка биллинга, разрешение абоненту звонить/получать и отправлять другие виды траффика. Все сценарии выглядят однотипно, в виде блоков. Блоки это обращение к разным системам за информацией. То есть легче написать приложение, куда выносишь эти блоки граффически, делаешь между ними связи и вперёд, генеришь нужный код, потом его компилишь.
А теперь вернёмся к этой статье.
Кодогенерация по большому счёту создание кода, который схож между собой, но, например, последовательность его разная, или разные стуктуры данных (например код для каждой таблицы в базе данных со своими полями). Вот для этого используется кодогенерация, чтобы не писать почти одно и тоже тысячу раз, а позволить это делать программе.
Автор же в этой статье пытается всунуть Дизайн паттерны, которые имею совсем другой смысл, и не связаны с кодогенерацией. Дизайн паттерны указывают на стиль написания вашего кода, но они никогда не заменяют кодогенерацию или как то связаны с ней, наоборот, в кодогенерации сгенерированный код может быть по какому-то из шаблонов, но рассматривать все стили программирования чтобы объяснить кодогенерацию это бред.
Кто хочет разобраться побольше с Дизайн паттернами советую посмотреть на Spring.NET(http://www.springframework.net).
Возвращаясь к статье, хочу сказать, нет, она в приципе не плохая, ну конечно неполно написано, но в целом нормально, но она не по адресу.
По-вашему многоуровневая абстракция - паттерн?)
http://en.wikipedia.org/wiki/Factory_met… и не важно как вы это называете
Прошу прощенья, туплю
В комментариях часто упоминают Ruby, там одна из фишек языка как раз и заключается в кодогеннерации. RoR просто её умело использует.
В качестве примеров систем кодогенерации можно привести ERWin (модель Бд -> приложение на VB) и Rational Rose (модель класов -> c++, java).
Вот никак в толк не возьму, если у вас есть некие метаданные для некоего кодогенератора, то чего бы сразу и не написать прогу, которая по этим данным и работает без всякой кодогенерации? Медленно? Так медленно только на очень ограниченном куске программы — его отдельно написать. Лежат себе в базе данные, а прога их читает и отрабатывает. Кодогенераторы иногда используются чтобы сбросить структуру данных в исходник программы и предоставить программисту готовые переменные с названиями по этим данным. Все это глючит всегда и у всех и используется только в одну сторону — любое изменение в программе и прощай кодогенерация. Правильные пацаны кодогенераторов не используют.
Sign up to leave a comment.
Многоуровневая абстракция