Здравствуйте Финченко Юрий, Вы писали: ФЮ>Вопрос номер два. А то у меня понятия стали путаться. ФЮ>Что такое моникер? В любой объектно-ориентированной (ОО) системе полезно иметь способ идентификации конкретного экземпляра объекта. Эта идентификация (именование) в общем случае требует указания 2 элементов: способа создания объекта (эквивалентно заданию CLSID) и его перманентных данных (необязательно). Сама по себе СОМ не предоставляет способа именования экземпляра объекта. В СОМ клиент может создать абстрактный экземпляр объекта, вызвав CoCreateInstance и передав её соответствующий CLSID. Если для объекта имеются перманентные данные, то клиент затем может использовать один из интерфейсов IPersist* или какой-то другой интерфейс, чтобы выдать объекту команду загрузки этих данных. Но для всех этих манипуляций клиент должен знать CLSID объекта и способ найти место хранения перманентных данных, а также иметь желание всё это проделать. В чистом виде СОМ не представляет клиенту простого решения. Однако существует помощник в этом деле, моникер, который и выполнит всю работу по созданию и инициализации конкретного экземпляра объекта. Моникер — это имя определённого экземпляра объекта, имя одного конкретного сочетания некоторого CLSID и перманентных данных. Каждый моникер идентифицирует только один экземпляр объекта. Но моникер — это больше чем просто имя. Он сам является СОМ-объектом, имеет свой способ создания и поддерживает особый интерфейс — IMoniker. У каждого моникера есть свои собственные перманентные данные, в составе которых всё, что необходимо моникеру для запуска и инициализации одного экземпляра объекта, идентифицируемого этим моникером. Зачем связываться с моникерами, что это нам даст? Так как клиенту в любом случае необходимо создавать СОМ-объект-моникер, почему просто не опустить этот этап вовсе и не создать целевой объект непосредственно? Зачастую моникер не даёт клиенту ничего: если создание моникера не уступает по сложности созданию и инициализации напрямую указываемого моникером объекта, эффект от применения моникера равен нулю. Но во многих других случаях (а их большинство!) моникеры могут значительно упростить жизнь клиента (и программиста, который пишет клиента!). Потому что, зная как вызывать IMoniker::BindToObject, клиент способен использовать моникеры для создания и инициализации объектов разных типов, каждый из которых может иметь абсолютно уникальные требования по созданию и инициализации. Инкапсуляция способов создания и инициализации объекта в моникере устраняет необходимость знания клиентом специфики процесса связывания и инициализации, так как, с точки зрения клиента, все моникеры выглядят одинаково. Значит, если моникер является СОМ-объектом, то нам нужно знать моникер-2 на моникер-1, чтобы, создав моникер-1, можно было бы создать нужный нам экземпляр объекта? И где конец у этой последовательности? Возможно, но необязательно. Если клиент умеет создать один тип моникеров, то он может создавать через него много экземпляров других объектов. Также существует ряд стандартных моникеров, реализованных в системе и готовых к использованию. Существуют системные функции, дающие конкретные экземпляры моникеров. В свою очередь, клиент может реализовать свой класс моникеров для идентификации объектов и создавать их в процессе работы по стандартным правилам СОМ. |