Are there established alternatives to ISomething / ISomethingable for interfaces?

Question

The .NET standard of prefixing an interface name with an I seems to be becoming widespread and isn't just limited to .NET any more. I have come across a lot of Java code that uses this convention (so it wouldn't surprise me if Java used it before C# did). Also Flex uses it, and so on. The placing of an I at the start of the name smacks of Hungarian notation though and so I'm uncomfortable with using it.

So the question is, is there an alternative way of denoting that Something is an interface, rather than a class and is there any need to denote it like this anyway. Or is it a case its become a standard and so I should just accept it and stop trying to stir up "religious wars" by suggesting it be done differently?

Answer 1

From the Framework Design Guidelines book:

Interfaces representing roots of a hierarchy (e.g. IList) should also use nouns or noun phrases. Interfaces representing capabilities should use adjectives and adjective phrases (e.g. IComparable, IFormattable).

Also, from the annotations on interface naming:

KRZYSZTOF CWALINA: One of the few prefixes used is “I” for interfaces (as in ICollection), but that is for historical reasons. In retrospect, I think it would have been better to use regular type names. In a majority of the cases developers don’t care that something is an interface and not an abstract class, for example.

BRAD ABRAMS: On the other hand, the “I” prefix on interfaces is a clear recognition of the influence of COM (and Java) on the .NET Framework. COM popularized, even institutionalized, the notation that interfaces begin with “I.” Although we discussed diverging from this historic pattern we decided to carry forward the pattern as so many of our users were already familiar with COM.

JEFFREY RICHTER: Personally, I like the “I” prefix and I wish we had more stuff like this. Little one-character prefixes go a long way toward keeping code terse and yet descriptive. As I said earlier, I use prefixes for my private type fields because I find this very useful.

BRENT RECTOR Note: this is really another application of Hungarian notation (though one without the disadvantages of the notation's use in variable names).

It has very much become a widely adopted standard, and while it is a form of Hungarian, as Brent states, it doesn't suffer from the disadvantages of using Hungarian notation in variable names.

Answer 2

I would just accept it, to be honest. I know what you mean about being a bit like Hungarian notation (or at least abuse of the same) but I think it gives sufficient value to be worth doing in this case.

With dependency injection being in vogue, often I find I end up with an interface and a single production implementation. It's handy to make them easily distinguishable just with the I prefix.

One little data point: I work with both Java and C# a fair amount, and I regularly find myself having to check which types in Java are actually interfaces, particularly around the collection framework. .NET just makes this simple. Maybe it doesn't bother other people, but it bothers me.

+1 for IFoo from me.

Answer 3

As a .NET programmer (for the most part), I actually prefer the Java convention of dropping the I here, for a simple reason: Often, small redesigns require the change from an interface into an abstract base class or vice versa. If you have to change the name, this might require a lot of unnecessary refactoring.

On the other hand, usage for the client should be transparent so they shouldn't care for this type hint. Furthermore, the “able” suffix in `Thingable” should be enough of a hint. It works well enough in Java.

/EDIT: I'd like to point out that the above reasoning had prompted me to drop the I prefix for private projects. However, upon checking one of them against the FxCop rule set, I promptly reverted to the usage of I. Consistency wins here, even though a foolish consistency is the hobgoblin of little minds.

Answer 4

Its all about style and readability. Prefixing Interfaces with "I" is merely a naming convention and style guideline that has caught on. The compilers themselves couldn't care less.

Answer 5

The coding standard for Symbian has interfaces (pure abstract C++ classes) denoted with an M rather than an I.

Otherwise, the only other way I have seen of denoting interfaces is through context.

Answer 6

For .NET, Microsoft's Framework Design Guidelines book absolutely recommends it, and yes, it is very much standard. I have never seen it done otherwise, and to create a new convention would only serve to confuse people.

I should add that I dislike Hungarian notation too, but this and the case of prefixing class variables with an underscore are good exceptions to me, because they make code so much more readable.

Answer 7

I've always thought this naming convention is a bit of a dinosaur. Nowadays IDEs are powerful enough to tell us that something is an interface. Adding that I makes the code harder to read so if you really want to have a naming convention that separates interfaces from classes I would append Impl to the name of the implementing class.

public class CustomerImpl implements Customer

Answer 8

You asked for an alternative, so here is one I have encountered:

Use no prefix on the interface class, but use a c or C prefix on the corresponding concrete classes. Most of your code will generally reference the interface, so why pollute it with the prefix and not the generally much less used concrete type.

This approach does introduce one inconsistency in that some concrete types will be prefixed (the ones with matching interfaces) and others will not. This may be useful since it reminds developers that an interface exists and its use should be preferred over the concrete type.

To be honest, I use the prefix on the interface, but I think it is more because I have become so accustomed and comfortable with to it.

Answer 9

My main assumption is that the most important thing is to maintain readability in domain part of the implementation. Therefore:

• If you have one behaviour and one possible implementation, then just don't create an interface:

  public class StackOverflowAnswerGenerator { }

• If you have one behaviour and many possible implementations, then there is no problem and you can just drop the "I", and have:

  public interface StackOverflowAnswerGenerator {}

  public class StupidStackOverflowAnswerGenerator : StackOverflowAnswerGenerator {}

  public class RandomStackOverflowAnswerGenerator : StackOverflowAnswerGenerator {}

  public class GoogleSearchStackoverflowAnswerGenerator : StackOverflowAnswerGenerator {}

  //...

• The real problem comes when you have one behaviour and one possible implementation but you need an interface to describe its behaviour (for example for convenient testing, because of convention in your project, using some library/framework which enforces this, ...). Possible solutions, other from prefixing the interface are:

  a) Prefix or suffix the implementation (as stated in some other answers in this topic)

  b) Use a different namespace for interface:

  namespace StackOverflowAnswerMachine.Interfaces { public interface StackOverflowAnswerGenerator {} }

  namespace StackOverflowAnswerMachine { public class StackOverflowAnswerGenerator : Interfaces.StackOverflowAnswerGenerator {} }

  c) Use a different namespace for implementation:

  namespace StackOverflowAnswerMachine { public interface StackOverflowAnswerGenerator {} }

  namespace StackOverflowAnswerMachine.Implementations { public class StackOverflowAnswerGenerator : StackOverflowAnswerMachine.StackOverflowAnswerGenerator {} }

Currently I'm experimenting with the last possibility. Note that in the implementation source file you can still have "using StackOverflowAnswerMachine;" and have convenient access to the domain objects.

UPDATE: Although I still think the last possibility is the cleanest, it's one drawback is that even though "using StackOverflowAnswerMachine;" gives you access to all domain objects you must prefix all domain interfaces not to be confused with their implementations. That may feel like something not very convenient but in clean design usually a class doesn't use many other domain objects, and mostly you need to use the prefix only in field declaration and constructor parameter list. So, that is my current recommendation.

The client of domain functionality shouldn't need to know whether they're using an interface, an abstract class or a concrete class. If they need to know this, then there is some serious problem in such a project, because it has domain logic and infrastructural concerns mixed on the same abstraction layer. Therefore I recommend "a" or "c" solutions.