Как стать автором
Обновить

Комментарии 101

Хорошее начало. Надеюсь, получится интересный и полезный цикл статей. Удачи в написании! :)
Спасибо :-)
НЛО прилетело и опубликовало эту надпись здесь
мне кажется, первые две проблемы вполне решаются использованием примесей вместо множественного иерархического наследования. так например сделано в Ruby, CLOS.

третья проблема - макры вообще и модные нынче DSL в частности.

а вообще интересно посмотреть на кодогенерацию в php. серьезно, без сарказма)
В Питоне есть Duck's Typing - просто и ясно. И не надо путаться с этими всеми интерфейсами и полиморфностями.
Просто когда у вас простые классы. Когда определенная функциональность начинает встречаться часто, проще задать ее в QuackableMixin, например ( раз уж мы про уток ;-)
Может в названии статьи следует указать, что это предисловие.
трезвые и взвешанные оценки ооп-подхода, ждем продолжения. (:
Начало цикла статей заинтриговало. Хотелось бы, чтобы в статьях так же "прошлись" и по недостаткам кодогенерации. Прочитал комментарии выше и стало интересно, есть ли связь между эффективностью кодогенерации и используемым языком. Например, колдогенерация для Java и Ruby.
ну вот попробуйте написать метапрограмму на C и на Lisp, там видно будет)
Хм, очень интересно что же будет дальше!
Статья хорошая, но идею КОДОГЕНЕРАЦИИ так даже и не приоткрыли (

PS После этой статьи я чувствую себя как Нео перед выбором красной или синей таблетки.
Зато смог заинтриговать :-)
определения ООП из википедии в последнее время здесь повторяются чуть ли не каждый день.
КУ
Ага, заинтриговал )

PS: Думаю, авторы полиморфных вирусов тоже могут что-то интересное в тему рассказать, относящееся к кодогенерации, только асма на асме (:
Начало хорошее. Респект! Ждем-с следующих выпусков.
Очень интересно! и главное вроде понятно всё написано даже тому, кто не понимал, о чем речь идет речь, читая умные книги.
Кстати, в предложении "Но если определенное изменение изменение надо внести в ..." 2 раза слово "изменение".
Спасибо)
я бы все таки разделил сложность и рутину. Как использовать кодогенерацию для рутины всем понятно, а вот про сложность хотелось бы услышать.
Есть множество ситуаций, когда для выполнения сложной задачи можно либо написать пусть не очень много, но сложного кода (сложно тестировать, поддерживать, изменять), а можно сгенерировать много простого, который "спрессует" в себе все иерархии наследования, сложности взаимодействия, и т.д.

Отлаживать просто, работает быстро, изменения делать просто - перегенерировал, и все.
Пример - ORM'ы. Можно использовать сложные библиотеки, а можно сгенерировать DAL-слой, состоящий из элементарного кода.
ну насчет простоты поддержки ещё не факт, если конечно вы хотите сохранить возможность перегенерации в любой момент, но в целом направление мыслей понятно, надо будет подумать.
подумал, согласен. будет проще отлаживать и можно добавить аспектно-ориентированных примочек на этапе генерации, что не скажется на производительности. В таком случае хотелось бы увидеть от автора список примеров где это может пригодится, чтобы подумать куда это ещё можно применить.
Интересная тема затронута, ждемс продолжения (у проблемы есть решение?).

Вот за что я люблю PHP, так это как раз за отсутствие монстроподобных иерархий классов в родных структурах языка. Хотя истории свойственно повторяться и некоторые фреймворки пытаются восполнить этот "недостаток" и плодят обширные классы, из которых от силы используется процентов 20...

Господа из Zend'да, я конечно понимаю, что Вам виднее, но помимо out of box функциональности есть еще производительность и удобство!
Это был крик души, грустно смотреть, как огромные кодерские мощности направляются на создание очередного монстра... А ведь так хочется скорости, легкости и прозрачности...
Мне кажется если убирать "всё лишнее" то, в конце концов, язык будет пригоден только для создания несложной домашней странички. Т.е. это равносильно шагу назад. Размещение классов в таких вот "монстроподобных иерархиях", на мой взгляд, как раз позволяет всё более-менее упорядочить, создать своеобразную инкапсуляцию для понимания. Например, изучая Java, я мог совсем ничего не знать о чём-то, что мне не нужно (например как писать программы для мобил или работаь со звуком), и вполне нормально работать с тем, что знаю. Когда же понадобится, что-то ещё - вот оно, лежит в таком-то пакете - бери да изучай.

