Monikers Compostos
Uma das características mais úteis dos apelidos é que você pode concatenar ou compor apelidos juntos. Um apelido composto é um apelido que é uma composição de outros apelidos e pode determinar a relação entre as partes. Isso permite que você monte o caminho completo para um objeto que recebe dois ou mais apelidos que são equivalentes a caminhos parciais. Você pode compor monikers da mesma classe (como dois monikers de arquivo) ou de classes diferentes (como um moniker de arquivo e um moniker de item). Se você fosse escrever sua própria classe de apelido, você também poderia compor seus apelidos com monikers de arquivo ou item. A vantagem básica de um composto é que ele lhe dá um pedaço de código para implementar todos os apelidos possíveis que é uma combinação de apelidos mais simples. Isso reduz significativamente a necessidade de classes de apelido personalizadas específicas.
Como os apelidos de classes diferentes podem ser compostos uns com os outros, os apelidos fornecem a capacidade de unir vários namespaces. O sistema de arquivos define um namespace comum para objetos armazenados como arquivos porque todos os aplicativos entendem um nome de caminho do sistema de arquivos. Da mesma forma, um objeto de contêiner também define um namespace privado para os objetos que ele contém, pois nenhum contêiner entende os nomes gerados por outro contêiner. Os Monikers permitem que esses namespaces sejam unidos porque monikers de arquivo e monikers de item podem ser compostos. Um cliente de moniker pode pesquisar o namespace para todos os objetos usando um único mecanismo. O cliente simplesmente chama IMoniker::BindToObject no moniker, e o código do moniker manipula o resto. Uma chamada para IMoniker::GetDisplayName em um composto cria um nome usando a concatenação de todos os nomes de exibição dos monikers individuais.
Além disso, como você pode escrever sua própria classe de moniker, a composição de moniker permite que você adicione extensões personalizadas ao namespace para objetos.
Às vezes, dois apelidos de classes específicas podem ser combinados de uma maneira especial. Por exemplo, um moniker de arquivo representando um caminho incompleto e outro moniker de arquivo representando um caminho relativo podem ser combinados para formar um único moniker de arquivo representando o caminho completo. Por exemplo, os monikers de arquivo "c:\work\art" podem ser compostos com o moniker de arquivo relativo ".. \backup\myfile.doc" para igual a "c:\work\backup\myfile.doc". Este é um exemplo de composição não genérica.
A composição genérica, por outro lado, permite a conexão de quaisquer dois apelidos, independentemente de suas classes. Por exemplo, você pode compor um apelido de item em um moniker de arquivo, embora, é claro, não o contrário.
Como uma composição não genérica depende da classe dos apelidos envolvidos, seus detalhes são definidos pela implementação de uma classe de apelido específica. Você pode definir novos tipos de composições não genéricas se escrever uma nova classe de apelido. Por outro lado, composições genéricas são definidas por OLE. Monikers criados como resultado da composição genérica são chamados de apelidos compostos genéricos.
Essas três classes, monikers de arquivo, monikers de item e monikers compostos genéricos, todos trabalham juntos, e eles são as classes de apelidos mais comumente usadas.
Os clientes de apelido devem chamar IMoniker::ComposeWith para criar um composto no moniker com outro. O apelido que é chamado internamente decide se pode fazer uma composição genérica ou não genérica. Se a implementação de moniker determinar que uma composição genérica é utilizável, OLE fornece a função CreateGenericComposite para facilitar isso.
Tópicos relacionados