Monikers compostos
Um dos recursos mais úteis dos monikers é que você pode concatenar ou compor monikers juntos. Um moniker composto é um moniker 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 dado dois ou mais monikers 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ê escrevesse sua própria classe de moniker, também poderia redigir seus apelidos com monikers de arquivo ou item. A vantagem básica de uma composição é que ele oferece uma parte do código para implementar cada moniker possível que é uma combinação de monikers mais simples. Isso reduz significativamente a necessidade de classes de moniker personalizadas específicas.
Como os monikers de classes diferentes podem ser compostos entre si, os monikers fornecem a capacidade de ingressar em 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 porque nenhum contêiner entende os nomes gerados por outro contêiner. Os monikers permitem que esses namespaces sejam unidos porque os monikers de arquivo e os monikers de item podem ser compostos. Um cliente moniker pode pesquisar no namespace todos os objetos usando um único mecanismo. O cliente simplesmente chama IMoniker::BindToObject no moniker e o código do moniker manipula o restante. Uma chamada para IMoniker::GetDisplayName em uma composição cria um nome usando a concatenação de todos os nomes de exibição de monikers individuais.
Além disso, como você pode escrever sua própria classe moniker, a composição do moniker permite adicionar extensões personalizadas ao namespace para objetos.
Às vezes, dois apelidos de classes específicas podem ser combinados de forma especial. Por exemplo, um moniker de arquivo que representa um caminho incompleto e outro moniker de arquivo que representa um caminho relativo pode ser combinado para formar um único moniker de arquivo que representa 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 de composição não genérica.
composição genérica, por outro lado, permite a conexão de dois apelidos, independentemente de suas classes. Por exemplo, você pode compor um moniker de item em um moniker de arquivo, embora não, é claro, o contrário.
Como uma composição não genérica depende da classe dos monikers envolvidos, seus detalhes são definidos pela implementação de uma classe de moniker específica. Você pode definir novos tipos de composições não genéricas se escrever uma nova classe moniker. Por outro lado, composições genéricas são definidas pelo OLE. Os 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 apelidos compostos genéricos, todos funcionam juntos e são as classes mais usadas de apelidos.
Os clientes moniker devem chamar IMoniker::ComposeWith para criar uma composição no moniker com outra. O moniker que é chamado internamente decide se pode fazer uma composição genérica ou não genérica. Se a implementação do moniker determinar que uma composição genérica é utilizável, o OLE fornecerá a função CreateGenericComposite para facilitar isso.
Tópicos relacionados