Аналогично и со сторонними библиотеками - если вам не нужна вся мощь фреймворка и достаточно одного-двух классов, то почему бы не написать их самостоятельно?? Но если же проект требует чего-то большего, то всё же будет проще изучить стороннюю библиотеку, чем писать свой собственный велосипед, с бронёй, пушкой и гусеничным приводом.
заинтриговали ))
Очень странное начало цикла.
1) "А ведь такое большое число методов и свойств несет в себе сложность. Во-первых, для программиста. Когда он набирает имя объекта и нажимает точку, то открываются огромные списки, среди которых сложно найти то, что надо. Во-вторых это все занимает память и процессорное время."
Бедный программист, столько функций - так сложно выбрать то, что он хочет. Не понятно что именно занимает память и процессорное время? Показ списка функций...
2) "Получается очень много классов. Программист, который работает с такими системами, должен держать в голове много информации при построении и сопровождении данной системы"
Программист конечно должен представлять как реализовано все на более низких уровнях, однако, если он не разработчик библиотек низкого уровня, то держать в голове всю иерархию, вплоть до ассемлерных вызовов ему не зачем
3) "В таких ситуациях часто используется «копи-паст». Но если определенное изменение изменение надо внести в массу этих же однообразных страниц, то опять появляется рутинная работа. Но строить абстрактные модели по таким мелким поводам никто не будет, ведь классы нуждаются в проектировании."
Такое впечатление, что в проекте участвует только один человек, если надо делать кучу раз копи-паст, то это свидетельствует о неправильно разработанной архитектуре программы
4) "Сложно представить проект, который не использовал бы какой-либо библиотеки классов/функций. Программист не просто вынужден изучать эти библиотеки, но и должен следовать их правилам и абстракциям, что опять же добавляет сложность проекту и вынуждает программиста держать в голове большой объем информации."
Рассматривайте любую библиотеку как черный ящик - и твердо следуйте его правилам. Ваш вывод совершенно не понятен
НЛО прилетело и опубликовало эту надпись здесь
1) по моему имеется ввиду "занимает память и процессорное время сам объект созданный во время работы приложения на сервере".
если таких объектов создается много то начинаются проблемы с памятью.
конечно же никто не мешает программисту скомпоновать отдельный класс GrifViewLight взяв только нужны функции.
Не слишком ли много работы будет, если для каждой задачи делать GridViewXXX? И опять же - повторение трудов тех, кто делал оригинальный GridView.
тут нужно смотреть каких именно объектов создается больше. всмысле оптимизировать только классы которые жрут память. я не думаю что придется делать light класс для каждого класса
НЛО прилетело и опубликовало эту надпись здесь
я не знаю как там в .net сам пишу на php. просто выразил свое мнение таким образом.
автор пишет об абстрактном языке, обещая показывать примеры на php
исходя из этого не понятно в каком случае возникают проблемы с памятью и процессорным временем.
Если мы говорим о сложных серверных приложениях, то их пока на интрепретируемом языке никто не пишет, а в компилируемых языках я таких проблем вроде не видел. Если мы говорим о веб-языках, то обычно задача сгенерировать страницу за наиболее короткое время, сложные вычисления выносятся на за веб-сервер.
А насчет этого - спорно. PHP потенциально подходит для проектов любой сложности. Другое дело - как его использовать.
Напишите мне файловую систему на php или веб-сервер.
Правильным ответом было бы написание того, что для каждой области применения есть свой набор языков, в которой данные языки обладают наилучшими характеристиками для человека (заказчика или разработчика), такими характеристиками являются, например, быстрота разработки, скорость работы конечного кода, удобность поддержки и т.д.
ну тем не менее есть огромные классы которых нужно опасаться. у меня уже была проблема такого плана. при посещаемость >20000 возникла проблема с памятью. я уменьшил размеры часто вызываемых классов и все ок. Сервер держит около 50000 в день.
имеел ввиду, что сервер на данный момент справляется с 50000 посещяемостью
Сейчас положение таково, что собака после того как сходит в туалет на лужайку - вызывает экскаватор чтобы закопать результаты своего труда, а это не правильно.
пример приведите
Зачем тут пример? Если вы хотите добавить в своей проект какую-то вещь - вы ищите библиотеку/класс для этой цели. А класс не только может отвечать вашим требованиям, но и намного превосходить их, делая много лишней работы (которая для вашего случая не нужна) тратя процессорное время и память. Если это один класс - хорошо. Но ведь так не бывает?! Обычно используются цеые фреймворки и библиотеки классов, каждый из которых несет в себе лишнюю сложность. А если программист начнет еще разбираться в таком кода - то он явно будет далеко от его конкретной задачи. Таково положение дел и оно совсем не идеально.
Кодогенерация - не решение таких проблем.
Ну для этого я и начал писать эту статью. Современная кодогенерация - очень интересная штука.
для компилируемых языков я не вижу проблем
для интерпретируемых...напишите тест, то что вы называете временем будет конечно тратится на загрузку кода (размера) файла библиотеки.
Но это можно преодолеть используя кеши
В нынешнее время работа программиста по созданию велосипеда стоит дороже железа. И, еще, больша просьба не писать про высоконагруженные приложения.

