Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Um objetivo importante de qualquer modelo de objeto é permitir que os autores de objetos reutilizem e estendam objetos fornecidos por outras pessoas como partes de suas próprias implementações. Uma maneira de fazer isso em Microsoft Visual C++ e outras linguagens é usando implementation inheritance, que permite que um objeto herda ("subclasse") algumas de suas funções de outro objeto ao substituir outras funções.
O problema para a interação de objetos em todo o sistema usando a herança de implementação tradicional é que o contrato (a interface) entre objetos em uma hierarquia de implementação não está claramente definido. Na verdade, é implícito e ambíguo. Quando o objeto pai ou filho altera sua implementação, o comportamento dos componentes relacionados pode se tornar indefinido ou instavelmente implementado. Em qualquer aplicativo único, em que a implementação pode ser gerenciada por uma única equipe de engenharia que atualiza todos os componentes ao mesmo tempo, isso nem sempre é uma grande preocupação. Em um ambiente em que os componentes de uma equipe são criados por meio da reutilização em caixa preta de outros componentes criados por outras equipes, esse tipo de instabilidade coloca em risco a reutilização. Além disso, a herança de implementação geralmente funciona apenas dentro dos limites do processo. Isso torna a herança de implementação tradicional impraticável para sistemas grandes e em evolução compostos por componentes de software criados por muitas equipes de engenharia.
A chave para a criação de componentes reutilizáveis é ser capaz de tratar o objeto como uma caixa opaca. Isso significa que a parte do código que tenta reutilizar outro objeto não sabe nada e não precisa saber nada sobre a estrutura interna ou a implementação do componente que está sendo usado. Em outras palavras, o código que tenta reutilizar um componente depende do comportamento do objeto e não de sua implementação exata.
Para alcançar a reutilização em sistema de caixa preta, o COM adota outros mecanismos de reutilização estabelecidos, como contenção/delegação e agregação.
Observação
Para conveniência, o objeto que está sendo reutilizado é chamado de objeto interno e o objeto que faz uso desse objeto interno é o objeto externo.
É importante lembrar em ambos os mecanismos como o objeto externo aparece para seus clientes. No que diz respeito aos clientes, ambos os objetos implementam quaisquer interfaces para as quais o cliente pode obter um ponteiro. O cliente trata o objeto externo como uma caixa opaca e, portanto, não se importa, nem precisa se preocupar com a estrutura interna do objeto externo. O cliente se preocupa apenas com o comportamento.
Para obter mais informações, consulte os seguintes tópicos: