Агрегация COM не поддерживается большинством объектов? - PullRequest
4 голосов
/ 18 апреля 2009

Я заметил, что многочисленные книги и т. Д. По COM указывают на то, что относительно легко реализовать объект, который можно использовать в качестве внутреннего объекта в агрегации COM. Однако, если я что-то упускаю, кажется, что агрегация может быть успешной только в крайне ограниченных сценариях, и, следовательно, ее поддержка должна предоставляться только тогда, когда такой сценарий специально распознается.

Часть, которая беспокоит меня, заключается в следующем. Агрегация COM объединяет идентичность внутреннего объекта с идентичностью внешнего объекта. Разработчик внешнего объекта выбирает подмножество интерфейсов внутреннего объекта и перенаправляет запросы на эти интерфейсы внутреннему объекту. Внутренний объект перенаправляет все запросы на интерфейсы к внешнему объекту. Теперь предположим, что внутренний объект в рамках своей реализации создает дочерние COM-объекты. Предположительно указатель интерфейса передается этому COM-объекту, чтобы он мог общаться со своим родителем. Внутренний объект имеет некоторое представление об интерфейсах, которые он реализует. Однако внешний объект мог бы не передавать некоторые из этих интерфейсов. Действительно, в документации говорится, что внешний объект не должен слепо перенаправлять интерфейсы. Кажется, это подразумевает, что внутренний объект часто не может передавать указатели интерфейса другим COM-объектам, если только внешнему объекту не требуется перенаправлять все эти интерфейсы внутреннему объекту. Это не ограничено сценарием дочернего объекта. Действительно, любое место, где внутренняя реализация объекта передает указатель на интерфейс, кажется, что на них может быть оказано влияние.

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

Это правильное (и редко документированное) описание того, как обстоят дела на самом деле, или есть что-то еще для истории?

Ответы [ 2 ]

4 голосов
/ 22 апреля 2009

Нашел вашу ветку томной здесь, думал, что я отвечу. Для начала, агрегация сравнивается с инкапсуляцией в ООП, но с некоторыми существенными отличиями. Что приятно, так это то, что во внешнем интерфейсе не требуется много работы для раскрытия агрегированного интерфейса. Что не хорошо, так это то, что интерфейс должен быть спроектирован так, чтобы его можно было агрегировать с самого начала - требование, которого нет в инкапсуляции ООП. Это ограничивает шансы, когда на полке лежит класс COM, готовый к посадке. Исходя из моей собственной работы, когда я столкнулся с вопросом, поддерживать агрегацию или нет, я все же должен ответить «да, может быть когда-нибудь будет полезно». Головные боли от реализации делегирующих и не делегирующих IUnknowns привели меня к «нет».

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

Но да, агрегирование не очень практично.

1 голос
/ 22 апреля 2009

Каждый отдельный COM-объект, который я когда-либо реализовывал или видел, реализовал, имеет проверку отсутствия агрегации в своем методе create. Большинство COM-объектов MSFT-корабли не поддерживают агрегацию.

...