[ACCEPTED]-Why prefix C# interface names with an “I”-interface

Its the complete opposite, the naming convention 23 clearly identifies an interface.

For example 22 if you have:

public class Dog : IPet, IMammal
{
    ....

Just from reading it, I can 21 safely assume that IPet and IMammal are 20 probably interfaces.

The .NET CLR allows 19 for single class inheritance. So, if I 18 have a base class..I can only inherit one 17 class from it. Lets change the IPet interface 16 to a base class..our example now becomes

public class Dog : Pet, IMammal
{
    ....

I 15 am inheriting from the Pet class and implementing 14 the IMammal interface.

If we did it what 13 you are suggesting and removed the letter 12 "I" we have this:

public class Dog : Pet, Mammal
{
    ....

Which one is the class 11 I am inheriting from? Which is the interface 10 I am implementing? It gets confusing right? (FYI..you 9 are supposed to put the base class always 8 first, so you could argue that point...but 7 if you are arguing to remove the letter 6 I from prefixing interface names I doubt 5 you follow that practice as well)

As you 4 can see that naming convention easily tells 3 me a lot about my object without me having 2 to investigate further. I can easily see 1 what I am inheriting vs what I am implementing.

I also like it cause I can read it as "I 1 verb-behavior" as in "ICanSave" or "IDoDoubleEntry" etc...

I think that the IInterface naming convention 9 is silly. It's an example of Hungarian notation, and 8 I subscribe to the school of thought that 7 despises Hungarian notation. If you have 6 an interface with only one implementation 5 that has the same name, consider the possibility 4 that this is a code smell.

However, I still 3 use it, because in this case IInterface 2 is recommended by Microsoft, and "standard 1 is better than better".

Why isn't this a function of syntactical 20 highlighting instead of Hungarian notation? Why 19 doesn't the IDE just italicize identifiers 18 that refer to interfaces if it's so important 17 to distinguish between classes and interfaces. I 16 hate putting "" or "m" before fields, "C" before 15 classes, etc. Even worse, it encourages 14 programmers write really bad APIs such as:

public class List : IList

instead 13 of a more reasonable:

public class LinkedList : List
public class ArrayList : List
public class HashList : List

Even the .NET common 12 class authors fell into this trap. A class 11 name should NEVER be the name of the interface 10 with just the "I" removed. The class name 9 should always tell the user how the class 8 differs from other possible implementations 7 of the interface(s). I vote for dropping 6 the stupid "I" for that reason alone.

Also, when 5 I use intellisense, I want to group things 4 by functional area, not whether it's a class 3 or interface. I never think, "I need an 2 interface, not a class." I always think, "I 1 need something that does X".

Actually I find it useful to avoid naming 2 clashes, I might for example create a concrete 1 class called Fred that implements IFred

I always thought it was fun to use verbs 13 for behavioral interfaces. This is a departure 12 from the class naming convention of using 11 nouns, but it allows the class to "speak" to 10 its behavior.

class Dog: IBark

This does not work well for 9 structural interfaces like WCF interfaces, but 8 we don't need to have fun all the time.

to 7 answer your question, think of the I as "implements" So...

class DogDataService : Dog, IDataService

this 6 service class inherits from Dog and implements 5 IDataService

I'm still not really answering your question, but 4 the I is useful because you get naming collisions 3 between namespace, class and interface.

namespace DataService
interface DataService
class DataService: DataService

so 2 we end up with

namespace DataServices
interface IDataService
class DataService : IDataService

I think in reality, it's a 1 sanity convention.

If you consider the two "best-practice-aphorisms"

clarity is king

and 4

noise is bad

there is a conflict between these. The question 3 is: when does clarity become noise?

For 2 me it more noisy (but equally clear) to 1 write Person person = new PersonImpl() than IPerson person = new Person().

It's either that or add "Impl" to the implementation 3 of the interface (argh). I don't have a 2 problem with the "I", it is the simplest 1 and most straightforward naming for an interface.

The "I" convention seems to be an old convention 19 that wouldn't be relevant today. Current 18 code editor provides lots of insight about 17 the type you are using, so arguing that 16 It's easier to identify the interface is 15 like asking for a namespace to be prefixed 14 by a "N" because you want to be sure that 13 you will not confound it with a concrete 12 class (prefix with a "C"?).

A convention 11 doesn't mean that It's a good convention. Sometimes, It's 10 just because people get to use it...

Take 9 for example the C# documentation generator: It 8 doesn't care about it... if your interface 7 is not prefixed with a "I" you will still 6 see your interface in the interface part 5 of your documentation. Do you really think 4 that having a prefix "I" for all your interfaces 3 inside the interface section of your documentation 2 is a relevant information and help you to 1 better identify interfaces?

The need to differentiate between an interface 45 and a class actually indicates a design 44 flaw. In a well designed application, it 43 will always be clear. A subclass should 42 always be a specialization and classes can 41 only be specialized in one subject, never 40 more.

A class should have a single reason 39 for existence. It should never be required 38 to put secondary roles in a base class. E.g.:

public class XmlConfigurationFile : ConfigurationFile, IDisposable
{
}

public class YamlConfigurationFile : ConfigurationFile, IDisposable
{
}

The 37 first one is a configuration file that is 36 specialized in Xml, the second one is specialized 35 in Yaml. These are also disposable, but 34 that doesn't matter as much. You didn't 33 create these two classes because of a different 32 disposing processes.

Constrast this with:

public class XmlConfigurationFile : IDisposable, ConfigurationFile
{
}

This 31 will tell you that the main purpose a XmlConfigurationFile 30 has, is that it is disposable. That you 29 can use it as a way to represent configuration 28 files is nice, but is secondary.

The problem 27 starts when you create classes that have 26 multiple reasons for existence:

public class MyConfigurationFile : XmlConfigurationFile, YamlConfigurationFile
{
}

Even if XmlConfigurationFile 25 and YamlConfigurationFile would have been 24 interfaces, it still indicates bad design. How 23 can your configuration file be Xml and Yaml 22 at the same time?

If you read through the 21 examples given (here and elsewhere), people 20 always struggle to find a good example of 19 when the I-prefix matters. One of the answers 18 here is:

public class Dog : Pet, Mammal
{
}

This is how this class will look 17 like in an application about pets. A dog's 16 main purpose is being a specialized pet, that 15 can do pet-related things, not that it is 14 a mammal.

public class Dog : Mammal, Pet
{
}

This is how the same class will 13 look like in an application about animal 12 classifications. It is nice to know a dog 11 is a pet, but it's main purpose is being 10 a specialized mammal, that can do mammal-related 9 things.

I think your classes should tell 8 you the correct story about the architecture 7 and domain of your application. Requiring 6 an interface to be prefixed with an 'I' is 5 a technical requirement and doesn't help 4 you to tell your application's story better.

Once 3 you start writing small, dedicated, single-purpose 2 classes, the need for knowing if it implements 1 or extends will automatically vanish.

It makes it easily identifiable as an interface.

0

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 23 interface IFoo (especially if both are in the 22 same assembly) conveys a specific intention 21 that:

• Coupling on a dependency to a Foo should always be indirect, through the corresponding IFoo interface (and likely to be injected via an IoC container)
• The initial design of IFoo is a proprietary, non-reusable interface specifically to allow classes dependent on Foo to mock out this dependency during unit testing.
• Beyond the above, a reader doesn't need to infer any additional intelligence in the design of the IFoo interface
• Conversely, if multiple concrete implementation classes of 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 20 out a class, a widely accepted best practice 19 in Unit Testing is to decouple dependencies 18 between classes only via interfaces. This 17 interface decoupling will also be done to 16 classes which would otherwise never had a design requirement for polymorphicism (i.e. only 15 one such implementation would have existed, were 14 it not for the need for unit testing).

As 13 a consequence, the refactoring and reuse 12 of these interfaces (e.g. the Interface Segregation Principal of SOLID) isn't frequently 11 applied to such 'mockable' interfaces - there 10 is often a 1:1 correlation between the public 9 methods, properties and events of a 'mockable' class 8 (Foo) and its decoupled interface IFoo (similar 7 to the COM-era automatic interfaces in VB).

Tools such as VS and Resharper 6 can make extracting such public symbols 5 from a class into a separate interface trivial, as 4 an afterthought.

Further, if we consider 3 that Mocking frameworks like Moq allow definition of implementations of the interface on-the-fly, we 2 need not waste effort naming the concrete 1 test double implementation class.

Naming conventions offer the benefit of 14 telling you something about the object before 13 you use it. Naming conventions have been 12 widely used for many years, going all the 11 way back to fortran's insistence that integer 10 values were restricted (if I remember correctly) to 9 variable names like "i" and "j".

Hungariation 8 notation took naming conventions to a whole 7 new ugly level tha described the variable 6 type, whether or not it was a pointer, etc. Many 5 of us who were exposed to lots of code with 4 Hungarian notation developed nervous twitches 3 and verbal stutters.

Prefixing interface 2 names with I is a relatively low-impact, harmless 1 way of identifying that object.

It is just a naming convention so everybody 5 would know if it is an interface or something 4 else it is not mandatory nor by the compiler 3 nor by the IDE but All the interfaces i 2 saw in my entire life starts with the letter 1 I

Firstly I believe prefixing with I then 29 description is wrong because it means implementations 28 can have a shorter name. IList (intf) -> List. This 27 is an anti-pattern as we all know we should 26 be using intf and probably only concrete 25 types when creating. Don't flame me this 24 is a generalization but the premise is intf 23 only impl rarely. The implementation name 22 should describe how it's implementing the 21 intf or what it's doing. Think intf List, LinkedList 20 which implements List using a linked list. Who 19 cares if it's longer as we should be using 18 List most of the time. If we have a class 17 implementing many intf we probably should 16 not include all the intf as the shadows 15 the real purpose of the class. IN the case 14 something removed without the intf makes 13 sense. Eg ppl call me by name not Person, Sibling, developer 12 etc using my name is the best most descriptive 11 name. I suppose if a class is impl a simple 10 intf then call it Default Intf which makes 9 it on ious this is the default implementation 8 of Intf. Names of classes sHould in the 7 end be human readable and almost a short 6 phrase describing their purpose. Prefix 5 codes etc are not great as we communicate 4 with words not codes. Computers do t cAre 3 what classes are called so why remains is 2 that we name things so the names help us 1 and our colleagues.

I seems to traditional convention from Hungarian 8 Notation. Interface Naming Guidelines says "Prefix interface names 7 with the letter I, to indicate that the 6 type is an interface." Framework Design Guidelines also says "DO 5 prefix interface names with the letter I, to 4 indicate that the type is an interface."

It 3 is just a coding convention, So it's to 2 hard to determine good or bad. Important 1 things is consistency.