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 u

Answer 1

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 2

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 
  {}
  
  }
  

Even though I think the last possibility is the cleanest, its 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.

Answer 3

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.