Это
21112175 сравнение как источник раздумий по шаблонам и их применению, о котором многие твердят.
Не будем рассматривать виртуального коня в вакууме, а возьмём конкретное применение — ось разработки - окна, ось продакшена — линуксы. Сервер приложений — котяра. Соответственно язык — java.
Читабельность кода — в приведённом шаблоне имеется раскраска текста. Это будет если для написания такого шаблона использовать специализированный редактор. Если этот шаблон поместить в код java – эта раскраска пропадёт, это будет простая строка , появятся дополнительные кавычки, плюсы для соединения при переносе строк. При наличии кавычек надо учитывать дублирование кавычек, или знак «\» соответственно читаемость падает в разы.
Учитывая, что skyANA, не является практикующим java-программистом, но смог прочитать и рефакторить код на чистой java, и что написанный им шаблон тоже надо суметь прочитать, даже при раскраске (не говоря о не раскрашенном варианте) — можно сделать вывод что аргумент с «плохой читабельностью» можно забыть.
Есть вариант — подготавливаем шаблон в отдельном редакторе с раскраской и переносим в код java -это куча действий, но только один раз, при создании, при исправлении — мало кто захочет этот путь повторять.
Храним шаблон в отдельном файле — редактируем спецредактором — наглядность , раскрашеность. Что с ним делать?
Вариант: файл храним в проекте. Как используем? В коде, где нужно его применить читаем файл. Файл текстовый прочитаем в StringBuilder, начнем менять «спецвставки» на нужные, т. е. начнём работать со строками, работа со строками, даже StringBuilder (поиск,вставка, замена) операция очень не быстрая — огромная потеря времени, если учесть что такой шаблон будет вызван 500+ раз… Пагинация сокращает до 50+ раз, но в любом случае необходим вариант полного отображения данных, т. е. вызов 500+ раз.
Есть вариант использовать Singleton загрузить этот файл один раз, в рантайме при старте вызвать компилятор , сформировать из этого шаблона класс, скомпилировать класс , загрузить его и вызывать… Оно того стоит? А если таких шаблонов по 5+ на каждую страницу?
Пусть будет отдельный файл/ы. Первоначально он обработан/ы в Singleton. Простому пользователю приспичило его править — т. е. мы даём права «простому пользователю» на доступ в папку сервера? Хорошо, не «простой пользователь» - а программист, он правит шаблон. Значит в проекте должен появиться механизм отслеживающий изменения версий шаблонов, что бы при изменении подхватить и скомпилировать. Оно того стоит?
Берём вариант текстовая строка в коде. Закрываем глаза на неудобство связанное с не раскрашенным текстом, используем предкомпилятор, который перед компиляцией сделает нужное. Ну будет работать быстро? Возможно, не известно что сгенерирует предкомпилятор… Есть выйгрыш? В чем? В читаемости? Маловероятный. В отладке? Если в чистом варианте ide сразу показывает все описки синтаксисе, то это же мы сможем понять только при запуске компиляции при работе предкомпилятора. Это увеличение времени разработки , да и при изменении/правки — тоже не мало времени уйдет. Вместо того чтоб исправлять ошибки при наборе — многократно запускать компиляцию. Опять таки «простой пользователь» не при делах.
Аргумент — простой пользователь может изменять шаблон.
В приведённом примере что может изменить пользователь? Добавить классы для расцветки? Ширины столбцов? Код основан на результатах работы хранимки — там много что вычислено именно в хранимке (точнее в селекте этой хранимки) благодаря чему много что удалось убрать из кода java. Если эту обработку перенести в java, то мало вероятно что кто-то сможет сделать такой шаблон как сделал skyANA, это будет кусок обыкновенного кода java. С кучей переменных, обработкой строк. Поместить текст хранимки в код? Это огромная строка , в коде будет не читабельна, править и проверять — дело долгое и не благодарное, в отличии от кода хранимки в предназначенном для этого ide. Да и «простой пользователь» который, который будет разбираться в sql коде и коде java - это уже программист.
Для того чтоб простой пользователь мог менять шаблон — шаблон должен находиться вне проекта. Потому как при деплое проекта всё что изменил «простой пользователь» (при нахождении шаблона в проекте) будет похерено.
Хранить шаблон в базе — можно, но тогда нужен специальный механизм для того чтоб «простой пользователь» мог его достать из базы исправить и положить обратно. И опять — что он может поправить для конкретного примера?
«Простой пользователь» должен понимать язык построения шаблона, понимать что за поля используются в качестве условий, в качестве данных. Это будет уже не простой пользователь, да и для понимания ему надо подготовить хороший мануал. Нормальный программист, как показала практика, сделал это «с листа».
Да есть задачи , в которых «простой пользователь» должен менять шаблон . Эти шаблоны должны сохраняться при деплое, разработчик должен видеть и проверять изменения кода с ними, т. е. необходимо иметь копию пользовательских шаблонов у разработчика, но это отдельная тема для разработки. Данный код не попадает в эту категорию.
Если я что-то пропустил — прошу разъяснить.
Это не критика использования шаблонов, это попытка разобраться.