Если архитектура правильная, то очень быстро локализуется место утечки и исправляеться в момент ока.
Для меня намного важнее не нагрузка (хотя этот фактор тоже нельзя исключать) а сложность. Сложность вредна - факт.
Я думаю кодогенерацию в PHP можно рассмотреть на примере Symfony framework. Действительно, очень удобно задавать параметры в yml-файлах вместо рутинного написания одного и того же кода. Производительность? Ну-во первых есть кэширование, во вторых сто раз уж было сказано что удобство в сопровождении и логичность структуры гораздо важней.
Не возникает при этом проблемы xml data hell? У меня на прошлой работе, помнится, все прогеры плевались от огромного количества xml файлов с настройками.
Именно поэтому вместо XMl рекомендуется использовать формат YML. http://yaml.org/

Я при свосем не понимаю почему на сайте Propel'а все примеры в XML
Чем-то похоже на HTML DTD. Спасибо за ссылку - почитаю на досуге!
Я раньше что-то слышал об этом формате, но руки не доходили познакомиться.
НЛО прилетело и опубликовало эту надпись здесь
Я бы предпочел исходить из задачи

Как для простого блога/блокнота нет смысла использовать монстрообразные с 10-ти ступенчатым наследованием классы так и для большой меж-серверной распределенной системы нет смысла писать все с 0, до пенсии можно писать.

Всему свое место
"Чем проще проект, тем он качественнее."


Чувствую запах лапши. PHP-лапши.

Я примерно представляю стиль кода, в котором пишут приверженцы такого "метода" - "что б все просто". Посмотрите внутрь того же, скажем, WP :)

Нет, конечно, это работает. Но без особой (!!!) мотивации я не полезу разбираться в этом хаосе.

Хотя иногда так хочется для того же WP написать пару модулей. Или поработать, скажем, над его интеграцией в SOA-стиле. Каждый раз моего порыва хватает на 15 минут, не больше. :)

Конечно, я не гуру-разработчик. Но разве бородатые старики правят миром?
Простота бывает разной. Для меня хороший и простой код - это:

$user = $DB->users->select('id=5');
$user->last_activity = time();
$user->update();
НЛО прилетело и опубликовало эту надпись здесь
Ваш код сложнее, потому что вам приходится держать в голове принципы работы MySQL. А это, как было оговорено автором,— враг вашего проекта. Ничего страшного, что одна SQL команда заменяется 3 функциями и двумя SQL'ями — ООП подход придуман для упрощения развития больших проектов, а не для оптимизации работы приложения.
НЛО прилетело и опубликовало эту надпись здесь
Ваш вариант скорее похож на выполняемый код сервера, а пример mdevils — на то, как он должен выглядеть в проекте :)
в проекте тогда он должен выглядеть так =):

