Återanvända objekt
Ett viktigt mål för alla objektmodeller är att göra det möjligt för objektförfattare att återanvända och utöka objekt som tillhandahålls av andra som delar av sina egna implementeringar. Ett sätt att göra detta på Microsoft Visual C++ och andra språk är genom att använda arv av implementering, vilket gör att ett objekt kan ärva ("underklass") några av dess funktioner från ett annat objekt samtidigt som andra funktioner åsidosätts.
Problemet med systemomfattande objektinteraktion med traditionellt implementeringsarv är att kontraktet (gränssnittet) mellan objekt i en implementeringshierarki inte är tydligt definierat. I själva verket är det implicit och tvetydigt. När det överordnade eller underordnade objektet ändrar implementeringen kan beteendet för relaterade komponenter bli odefinierat eller ej implementerat. I alla enskilda program, där implementeringen kan hanteras av ett enda teknikteam som uppdaterar alla komponenter samtidigt, är detta inte alltid ett stort problem. I en miljö där ett teams komponenter byggs genom black-box-återanvändning av komponenter skapade av andra team, äventyrar den här typen av instabilitet återanvändningen. Dessutom fungerar implementeringsarv vanligtvis bara inom processgränser. Detta gör traditionellt implementeringsarv opraktiskt för stora, växande system som består av programvarukomponenter som skapats av många tekniska team.
Nyckeln till att skapa återanvändbara komponenter är att kunna behandla objektet som en ogenomskinlig ruta. Det innebär att kodstycket som försöker återanvända ett annat objekt inte vet någonting och behöver inte veta någonting om den interna strukturen eller implementeringen av komponenten som används. Med andra ord beror koden som försöker återanvända en komponent på objektets beteende och inte på dess exakta implementering.
För att uppnå återanvändning av svarta rutor antar COM andra etablerade återanvändningsmekanismer som inneslutning/delegering och aggregering.
Observera
För enkelhetens skull kallas objektet som återanvänds för inre objekt och objektet som använder det inre objektet är det yttre objektet.
Det är viktigt att komma ihåg hur det yttre objektet visas för sina klienter i båda dessa mekanismer. När det gäller klienterna implementerar båda objekten alla gränssnitt som klienten kan hämta en pekare till. Klienten behandlar det yttre objektet som en ogenomskinlig låda och bryr sig därför inte, och behöver inte heller bry sig om den inre strukturen i det yttre objektetâ € "klienten bryr sig bara om beteende.
Mer information finns i följande avsnitt: