Немного шокирует, что эта штука будет работать :)
using System;
using System.Runtime.InteropServices;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
// ухты !!!
IFoo i = new IFoo("Hello");
i.Print();
Console.WriteLine(i.GetType());
Console.ReadLine();
}
[Guid("40DCF1C3-C39D-4BB0-B967-1391C56E2852")]
[CoClass(typeof(Foo))]
[ComImport]
interface IFoo
{
void Print();
}
class Foo : IFoo
{
private string _message;
public Foo(string message)
{
_message = message;
}
public void Print()
{
Console.WriteLine(_message);
}
}
}
}
К интерфейсу (во время компиляции!) "подвязывается" экземпляр дефолтового класса (что-то типа Activator.CreateInstance(Type.GetTypeFromClsid(GUID OF COCLASSTYPE)), и дальше все работает так, будто бы мы явно создавали экземпляр конкретного класса.
Вникать историю развития COM особого желания нету, но пример забавный. К сожалению, трудно представить реальное применение этой фичи.
3 комментария:
Вот, например, нету в Framework клаcса работы с сетевыми дисками такого как WScript.Network, тогда можно его по GUID вызвать, это конечно неудобно (удобней Createbject), но не уверен что все COM- объекты можно привязать по наименованию. Хотя тогда не понятно чем .NET будет от скрипта отличаться. Я конечно в .NET не эксперт, но иногда формочками балуюсь 4fun.
Вот, например, нету в Framework клаcса работы с сетевыми дисками такого как WScript.Network, тогда можно его по GUID вызвать, это конечно неудобно (удобней Createbject), но не уверен что все COM- объекты можно привязать по наименованию. Хотя тогда не понятно чем .NET будет от скрипта отличаться. Я конечно в .NET не эксперт, но иногда формочками балуюсь 4fun.
Спасибо за пример. То, что это можно использовать для работы с COM - понятно. Меня сама конструкция new Interface приколола:) Имхо, это синтаксический сахар, который только сбивает с толку.
Отправить комментарий