Le classi di modelli, CComObject, CComAggObjecte CComPolyObject sono sempre le classi derivate più nella catena di ereditarietà. È loro responsabilità di gestire tutti i metodi in IUnknown: QueryInterface, AddRefe Release. Inoltre, CComAggObject e CComPolyObject (quando viene utilizzato per gli oggetti aggregati) forniscono il conteggio dei riferimenti speciali e QueryInterface semantica necessaria per l'inner unknown.
Se CComObject, CComAggObjecto CComPolyObject è usato dipende dal se si dichiara la macro DECLARE_POLY_AGGREGATABLE e se l'oggetto è da aggregare:
Il vantaggio di utilizzare CComAggObject e CComObject è che l'implementazione di IUnknown è stato ottimizzato per il tipo di oggetto creato. Per esempio, un oggetto non aggregato solo bisogno un conteggio dei riferimenti, mentre un oggetto aggregato esigenze sia un conteggio dei riferimenti per l'inner unknown che un puntatore all'ignoto esterno.
Il vantaggio di usare CComPolyObject è che si evita di avere sia CComAggObject e CComObject nel modulo per gestire i casi aggregati e non aggregati. Un singolo oggetto CComPolyObject gestisce entrambi i casi. Questo significa che solo una copia di vtable e una copia delle funzioni presenti nel modulo. Se tuo vtable è grande, questo può ridurre notevolmente le dimensioni del modulo. Tuttavia, se tuo vtable è piccola, utilizzando CComPolyObject può comportare una dimensione leggermente più grande del modulo perché esso non è ottimizzato per un oggetto non aggregato o aggregato, come sono CComAggObject e CComObject.
La macro DECLARE_POLY_AGGREGATABLE viene aggiunto automaticamente alla definizione della classe dalla creazione guidata oggetto ATL quando si crea un controllo completo o il controllo di Internet Explorer. Per ulteriori informazioni sulla procedura guidata, vedere creazione di un progetto ATL.