$user->update($DB, $id, time());
Это по-вашему интуитивно понятно?)
Тогда уж
$user->set_last_activity( time() )
ну да, $db и $id скорее всего внутри скрыто. тогда еще time() убрать - ведь устанавливают активное время по текущему и получится:

$user->set_last_activity()
:) Нет, Вы определенно шутите :)))) Для меня это - отличное начало дня.

Во фрагменте кода - при чем тут $DB ?
Что - создавая юзера, мы не позаботились о том, с какой БД мы работаем? :)))))
Про то, что обновлять какие-то другие атрибуты, кроме некоего времени, Вы, похоже, не подумали...

Вот это - и есть PHP-лапша. В чистом виде :)))
Предположим, вы решили вынести данные по активности пользователя, в отдельную таблицу, ну или сделать "ручками" партишенинг таблицы, что вы будете делать в данном случае?
НЛО прилетело и опубликовало эту надпись здесь
А, ясно, я неправильно понял.
В таком случае, конечно, интересно, как будет поддерживаться актуальность кода при изменении, например, структуры БД.
Но это, я так понимаю, больше к автору статьи вопрос, и его пока рано поднимать.
НЛО прилетело и опубликовало эту надпись здесь
Это не хороший и простой код, а п-дец.
Посмотрите как то же самое сделано на Rails.
Извините, я последние минут 40 убил на чтобы найти "как тоже самое сделано на Rails", успел прочитать по то как станет прекрасна моя жизнь, когда я начну жить в стиле RoR.
Но при этом не нашел ни одной модели пользователя.
Итак мне надо обновить last_activity у некоторого пользователя, что же мне надо сделать на RoR?
Хотя возможно "Rubi On Rails настолько умен гибок и сексуален, что сам знает когда что надо обновить, вам больше не надо писать код, вам надо просто сидеть и наслаждаться мощью RoR- величайшего изобретения человечества после колеса."
Да приблизительно так же там сделано. Как-то так (точно не помню)
user = Users.find(5)
user.last_activity = Time.new
user.save
логика та же, отсутсвуют только эти безумные знаки доллара и стрелочки. Ну, и сущность db отсутствует.
т.е. вам просто не нравиться синтаксис языка
и в принципе "п-ц" код не сильно отличается от Rails?
или просто php код это априори п-ц потому что вам @@ симпатичнее чем $
Ну, автор первоначального сообщения не я, поэтому претензии не ко мне. Но что касается лично меня, то да, синтаксис пхп мне тоже не нравится :). "Тоже" в том смысле, что мне вообще в пхп ничего не нравится. Язык не имеющий положительных качеств :).
@@ против $ - конечно симпатичнее. Переменные класса используются на порядок реже, чем локальные переменные. Хотя лично я бы предпочёл просто описывать переменные (примерно как в перле) и полное отсутствие префиксов.
А про пример - самое главное забыл :). Это _весь_ код, который должен написать пользователь. Вообще. То есть ни про User, ни про базу данных не надо писать ничего. Ну, разве, что указать парамтры бд в конфиге.
>Это _весь_ код, который должен написать пользователь
db-модель в PHP тоже пишется не чаще раза на проект, а если все-таки пользоваться code reuse - так вообще раз в жизнь.
Убил еще 40 минут и 100Mb траффика на скачивание книжек по RoR.
В Agile Web Developer With Rails, подробненько расписано как создать свою модель пользователя, как ее на каждый чих дергать из базы, из этого следует что либо авторы книги- любители изобретать велосипеды, либо вы лукавите, когда говорите, что это весь код, который должен написать пользователь.
Я все в тайне надеялся, что есть какая-то моделька у которой можно прописать в конфиге что-то из серии: OpenID- вкл, ЗапомнитьМеня- в куки с именем таким-то, профиль пользователя- модель такая-то.
Нет сидим, пишем и потеем. При том я так и не смог найти на оф.сайте сколь либо приемлемого описания служебных моделей фреймворка (наподобие PECL/PEAR/ZF), я даже не вполне уверен, что они существуют, при этом если что-то и удается найти, оно обыкновенно документировано в стиле "как легко и просто сделать это с Ruby WOW!".
Что касаемо синтаксиса, от php я и сам не в восторге, когда я после C# попытался в первый на нем написать что-то "объектно ориетированное", меня потом три дня била дрожь, я плакал и звал маму, но в принципе, там все вполне логично, уродливо но понятно. От Руби у меня остается стойкое ощущение, что люди решили придумать ЯП "чтобы не как у других" (с блекджеком и шлюхами), при этом не разу не озаботившись логикой. И главное, я-то уже было надеялся, что разум победил и, за исключениям отдельных маргиналов, все будут пользовать нормальный c-образный синтаксис, и вот: снова здрасте, begin-end.
Если я где-то налажал и модели с документацией все-таки существуют, буду крайне благодарен за исправления, так как на самом деле just for fun, хочется поработать на web с чем-то помимо php.
P.S. Извините, за излишнюю многословность.
>либо вы лукавите, когда говорите, что это весь код, который должен написать пользователь.
Тут, наверное, возникло некоторое недопонимание :). Мой ответ был на пример пхп-шного кода, не более. _Там_ действительно ничего не надо писать. $DB вообще отсутствует, а Users нам самим описывать не надо, за исключением двух строчек. ОРМ - автоматический.
>моделька у которой можно прописать в конфиге что-то из серии: OpenID- вкл, ЗапомнитьМеня- в куки с именем таким-то, профиль пользователя- модель такая-то.
Ну-у-у! Опять путаница. Рельсы - это не SMS/SMF или как их там. Это фреймворк довольно таки низкоуровневый всё-таки. Берущий на себя довольно много рутины. Но не всю, конечно. Но плагинов, вроде, уже изрядно к нему написали, если поискать, может что подходящее и найдётся.
>я даже не вполне уверен, что они существуют
Угу. Я не вполне понял, что именно вы имели в виду, но, похоже, именно этого там и нету :). И с документацией довольно фигово :(. Ну, вот так вот...
>От Руби у меня остается стойкое ощущение, что люди решили придумать ЯП "чтобы не как у других" (с блекджеком и шлюхами), при этом не разу не озаботившись логикой.
Гм. У меня ровно противоположное впечатление. Диаметрально. В Руби есть идея, логика и внутренняя красота. "Не как у других" - не согласен. Очень чётко прослеживается откуда у чего уши растут и видно, что взято не бездумным тупым копированием, а после долгого и тщательного обдумывания. Последовательное ОО - круче, навеное только в смолтоке, вменяемые перловые регэкспы (за одни только издевательства над пользователями с регэкспами пейсатели пхп заслуживают мучительной смерти), причём без без перловых заскоков. Лямбды - понятно откуда. def перед методами - видимо из питона. Откуда взялись блоки - вот этих языков я, к сожалению, не встречал, но идея - чудо.
А вот пхп - это как раз язык без идеи. Оно и понятно - это был шаблонизатор студента, не осилившего перл и решившего написать его жалкое подобие. А потом туда навалили и блекджек и шлюх... Понять невозможно, можно только зазубрить.
>снова здрасте, begin-end
:) и что мешает скобочками пользоваться? Они ведь там есть. В большинстве случаев они вполне взаимозаменяемы. Ни и довольно логично они сделаны. Глядите, можно написать и так:
if (somewhat()) {
do_something()
} else {
do_something_else()
}
и так:
if somewhat?
do_something
else
do_something_else
end
второй вариант выглядит не хуже первого, а если присмотреться, то в чём-то даже и "лучше" :) При том, что я последовательный поклонник сишного синтаксиса :). От алгола-паскакаля предлагаемый вариант всё-таки отличается как небо от земли :).
>и модели с документацией все-таки существуют
Фиг его знает. Я ведь не настоящий сварщик, я маску на стройке нашёл :). На руби теперь пишу все свои рутинные скрипты (переехал с перла и баша), а к рельсам только присматриваюсь.
Собственно db в данном случае никак не является сущьность.
1. Многоуровневое наследование.
...Во-вторых это все занимает память и процессорное время.

