4

I recently discovered that it's possible to "new up" an interface in C# by decorating the interface with the CoClassAttribute to specify a default implementation.

[ComImport, Guid("579A4F68-4E51-479A-A7AA-A4DDC4031F3F"), CoClass(typeof(FooImpl))]
public interface IFoo
{
    void Bar();
}

public class FooImpl : IFoo
{
    public void Bar() { }
}

...

// Constructs a FooImpl
IFoo foo = new IFoo();

I'm aware that this feature exists primarily to support COM-interop, but I was wondering if this would be a reasonable way to associate interfaces with default implementations in generic class-libraries.

I have two questions:

  1. Are there any gotchas with doing this? I'm not an expert on COM-interop and I don't know if this will have any negative impact on POCOs. I haven't run any major tests, but the the IL for my example seems ok (a normal newobj instruction on FooImpl rather than calls to Type.GetTypeFromCLSID and Activator.CreateInstance).

  2. Even if this would work smoothly, are there other reasons (say from an API-design perspective) to avoid this?

Ani
  • 111,048
  • 26
  • 262
  • 307

2 Answers2

2

The key reason you shouldn't do this is that you are starting the COM lifecycle management on an instance of an object that doesn't need it. .NET will now have to do some COM interop that includes a security stack walk, apartment threading checks, and addref/release stuff.

Instead, I would consider looking at dependency injection (inversion of control pattern) and the Common Service Locator Pattern. I would focus on understanding constructor injection as it is the preferred pattern for dependency management.

Here's what I do in my libraries. Let's say I want to write a logging service (contrived example). I would have two core components:

MyStuff.Logging.Contracts - Here is where I would declare the ILogger interface MyStuff.Logging - Here is where I would write the different logging implementations I might have like FileLogger, DatabaseLogger, etc.

Then in my application I would use either Ninject or Unity (DI containers) to associate ILogger with the default implementation.

Geoff Cox
  • 6,102
  • 2
  • 27
  • 30
  • Thanks for this. Will the runtime really do all of that stuff even within a pure .NET environment simply because those attributes are present? Could you provide me with some info on this? – Ani Nov 11 '11 at 18:00
  • Check out this: http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.comimportattribute.aspx. "ComImportAttribute is a pseudo-custom attribute that indicates that a type has been defined in a previously published type library. The common language runtime treats these types differently when activating, exporting, coercing, and so on." – Geoff Cox Nov 28 '11 at 20:43
  • While using the new operator may end up just calling a constructor. I think the runtime would have to do lifetime management and threaded apartment management otherwise the class really isn't a COM object. – Geoff Cox Nov 28 '11 at 20:45
-2

Use intelisense comments:

    /// <summary>
    /// Explain here all about interface
    /// </summary>

rather then hacking the attributes, as it might backfire in someone else's semi-reflection implementation that uses your class. Attributes are there to be used by tools that use reflection, intelisense is for documentation.

Granted, some legacy tools will have problems reading your /// comments, but they will not be able to read your attributes either.

zmilojko
  • 2,125
  • 17
  • 27
  • This question isn't about comments, but a default implementation for an interface. – Geoff Cox Nov 28 '11 at 20:38
  • Nice, it is always good to vote down a competing answer, but I appreciate you didn't do it anonymously. Anyhow, the question was. "Are there any gotchas with doing this?" and I answered it and also proposed a correect way to solve his problem... – zmilojko Dec 14 '11 at 07:33