An Interface By Any Other Name

We’re going to take a brief break from our series on plug-ins to explore an idea that I had regarding naming conventions, specifically interface naming in .Net.

For those of you who program in frameworks other than .Net, this may not apply in your world. But in the .Net world, interfaces are like contracts for types. Their sole purpose is to identify a set of functionality that will be implemented in a concrete type. Any type can be made to implement any interface, or even multiple interfaces. Wait… this is turning into a discussion of the merits of interfaces. That’s not what this post is.

Instead, I’m going to blow your mind by changing a long-standing convention:

Interfaces are named IWhatItIs.

For example, a common interface in WPF is IValueConverter, and typically classes that implement it are called WhatItConvertsConverter (e.g. FeetToInchesConverter). And the code looks like

class FeetToInchesConverter : IValueConverter
    ... // implementation stuff

This is the usual pattern. We think of the class name, slap an I in front of it, and we have an interface name. This is even the approach that most code analyzers (like Resharper) take when refactoring code to extract an interface from a class.

I propose we drop the current convention in favor of a new one. Instead of naming our interfaces like classes (what it is) we should name them by what they do. It’s a subtle difference. It’s changing the focus from the noun (or adjective) to the verb. The interface mentioned above would then become IConvertValues, and the class would look like

class FeetToInchesConverter : IConvertValues
    ... // implementation stuff

As another example, take a look at ICommandManager, probably extracted from some class called CommandManager. This would become IManageCommands.

The primary benefit produced by this naming convention is code readability. Hi. I’m FeetToInchesConverter. I convert values… from feet to inches.

Also, this is totally legal in just about every .Net version because it’s just a renaming.

Some interfaces get a little weird, though. Specifically the ones that describe model types (e.g. ISerializable) and generics (e.g. ITypeConverter<TFrom, TTo>). For model types, you’d have to insert a verb that’s not there, and it just doesn’t feel… right (IAmSerializable, or ICanBeSerialized (ew)). For generics, well…

Class PointToVectorConverter
    Implements IConvertTypes(Of Point, Vector)

class PointToVectorConverter : IConvertTypes<Point, Vector>

Now that I’ve seen those, I don’t really see much improvement. Maybe it’s just good for service-defining interfaces.

Regardless, I’m going to try this with my next open source library. If it doesn’t work out, I’m going to delete this post and pretend it never happened.


5 thoughts on “An Interface By Any Other Name

  1. I see where you’re going with that, and it’s not a terribly bad idea… as a service definition. I was making your objection mentally before I got to the end of the article; makes me glad I’m not one of those hair trigger commenters I see on other blogs.

    I trust you’ll keep us informed how it works in your next lib?


      1. Haha… understood. No one wants to be the recipient of “Hey, aren’t you the guy that proposed verbing interfaces?”

        If this post disappears, I’ll pretend it never happened, too.

        Liked by 1 person

  2. How would you use this convention to name IEnumerable, ICollection, IList, IReadOnlyList and IImmutableList?

    In general, I think your naming convention might work for small interfaces that have one of few methods, but not so much for larger interfaces.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s