[gl00mie]

Цитата:

Сообщение от kashperuk

Но тогда с Табаксом пришлось бы параллельно распространять класс базовый. Чего и хочется избежать

Не вижу объективных причин для столь жесткого условия в контексте прикручивания к Табаксу плагинов. Когда он был сам по себе, то пожалуйста, можно весь код, вопреки best practices, пихать в методы формы, но когда появляются плагины и объективная необходимость как-то формализовать взаимодействие с ними, то без какого-то развитого интерфейса взаимодействия уже не обойтись. Идентификация плагина по префиксу названия класса - это мелочи, самое интересное начнется тогда, когда понадобится как-то регулировать работу Табакса с плагинами, работу плагинов с Табаксом и работу плагинов в окружении других плагинов (какие-нить блокировки и т.п.). Как только дело дойдет до реальной работы, передача плагину ссыли на экземпляр формы уже никого не устроит. Пусть Табакс предполагает наличие у класса-плагина метода void tabax(FormRun _fr), но как плагин будет взаимодействовать с самим Табаксом? тоже предположит, что у формы есть какие-то методы с определенными наборами параметров? А в следующей версии Табакса они сохранятся, а новые добавятся? А как плагин сможет проверить, что он работает как минимум с такой-то версией Табакса, реализующей нужную ему функицональность?..
Imho по-любому дожен быть 1) формализованный интерфейс для плагина с поддержкой версионности; 2) формализованный интерфейс для Табакса и его сервисных функций, предоставляемых плагину, с поддержкой версионности. Посмотрите на Far Manager plugin API, посмотрите на Winamp plugin API, посмотрите на COM-интерфейсы, в конце концов...