Объектное API
Надо сформулировать, в первую очередь для себя, базовые принципы, на которые стоит опереться при создании интерфейса компонент. Пока нахожусь в здравом уме и ясной памяти 🙂
1. В основе должен быть IUnknown.
— Это динамическая поддержка нескольких интерфейсов
— Это агрегация
1.5 Взять из COM принципы управления памятью и указателями на интерфейсы.
2. Первый аргумент методов должен быть указатель на интерфейс контекста вызова. Через этот контекст можно:
— Выполнять отмену вызова
— Возвращать описания ошибок/предупреждений/сообщений вызова
— Выделять память компоненту
Нужно ли передавать контекст в методы контекста? Наверное, да.
<уже начал напрягаться, чтобы вспомнить>
3. Для настройки и получения характеристик компонент следует использовать свойства, сгруппированные в наборы.
— Для идентификатора набора свойств вполне подходит GUID.
— Внутри набора используется целочисленный идентификатор свойства.
— У компоненты может быть несколько наборов свойств.
— У свойства может быть несколько равнозначных символьных идентификаторов.
— Свойство может связанно с несколькими объектами внутри компоненты (например — Columns внутри Rowset). При получении/установки свойства нужно указывать идентификатор целевого объекта.
4. Нужен аналог VARIANT. Для универсальной передачи типизированных значений (свойств, в первую очередь).
<пока все>
—
А, ну да. Напомню себе, что у модуля с компонентами должен быть метод инициализации и деинициализации. Допускается повторная инициализация, компенсируемая связанным вызовом метода деинициализации.
—
PS. Если вспомню что еще, дополню.