Interface Naming Notation - To "I" or not to "I" - Part 2

While discussing with JP Boodhoo why he stopped to use the I notation for the interfaces, I think we got to the point where it was clear why would someone drop the "I" or opposite, adopt it.

As a developer, I want to differentiate between a pure abstraction and a concrete thing. So to ease on ourselves, we put the I as a differentiation, rely on the visual interpretation that our brain (little one in my case) is doing ("association" as against to "memorization"). And that would be the justification of using the "I" notation.

Now, if we look at the same issue from a more real-world perspective - bicycle. A bicycle is an abstraction, a 3-wheel or mountain bicycle are something concrete.   So having something like:

   1:  class MountainBicycle : Bicycle
   2:  {
   3:  }

Is nothing but

   1:  class MountainBicycle : IBicycle
   2:  {
   3:  }

With a difference that you know that bicycle is an abstract thing and if your brain is trained enough about it, then you do not need to have an "I"-hint to trigger the "association".

Personal note: so far, from the comments to my previous post on this, I have not seen that direction. Does this mean we are "boxed" to a particular thinking and not willing to evaluate other options as a community (.NET)?...

PS: "Hey, what about Customer sample?" you might ask - never too late to admit - I was wrong. Customer is not concrete, therefor it's an interface, what concrete is a CertainTypeOfCustomer or any other deviation of a Customer :)


  • This is wrong:

    1: class MountainBicycle : IBicycle
    2: {
    3: }

    This is right:

    1: interface MountainBicycle : IBicycle
    2: {
    3: }

    It's just a standard. You can do whatever you want... and (please don't take this the wrong way), but you can even suck and get nowhere as a developer.

    But if you want to be serious and move forward, then you should definately adopt all the standards (that are truely standards) even if you don't understand them.


  • After reading my above message, I realize that it could sound negative, and I didn't want it to be...

    My "you should definately adopt all the standards" statement is reasoned as follows: As you continue to progress (as we all should be doing, because the development world never stops), you'll eventually say "ahh, that makes sense now why I've been doing that" or "ahh, that makes sense why the standard says to do ..."

    Ok, enough from me...

  • @Nullable

    I am sure in a time from now this will even not be a question. All I am trying to do is to understand the motivation behind the standard (it's not written by gods after all). Adopting things blindly is just not my way :)

  • In genreral, I avoid prefixes and certainly would not prefix a class with C or a structure with S, but interfaces get an I. (Generic type parameters are a different but related story)

    I'm sure that searching would turn up elegant and well written explanations of the importance of the I prefix for interfaces.
    For me, an interface is significantly different from a class or a structure and the I prefix makes that very clear.

    How can you say this is right when you are arguing for Interface prefixes.

    interface MountainBicycle : IBicycle


    This is a mountian bike that derrives from Bycycle which should be the default implementation of IBicycle

    class MountainBicycle : Bicycle

    On the other hand, this on is a mountain bike that (re)implements then bike features itself.

    class MountainBicycle : IBicycle


  • I agree that having "class MountainBicycle : Bicycle" makes sense from a domain perspective. Does it matter to me if Bicycle is an abstract class, an interface, or a concrete class? Problaby not.

    However everyone in .NET (including Microsoft so all the framework and SDK code is going to have this) uses the I notation. If you want to excuse that fact and are willing to explain why you don't use "IBicycle" then all the power to you. You'll probably have to explain it as some people will be expecting it.

    Is it right? Delphi used T prefix in all their classes so concrete classes were TForm and TButton. When 3rd party vendors came along to provide new controls, you saw the same thing. Java uses Bicycle and BicycleImpl which kind of thows me when I see code, but you get used to it.

    There's no right or wrong here. I could go either way but for me, if there are 10 guys in a room and 8 of them expect to be able to read "IThis" or "IThat" and ding me in a code review on readibility, I might try to fight it but it's going to take some convincing. Again, what battle do you want to fight today and is it that big of a deal having a naming standard you didn't come up with?

  • @Bil,

    This is a comment that would summarize it all. Thank you.

Comments have been disabled for this content.