Reutilizando objetos

Um objetivo importante de qualquer modelo de objeto é permitir que os autores de objetos reutilizem e estendam objetos fornecidos por outros como partes de suas próprias implementações. Uma maneira de fazer isso no Microsoft Visual C++ e outras linguagens é usando a herança de implementação, que permite que um objeto herde ("subclasse") algumas de suas funções de outro objeto enquanto substitui 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 implementado de forma instável. Em qualquer aplicativo, onde a implementação pode ser gerenciada por uma única equipe de engenharia que atualiza todos os componentes ao mesmo tempo, essa nem sempre é uma grande preocupação. Em um ambiente onde os componentes de uma equipe são construídos por meio da reutilização de outros componentes construídos por outras equipes, esse tipo de instabilidade compromete 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 construídos por muitas equipes de engenharia.

A chave para construir componentes reutilizáveis é ser capaz de tratar o objeto como uma caixa opaca. Isso significa que o pedaço de 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 da caixa-preta, a COM adota outros mecanismos de reutilização estabelecidos, como contenção/delegação e agregação.

É 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 importar, com a estrutura interna do objeto externo – o cliente se preocupa apenas com o comportamento.

Para Mais informações, consulte os seguintes tópicos:

• Contenção/Delegação
• Agregação