Это очень спорное утверждение. Вы должны понимать, что добавление методов к объекту не увеличивает размер его экземпляра. На размер экземпляра сказывается только количиство данных. Но при грамотном проектировании класса неиспользуемые данные тоже не будут инициализированны.
Причём добавление данных к объекту увеличивает только размер экземпляра в памяти, но дополнительное процессорное время не отнимает. Правда, я говорю про компилируемые языки, как обстоит дело в интерпретируемых я не знаю.
Ява и .NET-программисты, наверное, сейчас залезли под столы и плачут горючими слезами. Сколько же им классов, бедным, надо в голове держать! Сколько же памяти все это отжирает! О, а абстракции какие многоуровневые, жуть.

Соглашусь с AlexBruce. В 90% случаев кодогенерация - это лапша, которую придумывают от незнания базовых вещей.
:) Тут еще такое дело, что чем дальше в лес, тем в большей степени оставшиеся %10 обречены на отсутствие сообществ разработчиков вокруг себя.

Взять тот же WP. Я только что обломался на очередной попытке понять его. Честное слово. Будь он сделан (нет, не обязательно нативный MVC) хотя бы как некий компромисс, в стиле Drupal , или Xoops (хотя, второму, конечно, гибкости не хватает) - дело другое.

Но тратить свою жизнь на поддержание комплексов неполноценности "разработчиков", которые (замечено мной), часто даже нормальных шаблонных систем не применяют - увольте меня. :))

