Боюсь нарваться на праведный гнев защитников ООП :), но все-равно поделюсь личным опытом.
VFP выросло из процедурного FPD многое что касается ООП добавилось, но отказываться от проверенных подходов только в дань моде ООП считаю не уместным. Знать о возможностях ООП надо, но не надо пытаться использовать их любой ценой. Курсор, например, не может быть свойством объекта. Отказаться от их использования? Зачем?
CTAC-KO Я вынес отдельными методами серию SET-ов, подключение к SQL-серверу, афторизацию, выход из проги и тд. Кроме того создал пропертя типа Админ, SQLHandle и т.п. (вместо создания паблик-переменных).
Я можно сказать на том же остановился. Сделал обертки для наиболее используемых наборов функций (работа с файлом, с Ini-файлом, запуск и ожидание завершения внешнего приложения и т.п.)

Лично для меня в ООП важен только принцип повторно используемого кода.
Если попытаться сформулировать в правило какой код собирать в объект, то оно будет звучать так: "Если какой-то кусок кода пишешь второй раз, надо скопипастить и задуматься, пишешь в третий раз - сделать класс и использовать его, на 4 раз исправить первые два на объект" На третий раз приходит уже четкое понимание того какие свойства и методы нужны объекту, на 4-й это либо подверждается, либо класс переделывается.
И то за исключением случаев когда можно обойтись функцией и вставить ее в файл подцепляемый по SET PROC
CTAC-KOВсе это хорошо и я начал думать дальше.

Значит у меня в проге есть список работников. Думаю - надо создавать объект оРаботники, который сможет ...
А в меню мне нужно к примеру так - Меню Справочнеги, Пункт Работнеги. Сейчас там do form ListWorkerz with ADD|EDIT. ...
А форма разве не объект? На мой взгля форма самый идеальный базовый класс для простых объектов бизнес-логики. Курсор не может быть свойством объекта, он виден всем в DE, а если форма с PrivateDataSession, то курсор на форме становится ее свойством. Создать несколько однотипных форм фокс не запрещает. Производный класс раве что не создашь.
На мой взгляд достаточно нескольких классов форм (я так делаю):
1. clsForm (производный от Form) - прописан Resize(), создание пункта меню при получении фокуса, запуск модально/немодально, автоизменение размера шрифта, контроль повторного открытия формы и еще кое-что по мелочи
2. clsFormBSpr (производный от clsForm) - работа со списком записей, есть грид и набор кнопок (добавить, удалить ...)
3. clsFormESpr (производный от clsForm) - работа с одной записью, есть набор кнопок (сохранить, отмена)
и т.д. (есть еще clsFormBDoc, clsFormEDoc для документов с табличной частью, clsStepForm - для сложных расчетов с показом шагов и прогрессбаром)

Создав две формы на основе clsFormBSpr и clsFormESpr, добавляю в DE нужную таблицу или КА, на первой настраиваю колонки в гриде, на второй поля ввода. Остальное взаимодействие между этими формами прописано в классах форм (поиск, добавление, правка, удаление, копирование, ввод с возможностью отмены сохранения и т.д.). В 80% случаев этого достаточно чтобы за пару минут сделать интерфейс для простого справочника, в остальных случаях прописываются ньюансы обработки и отображения конкретных данных.
Все что касается бизнес-логики, то часть работы со списком добавляется в форму списка, часть касающаяся обработки конкретной записи в форму обработки записи. Если надо - всегда можно вызвать DO FORM ... NOSHOW
И самый главный плюс формы - ее можно запустить одним мышекликом, в отличии от классов в VCX. Классы в PRG наверно "не умею готовить"

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

прошелмимо авторА форма разве не объект?
это ужас, летящий на крыльях ночи
Ничто так не меняет точку зрения как удар в глаз. Свои эмоции надо аргументировать. Цитат из мультфильмов недостаточно.
прошелмимоэто попытка еще раз рассказать о подходе, который:
- повышается производительность труда программистов и снижаются трудозатраты;
- повышается надежность программ.
...
логика не бывает сложной,
логика или есть или ее нет (т.е. на самом деле логика есть всегда - законы существуют
более 3-х тысяч лет) - есть понятие истинности и неистинности (ошибочности, ложности, изв. за каламбур)
вот когда все сложно - и выручает наследование в 5 уровней + взаим-е десятка классов,
в 3-- 5-ти виз-х библиотеках
Ага. Смотришь на этот изнаследованный код, лазишь по методам всех уровней и материшь про себя того джедая с бластером и красным мечом, который это напроектировал. Даже если это твой собственный проект законченный год назад и благополучно забытый. И в чем тут высокая производительность? В том что при внесении изменений самый нижний класс надо просмотреть и протестить всех наследников? Это повышает надежность? Или проекты выполненные по всем правилам теории ООП так хороши что не требуют внесения изменений? Инкапсуляция и наследование красивы только в теории, а на практике приходится жертвовать теорией в угоду производительности.
На мой взгляд понятней и надежней использовать свойства-объекты, чем наследование. Хотя тестить при изменении тоже не мало.

А у меня библиотека базовых форм едина на все проекты, постоянно используется, доработки не требует, поэтому не надо долго вспоминать что там к чему. В 99% времени работы с программой нужна именно визуализация, так почему бы не делать объекты на основе форм? В чем ужас? Про последовательность инитов в курсе. Чем это не ООП?
1. В форме легко собирается весь код для работы с конкретным объектом. Весь код и данные в одном месте. В случае чего поправил, быстро протестил и забыл.
2. Форму элементарно запускать (особенно в процессе разработки)
3. На форме простановка ControlSource делается мышекликами, а в VCX приходится руками писать

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

прошелмимоя и твержу все время,
анализ, анализ, синтез, синтез, снова анализ ...
А работу когда работать? Производительность производить?
Для анализа надо сначала досконально изучить предметную область. Ладно если проект большой есть отдельный аналитик, который только этим и занимается, круги с квадратами рисует, а если я все в одном? Потеря времени на излишний анализ явно мою суммарную производительность не повысит.
Я предпочитаю максимальное время анализа уделить проектированию структуры БД, чтобы можно было все данные правильно хранить, чтобы потом с нуля не переделывать, а все остальное строится уже от БД.

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

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

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

PS Извини за резкость :)