Объектное API

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

1. В основе должен быть IUnknown.
— Это динамическая поддержка нескольких интерфейсов
— Это агрегация

1.5 Взять из COM принципы управления памятью и указателями на интерфейсы.

2. Первый аргумент методов должен быть указатель на интерфейс контекста вызова. Через этот контекст можно:
— Выполнять отмену вызова
— Возвращать описания ошибок/предупреждений/сообщений вызова
— Выделять память компоненту

Нужно ли передавать контекст в методы контекста? Наверное, да.

<уже начал напрягаться, чтобы вспомнить>

3. Для настройки и получения характеристик компонент следует использовать свойства, сгруппированные в наборы.

— Для идентификатора набора свойств вполне подходит GUID.
— Внутри набора используется целочисленный идентификатор свойства.
— У компоненты может быть несколько наборов свойств.
— У свойства может быть несколько равнозначных символьных идентификаторов.

— Свойство может связанно с несколькими объектами внутри компоненты (например — Columns внутри Rowset). При получении/установки свойства нужно указывать идентификатор целевого объекта.

4. Нужен аналог VARIANT. Для универсальной передачи типизированных значений (свойств, в первую очередь).

<пока все>


А, ну да. Напомню себе, что у модуля с компонентами должен быть метод инициализации и деинициализации. Допускается повторная инициализация, компенсируемая связанным вызовом метода деинициализации.


PS. Если вспомню что еще, дополню.

Leave a Comment