Interface Naming – Prefix ‘Can-‘ vs Suffix ‘-Able’

An interface is like a "purely" abstract class. The class and all of its methods are abstract. An abstract class can have implemented methods but the class itself cannot be instantiated (useful for inheritance and following DRY).

For an interface, since there isn't any implementation at all they are useful for their purpose: a contract. If you implement the Interface then you must  implement the methods in the interface.

So the difference is an abstract class can have implemented methods whereas a interface cannot.

The reason they are separate is so a class can implement several interfaces. Java and C# restrict a class to inherent from a single parent class. Some languages allow you to inherit from multiple classes and you could accomplish the work of an interface via a "purely" abstract class. But multiple inheritance has its problems, namely the dreaded Diamond Problem

If you stop to think about it, you'll see that an interface really isn't semantically much different from an abstract class:

• Both have methods and/or properties (behaviour);
• Neither should have non-private fields (data);
• Neither can be instantiated directly;
• Deriving from one means implementing any abstract methods it has, unless the derived type is also abstract.

In fact, the most important distinctions between classes and interfaces are:

• Interfaces cannot have private data;
• Interface members cannot have access modifiers (all members are "public");
• A class can implement multiple interfaces (as opposed to generally being able to inherit from only one base class).

Since the only particularly meaningful distinctions between classes and interfaces revolve around (a) private data and (b) type hierarchy - neither of which make the slightest bit of difference to a caller - it's generally not necessary to know if a type is an interface or a class. You certainly don't need the visual indication.

However, there are certain corner cases to be aware of. In particular, if you're using reflection, interception, dynamic proxies/mixins, bytecode weaving, code generation, or anything that involves messing directly with the environment's typing system or code itself - then it's very helpful and sometimes necessary to know right off the bat whether you're dealing with an interface or a class. You clearly don't want your code to mysteriously fail because you tried to add a class, rather than an interface, as a mixin.

For typical, vanilla, run-of-the-mill business logic code, though, the distinctions between abstract classes and interfaces do not need to be advertised because they'll never come into play.

All of this being said, I tend to prefix my C# interfaces with I anyway because that is the .NET convention used and advocated by Microsoft. And when I'm explaining coding conventions to a new developer, it's far less hassle to just use Microsoft's rules than to explain why we have our own "special" rules.