В общем, здравствуй, питон...
НЛО прилетело и опубликовало эту надпись здесь
Перенес в отдельный блог ;-)
Начало конечно многообещающее, но это предисловие непонятно к чему.
Хотелось бы обратить внимание автора на то, что на ООП мир не заканчивается - подход АОП (аспектно-ориентированное программирование) обеспечивает гораздо меньшую связанность классов и гораздо большую инкапсуляцию. Рассматривать ООП, зная о более правильных вещах, уже немного несвоевременно...
Со многими высказываниями в статье поспорил бы. Но в целом заинтриговало. Буду ждать продолжения - хочу посмотреть, во что всё выльется.
НЛО прилетело и опубликовало эту надпись здесь
> 1. А ведь такое большое число методов и свойств несет в себе сложность. Во-первых, для программиста. Когда он набирает имя объекта и нажимает точку, то открываются огромные списки, среди которых сложно найти то, что надо. Во-вторых это все занимает память и процессорное время.

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

> 2. Получается очень много классов. Программист, который работает с такими системами, должен держать в голове много информации при построении и сопровождении данной системы. Более того, для согласования абстракций часто приходится использовать неоптимальные методы.

Опять с точностью до обратного. Да, в машине есть руль и 2-3 педали, но это не значит что 100 км проще пройти пешком, так ведь? Про согласование абстракций - тоже как-то все перевернуто с ног на голову. Хорошая абстракция упрощает жизнь.

> 3. Например, создание однообразных страниц, где каждая следующая страница отличается от предыдущей лишь источником или представлением данных. В таких ситуациях часто используется «копи-паст».

Вы привели пример плохого дизайна и плохого стиля кодирования. Ответ лишь один - так делать не надо, более того, ОО подталкивает к code reuse.

Ну и так можно долго продолжать. Резюме таково - хороший класс - а то и целая библиотека - должна делать что-то одно и делать хорошо. Если это не так - это плохой класс и использовать его не надо. Надо брать другой класс. Но это не повод для выводов, сделанных Вами.
Кодогенерация в целом делает тоже, что делает и любой другой подход - OO, AOP - добавьте свое. Иногда внутри применяется кодогенерация, иногда динамические методы (посмотрите разные реализации AOP). Динамические методы (простейший пример - Dynamic proxy в Java) на мой взгляд элегантнее и гораздо проще в поддержке, но сложнее в отладке.
Про кодогенерацию есть одно устойчивое мнение, которого и я придерживаюсь...
Если какой-то код можно сгенерировать автоматически, значит этот код не нужен, и несложно найти способ, как без него можно обойтись.
Возможно это мнение ошибочно... кто-то может доказать обратное?
НЛО прилетело и опубликовало эту надпись здесь
Согласен насчет "доказать обратное", я выразил свою мысль несколько жестковато, признаю. Попробую раскрыть мысль корректнее.

