Monday, April 2, 2007

Empty Interfaces

A recent practice I've taken up is empty interfaces.

Why you ask? Generics!

I love generics, they've added a whole new world to my design, but when it comes to using a generic interface, I find it best to wrap it in another interface, even if that interface is empty.

Here are some reasons:

1. The name is longer and intellisense isn't smart enough to fill in the types -- more typing (on the keyboard) is never fun (though visual assist does guess pretty well)

2. The name does not imply its responsibilities. Sometimes the generic interface is all you need, but the type of the interface is too generic to understand its responsibilities and behaviors.

3. If you need to add something extra to the interface, it will be quite painful to replace usages with an explicit interface.

4. A generic type name is an ugly type as a string -- I can never remember how to put a generic in the application configuration.

5. Less encapsulation -- if you have a generic interface that has two types, one type is implementation specific (like its used to consume another generic interface) and one type is consumer specific, consumers need to have more knowledge about implementation than they should, just to use the interface.

Here is a reason not to:
1. FxCop -- it gives you a warning... Here is what I think -- FxCop is great at giving warnings, but thats its job, it doesn't understand context, FxCop is not a reason on its own not to do something :)

2 comments:

lukemelia said...

When we talked about this, I called it a "marker interface". But since it's inheriting from an interface that does have a contract, it's not really a fit for that term. Maybe "alias interface" is a better term.

wendy said...

Luke -- hmm... alias interface, i like that, kinda mysterious! Makes me want to change the title :)