Does anyone know the rationale behind this naming convention? I don't see any benefit. The extra prefix just pollutes the API.
I like Konrad Rudolph's response found in this related article
Does anyone know the rationale behind this naming convention? I don't see any benefit. The extra prefix just pollutes the API.
I like Konrad Rudolph's response found in this related article
It's either that or add "Impl" to the implementation of the interface (argh). I don't have a problem with the "I", it is the simplest and most straightforward naming for an interface.
Most likely its to make it easily identifiable in intellisense, since all the interfaces will clump together. Similar to how I prefix all my UI controls with btn, tb, lb. When intellisense kicks in everything is clumped together in one easy group.
I also like it cause I can read it as "I verb-behavior" as in "ICanSave" or "IDoDoubleEntry" etc...
Naming conventions offer the benefit of telling you something about the object before you use it. Naming conventions have been widely used for many years, going all the way back to fortran's insistence that integer values were restricted (if I remember correctly) to variable names like "i" and "j".
Hungariation notation took naming conventions to a whole new ugly level tha described the variable type, whether or not it was a pointer, etc. Many of us who were exposed to lots of code with Hungarian notation developed nervous twitches and verbal stutters.
Prefixing interface names with I is a relatively low-impact, harmless way of identifying that object.
Its the complete opposite, the naming convention clearly shows what is an interface.
For example if you have:
public class Dog : IPet, IMammal { ....
Just from reading it, I can clearly see that IPet and IMammal are probably interfaces.
The .NET CLR allows for single class inheritance. So, if I have a base class..I can only inherit one class from it. Lets change the IPet interface to a base class..our example now bebomes
public class Dog : Pet, IMammal { ....
I am inheriting from the Pet class and implementing the IMammal interface.
If we did it what you are suggesting and removed the letter "I" we have this:
public class Dog : Pet, Mammal { ....
Which one is the class I am inheriting from? Which is the interface I am implementing? It gets confusing right? (FYI..you are supposed to put the base class always first, so you could argue that point...but it you are arguing to remove the letter I from interface names I doubt you follow that practice as well)
As you can see that naming convention easily tells me a lot about my object without me having to investigate further. I can easily see what I am inheriting vs what I am implementing.
A
Actually I find it useful to avoid naming clashes, I might for example create a concrete class called Fred that implements IFred
I think that the IInterface naming convention is silly. It's an example of Hungarian notation, and I subscribe to the school of thought that despises Hungarian notation. If you have an interface with only one implementation that has the same name, consider the possibility that this is a code smell.
However, I still use it, because in this case IInterface is recommended by Microsoft, and "standard is better than better".
I always thought it was fun to use verbs for behavioral interfaces. This is a departure from the class naming convention of using nowns, but it allows the class to "speak" to its behavior.
class Dog: IBark
This does not work well for structural interfaces like WCF interfaces, but we don't need to have fun all the time.
to answer your question, think of the I as "implements" So...
class DogDataService : Dog, IDataService
this service class inherits from Dog and implements IDataService
I'm still not really answering your question, but the I is useful because you get naming collisions between namespace, class and interface.
namespace DataService
interface DataService
class DataService: DataService
so we end up with
namespace DataServices
interface IDataService
class DataService : IDataService
I think in reality, it's a sanity convention.
It is just a naming convention so everybody would know if it is an interface or something else it is not mandatory nor by the compiler nor by the IDE but All the interfaces i saw in my entire life starts with the letter I
Firstly I believe prefixing with I then description is wrong because it means implenentations can have a shorter name. IList (intf) -> List. This is an antopattern as we all know we should beusing intf and probably only concrete types when creating. Don't flame me this is a generalisation but the premise is intf only impl rarely. The implementation name should describe how it's implementing the intf or what it's doing. Think intf List, LinkedList which implements List using a linked list. Who cares if it's longer as we should be using List most of the time. If we have a class implementing many intf we probably should not include all the intf as the shadows the real purpose of the class. IN the case something removed without the intf makes sense. Eg ppl call me by name not Person, Sibling, developer etc using my name is the best most descriptive name. I suppose if a class is impl a simple intf then call it DefaultIntf which makes it on ious this is the deafulT implementation of Intf. Names of classes sHould in the end be human readable and almost a short phrase describing their purpose. Prefix codes etc are not great as we communicate with words not codes. Computers do t cAre what classes are called so why remains is that we name things so the names help us and our colleagues.
The "I" convention seems to be an old convention that wouldn't be relevant today. Current code editor provides lots of insight about the type you are using, so arguing that It's easier to identify the interface is like asking for a namespace to be prefixed by a "N" because you want to be sure that you will not confound it with a concrete class (prefix with a "C"?).
A convention doesn't mean that It's a good convention. Sometimes, It's just because people get to use it...
Take for example the C# documentation generator: It doesn't care about it... if your interface is not prefixed with a "I" you will still see your interface in the interface part of your documentation. Do you really think that having a prefix "I" for all your interfaces inside the interface section of your documentation is a relevant information and help you to better identify interfaces?
Why isn't this a function of syntactical highlighting instead of Hungarian notation? Why doesn't the IDE just italicize identifiers that refer to interfaces if it's so important to distinguish between classes and interfaces. I hate putting "" or "m" before fields, "C" before classes, etc. Even worse, it encourages programmers write really bad APIs like
public class List : IList
instead of
public class LinkedList : IList public class ArrayList : IList public class HashList : IList
Even the .NET common class authors fell into this trap. A class name should NEVER be the name of the interface with just the "I" removed. The class name should always tell the user how the class differs from other possible implementations of the interface(s). I vote for dropping the stupid "I" for that reason alone.
Also, when I use intelisense, I want to group things by functional area, not whether it's a class or interface. I never think, "I need an interface, not a class." I always think, "I need something that does X".