What is the rationale behind this naming convention?
I don\'t see any benefit. The extra prefix just pollutes the API.
My thinking is inline with Konrad\'s respo
TL;DR - Extracting interface IFoo
from class Foo
is common in SOLID decoupling, especially for Unit Testing purposes
To me the dual convention of class Foo
implementing interface IFoo
(especially if both are in the same assembly) conveys a specific intention that:
Foo
should always be indirect, through the corresponding IFoo
interface (and likely to be injected via an IoC container)IFoo
is a proprietary, non-reusable interface specifically to allow classes dependent on Foo
to mock out this dependency during unit testing.IFoo
interface IFoo
are required at a later point, that proper interface segregation design will need to be retrofitted into the hierarchy.Rationale
In order to be able to Mock or Stub out a class, a widely accepted best practice in Unit Testing is to decouple dependencies between classes only via interfaces. This interface decoupling will also be done to classes which would otherwise never had a design requirement for polymorphicism (i.e. only one such implementation would have existed, were it not for the need for unit testing).
As a consequence, the refactoring and reuse of these interfaces (e.g. the Interface Segregation Principal of SOLID) isn't frequently applied to such 'mockable' interfaces - there is often a 1:1 correlation between the public methods, properties and events of a 'mockable' class (Foo
) and its decoupled interface IFoo
(similar to the COM-era automatic interfaces in VB).
Tools such as VS and Resharper can make extracting such public symbols from a class into a separate interface trivial, as an afterthought.
Further, if we consider that Mocking frameworks like Moq allow definition of implementations of the interface on-the-fly, we need not waste effort naming the concrete test double implementation class.
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?
I seems to traditional convention from Hungarian Notation. Interface Naming Guidelines says "Prefix interface names with the letter I, to indicate that the type is an interface." Framework Design Guidelines also says "DO prefix interface names with the letter I, to indicate that the type is an interface."
It is just a coding convention, So it's to hard to determine good or bad. Important things is consistency.
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
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.
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.