n  Шаблоны допускают весьма гибкое форматирование точек вставки, которое может обеспечить и наглядную, и компактную запись.

n  Обработчик выдаёт протокол сборки, позволяющий легко понять коллегу или себя.

n  Обработчик компактен и элементарно переносится на любую машину, работающую под управлением любой ОС.

Но не будем долго распространяться о мощи шаблонного подхода. Давайте перейдём к недостаткам.

Слабые стороны подхода

Когда вы принимаете решение использовать или не использовать некий подход (в частности, описываемый в этой статье), важно знать не только достоинства и потенциальные возможности, но и недостатки подхода. Итак, какие есть недостатки? Какие из них можно преодолеть, а какие – нельзя?

Относительно работы обработчика

Приведённая здесь реализация практически не содержит механизмов обработки нештатных ситуаций. Естественно, было бы полезно добавить следующее:

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

n  Было бы полезно реализовать проверку правильности конструкций, описывающих имя файла в точках вставки. Реакция программы на нештатные ситуации типа вложенных скобок или множественных двоеточий должна быть разумна.

n  Программа должна корректно себя вести, если требуемый файл не существует. Как? Решать вам. Может быть, вы предпочтёте аварийную остановку (сейчас сделано именно так) или захотите, чтобы эта ситуация была бы проигнорирована.

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

Плодотворной может оказаться идея «аварийного шаблона», который вставляется в те точки, которые не были корректно обработаны.

n  Было бы очень уместно сделать кэширование считанных файлов. Тем более, что это совсем не трудно.

n  После того как вы сделаете кэширование, можно очень легко сделать предопределённые шаблоны. Например, шаблон DATE может содержать дату сборки.

n  Очень полезной была бы и возможность регламентировать дополнительные обработки (или не обработки) файлов. Например, можно сделать, чтобы файлы с расширениями .file не обрабатывались как шаблоны, а их содержимое вставлялось «как есть». И наоборот, файлы с расширениями .quot проходили бы дополнительную обработку механизмом HTML-квотирования, заменяющим «&» на «&» и так далее. Здесь тоже возможны варианты: должен ли, например, подвергаться квотированию шаблон, вставляемый в квотируемый шаблон?

n  Было бы заманчиво хранить информацию с разными именами в одном файле, чтобы не заводить множество маленьких (как это получилось у нас с файлами заголовков и адресов). Это, правда, потребует некоторого усложнения «адресации» данных. Обойтись просто именем файла, как сделали мы, будет уже нельзя. Все ли в вашей команде одобрят подобные нововведения?