Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have been reading "Clean Code" by Robert Martin to hopefully, become a better programmer. While none of it so far has been really ground breaking it has made me think differently about the way I design applications and write code.

There is one part of the book that I not only don't agree with, but doesn't make sense to me, specifically in regards to interface naming conventions. Here's the text, taken directly from the book. I have bolded the aspect of this I find confusing and would like clarification on.

I prefer to leave interfaces unadorned. The preceding I, so common in today’s legacy wads, is a distraction at best and too much information at worst. I don’t want my users knowing that I’m handing them an interface.

Perhaps it is because I'm only a student, or maybe because I have never done any professional or team based programming but I would want the user to know it is an interface. There's a big difference between implementing an interface and extending a class.

So, my question boils down to, "Why should we hide the fact that some part of the code is expecting an interface?"

Edit

In response to an answer:

If your type is an interface or a class is your business, not the business of someone using your code. So you shouldn't leak details of your code in this thrid party code.

Why should I not "leak" the details of whether a given type is an interface or a class to third-party code? Isn't it important to the third-party developer using my code to know whether they will be implementing an interface or extending a class? Are the differences simply not as important as I'm making them out to be in my mind?

share|improve this question
2  
I agree with your point. There is a point when too much information hiding is not very helpful. However, Even if you follow this guideline, you would still be able to tell the type using the IDE or an add-on. –  Emmad Kareem Nov 2 '11 at 10:11
2  
This question is essentially known as the question of "Hungarian notation", you should find plenty of arguments and the reason why most non-MS developers abandonded it under this keyword. Hungarian notation was mostly prevalent for variables, but it's essentially the same for types. –  thiton Nov 2 '11 at 12:47
1  
Prior title edit was a terrible one. This question is not about Hungarian notation in general simply because it mentions a convention that might be associated with it. The relative merits of HN are wholly irrelevant here; the question was specifically about interfaces vs. classes and whether or not the semantic differences are important/interesting enough to justify a special-case naming convention. –  Aaronaught Nov 2 '11 at 23:52
    
Re to know whether they will be implementing an interface or extending a class: yes, but most users of your code will call it, not implement it or extend it, and they really couldn't care which it is. –  david.pfx Apr 8 at 11:17
add comment

6 Answers 6

up vote 31 down vote accepted

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.

share|improve this answer
    
Thank you for this breakdown. +1 for the "meaningful distinctions between classes and interfaces..." –  cspray Nov 2 '11 at 1:27
12  
+1 for "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". This is reason enough for me in C#. By following this common standard it is more likely that other .NET programmers with identify the interface. –  Robotsushi Nov 4 '11 at 17:00
1  
As someone who writes both Java and C# the statement "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" cannot be understated - it's one of the things that helps me remember which language I'm working in, –  Aidos Sep 3 '12 at 11:47
1  
Another difference in .NET (but not in Java) is that many .NET languages do not allow interfaces to contain static methods, so hacking the I off an interface can give a good name for a class to hold static methods associated with the interface (e.g. Enumerable<T>.Empty or Comparer<T>.Default). –  supercat Jan 13 at 18:16
add comment

The book is full of good stuff, but I would still add "I" to the interface name.

Imagine you have public interface ILog with a default implementation public class Log.

Now, if you decide to have public interface Log, all of a sudden you have to change Log class to public class LogDefault or something on those lines. You went from having one extra character to seven - surely that's wasteful.

There is often a fine line between theory and practice. In theory this is a really good idea, but in practice it's not so good.

share|improve this answer
add comment

Most answers seem to assume that the programming language is either Java or C# where there is a concept (or keyword) for interfaces / abstract classes. In these cases, in a decent IDE, it is immediately visible with which type of class one deals and writing public interface IMyClass is unnecessary duplication. It is like you wouldn't write public final FinalMyClass - imagine putting every keyword in the classes name.

However, in my opinion in C++ the situation is a little different as one has to dive into the header file and see if the class has any virtual methods to find out if it is an abstract class. In that case, I can clearly see an argument for writing class AbstractMyClass.

So my answer would be: It depends on the programming language.

share|improve this answer
    
Are you sure this answers the question? You might like to read the other answers and clarify some of your points. –  david.pfx Apr 8 at 11:10
    
C++ definitely has interfaces, even if there is no keyword for it. What do you call a class where every member function is pure virtual and there are no member variables? –  John Gaughan Apr 8 at 14:51
    
@david.pfx: I think I precisely answer the question "Should interface names begin with an “I” prefix?": It depends on the programming language. If you think my elaboration is not clear enough, I am happy to improve it - which parts are not clear for you? –  Ela782 Apr 8 at 15:39
    
@JohnGaughan: Sure it has interfaces! But my whole point is that it is about the keyword. C++ doesn't have one, so it is not visible to the IDE/user if he/she deals with an interface or not. In Java, however, it is immediately visible. –  Ela782 Apr 8 at 15:40
    
Read the top-rating answer and compare yours. You are new to SO, and this is an opportunity to learn what kinds of answers attract votes. As it stands, yours won't. With more work, more explanation, more value, it just might. Hang in there! –  david.pfx Apr 8 at 22:46
add comment

In many ways, consistency is more important than convention. As long as you're consistent in your naming schemes, they won't be hard to work with. Prefix interfaces with an I if you like, or just leave the name unadorned, it doesn't matter to me as long as you pick a style and stick with it!

share|improve this answer
2  
+1 for consistency > convention. In C# you would prefix with an I and in Java you wouldn't. Different tasks call for different conventions –  Bringer128 Nov 3 '11 at 9:05
1  
+1 while I'd personally prefer not to have Is on my interfaces, being inconsistent with the BCL and 3rd party libraries used in .Net projects is not an option imho. –  jk. Nov 3 '11 at 10:35
add comment

In my (Java) code, I tend to have this convention in the APIs I expose to callers:

  • Functionality is provided through interfaces, and never by classes.
  • Non-functional parts are classes.

By non-functional, I mean things like pure data structures (such as classes that act as bridges to XML serialization or the ORM), enumerations and exceptions, all of which can't be interfaces (well, you can for the pure data classes, but it's a lot of work for very little gain as there's nothing that those classes do except hold data).

In terms of naming conventions, interfaces tend to map to either actor nouns (e.g., FooBarWatcher) or adjectives (e.g., FooBarWatchable) and both pure data classes and enumerations map to non-active nouns (e.g., FooBarStatus); the IDE can guide the API consumer without special naming conventions. Exceptions follow usual Java conventions (FooBarException, FooBarError, FooBarFault) of course.

I'll also often put the interfaces in their own package or even in their own library, just to ensure that I'm not tempted to break my own rules. (This also helps me manage the build when I'm deriving the code from external sources such as WSDL documents.)

share|improve this answer
    
I also never put I prefixes on interfaces. Of course it's an interface! It's in an API (or SPI)! –  Donal Fellows Nov 2 '11 at 11:44
add comment

Well this is not about implementing the interface or extending a class. In thoses cases, you know anyway what you are doing.

However, when third party code (another module of the application for exemple) manipulates you data, this code should not care if you are presenting an interface or a class.

This is the whole point of abstraction. You are presenting to this third party code an object of a given type. This given type has some member function you can call. That's enough.

If your type is an interface or a class is your business, not the business of someone using your code. So you shouldn't leak details of your code to this third party code.

By the way, interfaces and classes are reference types at the end. And this is what matters. So this is what your naming convention must emphasize.

share|improve this answer
    
@Mat > Yes, that was a mistake of mine, and I edited it. –  deadalnix Nov 1 '11 at 22:35
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.