Имелось в виду следующее - кто-то может привести хоть_один_пример, когда применяется кодогенерация, и без этого сгенерированного кода нельзя обойтись для решения этой же задачи. Это и будет доказательством. Хоть один пример привести ведь несложно?

А насчет Вашего примера-утверждения "код нужно генерировать автоматически"... доказать обратное крайне просто. А именно. Чтобы генерировать код программы автоматом, нужно иметь генератор кода. Генератор кода - это тоже программа, которая также имеет свой код. Если Ваше утверждение про "по-другому это сделать нельзя" верно, тогда и этот код кодогенератора тоже должен быть сгенерирован автоматически, уже другим кодогенератором. Получаем зацикливание. Вывод - если следовать Вашему утверждению, никакую программу сделать невозможно. Конечно, остается еще вариант с НЛО, которое дало миру первичный кодогенератор... но это уже другая тема.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за ссылку, для меня она - самое полезное в данном топике.

P.S. - я как раз сторонник использования метаданных, а кодогенерацией перестал баловаться где-то в 2002 году.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
многоуровневое наследование - это пример плохой декомпозиции. почитай про примеси, штрихи, про интерфейсы, в конце концов.
Самое полезное на это тему - Мартин Фаулер "Рефакторинг"
Ну еще паттерны "Банды четырех"
Очень занимательное начало автору - респект
Жду продолжения
Почитал. Понравилось. Продолжайте ;-).
1. Многоуровневое наследование.

Если вам кажется неоправданным излишняя навороченность некоторых компонентов .NET и прочих подобных монстров, то, я думаю, просто не стоит на них писать (-: Излишняя навороченность и "никому не нужные" возможности которых - не то чтобы недостаток, а скорее особенность. Просто скорость в рантайме принесли в жертву скорсоти разработки.

2. Многоуровневые абстракции.

Когда абстракция хорошая, программисту не нужно думать что под ней лежит. Для того абстракции и придумали.

3. Рутинная работа.

Удивительный у вас прогарммист (-: я бы с таким работать не стал - он сначала не хочет думать "по таким мелким поводам", а потом жалуется на рутинную работу, которую сам избрал вместо правильно спроектированной системы.

4. Библиотеки.

Нет, ну всё. Современное ракетостроение слишком сложно, слишком много надо знать и уметь. Надо с этим что-то делать.

Кодогенерация - хороший приём, но проблемы которые вы перечислили непосредственно к ней на мой взгляд не относятся. С нетерпением жду следующих статей, надеюсь они моё мнение опровергнут.
Можно было не напрягаться и по каждому пункту просто написать: "Сам дурак" ;)
я привык аргументировать свои мысли. особенно тут, где карма штука шаткая. Хотя в последнее время, похоже, и это не работет.
Интересное начало, во многом с Вами согласен. С нетерпением жду развития мысли :)
Тема отличная и лично для меня долгожданная.

Для сомневающихся хотел бы добавить, что кодогенерация и не подразумевает генерирование 100% рабочего приложения. В лучшем случае это его каркас, в худшем случае это, как в советском анекдоте, тот паровоз из которого методом молотка и зубила получается ракета. И спор о том нужно ее использовать или нет так же бесконечен и бессмысленен как спорт о том какя ОС лучше. ИМХО, использовать кодогенерацию НУЖНО для больших проектов (от 50 форм и более), ну или для кучи очень похожих проектов. Для мелких - лишние затраты.

Почему-то люди противопоставляют кодогенерацию архитектуре приложения. Это странно и не правильно. Сгенерированный код также должен согласовываться с какой-либо выбранной архитектурой.

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

Ну и вообще скучно как-то ручками писать проект, в котором почти для каждой сущности нужно прописывать бизнес объект, объект доступа к данным, грид, инпут-форму, основные действия над сущностью и т.д.

Вобщем ждемс конкретных рецептов!
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории