Many software developers — especially .NET developers — have a habit of putting the “I” prefix when naming interfaces. At first glance, this is good because it helps us to identify quickly whether a class is an interface or not.
But why do we — as clients of the class — need to know about this?
Clearly, typical clients really don’t care. Just invoking the methods provided, and that’s it, knowing that it is an interface is useless. However, there are special clients who do care so that they know the class cannot be instanced — by the new keyword — and need to be implemented or extended.
In most cases, the typical force dominates the other one, thus the “I” prefix is unnecessary. Sometimes it is annoying: if we decide to change the interface to a normal class (or abstract class), we have to remove the prefix. As we know, renaming a type is often awkward!
As a rule of thumb, good names come from problem domains, not solution domains.