Ответ 1, нет. Внутренний объект увеличивает счетчик ссылок внешнего объекта, когда его IUnknown::QueryInterface
успешно работает для IID без IUnknown
. По сути, если внутренний объект жив, то и внешний объект, даже если никакой внешний объект не содержит ссылку на внешний объект. Это должно быть так, потому что любые QueryInterface
, AddRef
и Release
, выполненные с помощью указателей интерфейса внутреннего объекта не IUnknown
, должны делегировать внешний объект.
Ответ 2, нет. Внутренний объект не имеет возможности узнать, из какого объекта он вызывается, и даже если бы это было сделано, он бы разрушил идентификацию. Например, в COM единственная надежная проверка идентификатора объекта заключается в том, что два указателя интерфейса IUnknown
являются одинаковыми или нет, но все предполагают, что если любые два, возможно, не IUnknown
, указатели интерфейса одинаковы, они из одного и того же объекта (нет никакой гарантии, наоборот, два указателя интерфейса без IUnknown
, даже одного и того же типа, могут быть разными и ссылаться на один и тот же объект).
Чтобы ответить 3, агрегация COM - это особый случай композиции, где вместо реализации перехваченных интерфейсов с использованием методов перенаправления или переноса мы возвращаем указатели прямого интерфейса из внутреннего объекта. Эта оптимизация более актуальна, когда у вас много составных объектов. Это не должно быть первым подходом к композиции, поскольку вы теряете контроль и применяете некоторые ограничения, например. вы не можете обертывать объекты, предоставленные или возвращенные внутренними объектами, без предварительной и последующей обработки, внешний объект и внутренний объект не должны перекрываться по функциональности (например, если внешний объект имеет родительский объект в соответствии с некоторым определением родительский, внутренний объект не должен иметь другого родителя под тем же определением или он должен полностью не знать о таком родительском объекте, то же самое для дочерних объектов) и т. д.