vklepkoПосмотрите как сам VFP(сам engine) использует эти паттерны.
Первое время когда использовал "ручное" кодирование, то в качестве pattern использовал ранее разработанный и
отлаженный код.
Т.е. к примеру имеем код prg в котором производится формирование отчета скажем с тремя уровнями вложенности итогов.
Возникает необходимость в написании нового, то берем код "подходящего" отчета и доводим его до "кондиции".
Все крайне просто. Но много времени тратилось на изменение содержимого "подходящего" pattern.
Пришел момент когда понял, что хорошо бы избавиться от этой рутины и разработал генератор отчетов, который по существу
на основе meta данных отчета генерировал исходный код *.prg, который и был по существу кодом, который бы мне пришлось
делать в ручную.
Скажу, что этот подход позволил мне без проблем разработать по крайней мере 3 отчета.
И самое главное их не нужно было отлаживать, так как генератор на 100% давал правильный код *.prg.
Был также генератор форм, который также сэкономил много времени.
Да были конечно стандартные designers Foxpro, но в них многое нужно было делать "руками" ...
К примеру в моем генераторе можно было просто взять графы из каких-то других отчетов и задействовать в разрабатываемом.
Этот механизм также был использованы по отношению к break /итоговые строки/ ... ... ...
Даже был создан механизм parsing текста "чужого" отчета.
То бишь он парсил текст сформированного отчета и результатом его были готовые meta данные.
Вообщем такой поход экономил до 70% времени ...
"Ну вы понимаете как мне в таких условиях легко работалось ..."

PS: И еще об технологиях WWW.
С HTML, CSS, PHP, JavaScript, Perl, и многими другими технологиями дружу давно ...
Так вот всегда когда на habrahabr встречаю статьи об "замечательных" frameworks не покидает ощущение, что
имею дело с глубоко больными людьми ... /впрочем "имеются и другие мнения ..."/
Что-то пишут, спорят, улучшают ...
Казалось бы это все хорошо ...
Но вот возьмем к примеру http://nodejs.org/ к нему разработаны сотни plugins.
То же можно сказать о других frameworks.
И представьте себе код, который будет использовать эти framaworks и с десяток plugins к ним.
На мой взгляд такой код уже "мертв" не успев "родиться" ...

Чего на мой взгляд не хватает в VSF /могу и ошибаться, так как вообщем то не слежу за тем, что там к нему на ваяли/.
А вот чего - подхода подобного 1С.
Т.е. набора прикладных объектов /Счет, ПланСчетов, БухгалтерскиеИтоги, .../, которые можно было бы использовать по
аналогии с 1С.
Это была бы не не а-ля 1С, а набор прикладных объектов, который бы много упростил разработку подсистем бухгалтерского
учета. Понятно, что такой же подход можно было использовать и для других видов задач.
На VSF это все прекрасно можно было бы реализовать /может быть даже часть объектов разработать с использование
OLE objects/.
Про себя скажу не когда не считал себя ни 1С-ом, Foxpro-ом ...
По большей части разработку веду с использованием Visual Studio /C++/.