Monikers Compostos
Uma das características mais úteis dos apelidos é que você pode concatenar ou compor apelidos juntos. Um de 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 dado dois ou mais apelidos que são o equivalente 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 moniker, você também poderia compor seus monikers 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 são uma combinação de apelidos mais simples. Isso reduz significativamente a necessidade de classes de apelido personalizadas específicas.
Como os monikers de classes diferentes podem ser compostos uns com os outros, os monikers 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 container 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 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 de moniker lida com o resto. Uma chamada para IMoniker::GetDisplayName em um composto cria um nome usando a concatenação de todos os nomes de exibição de apelidos 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" 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 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 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. Em contrapartida, as 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 mais comumente usadas de monikers.
Os clientes Moniker 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 do moniker determinar que uma composição genérica é utilizável, OLE fornece o função CreateGenericComposite para facilitar isso.
Tópicos relacionados