Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

The I Naming Convention

I don’t like the I<something> naming convention for interfaces for various reasons.

Let me explain with an example. Lets say we have IAccount interface. Why is this bad?

  • All I care is, I’m talking to an Account, it really does not matter whether its an interface, abstract class or a concrete class. So the I in the name is noise for me.
  • It might turn out that, I might only ever have one type of Account. Why do I need to create an interface then? Its the speculative generality code smell and violating the YAGNI principle. If someday I’ll need multiple types of Accounts, I’ll create it then. Its probably going to be as much effort to create it then v/s doing it now. Minus all the maintenance overhead.
  • Let’s say we’ve multiple types of Accounts. Instead of calling it IAccount and the child classes as AccountImpl1 or SavingAccountImpl, I would rather refer to it as Account and the different types of account as SavingAccount or CreditAccount. It might also turn out that, there is common behavior between the two types of Account. At that point instead of having IAccount and creating another Abstract class called AbstractAccount I would just change the Account interface to be an abstract class. I don’t want to lock myself into an Interface.

Personally I think the whole I<something> is a hang-over from C++ and its precursors.

Some people also argue that using the I<something> convention is easy for them to know whether its an interface or not (esp. coz they don’t want to spend time typing new Account() and then realizing that its an interface).

The way I look at it is good IDEs will show the appropriate icon and that can help you avoid this issue to some extent. But even if it did not, to me its not a big deal. The number of times the code is read is far more than its written. Maintaining one extra poorly named Interface is far more expensive than the minuscule time saved in typing.

P.S: I’m certainly not discouraging people from creating interfaces. What I don’t like is having only one class inheriting from an interface. May be if you are exposing an API, you might still be able to convenience me. But in most cases people use this convention through out their code base and not just at the boundaries of their system.

In lot of cases I find myself starting off with an Interface, because when I’m developing some class, I don’t want to start building its collaborator. But then when I start TDDing that class, I’ll change the interface to a concrete class. Later my tests might drive different types of subclass and I might introduce an Interface or an Abstract class as suitable. And may be sometime in the future I might break the hierarchy and use composition instead. Guess what, we are dealing with evolutionary design.

  • Stephen Souness

    I agree with you on the naming convention aspect of your post, but I’m curious about what your approach to testing something that interacts with your Account object would be, if the Account is not an interface?

    With interfaces you can easily provide a mock implementation for use in tests.  In my experience of TDD, interfaces aren’t only useful when you have different specialisations of an object.

  • Stephen Souness

    I agree with you on the naming convention aspect of your post, but I’m curious about what your approach to testing something that interacts with your Account object would be, if the Account is not an interface?

    With interfaces you can easily provide a mock implementation for use in tests.  In my experience of TDD, interfaces aren’t only useful when you have different specialisations of an object.

  • @Stephen, most mocking frameworks today support exact same mechanism to mock/stub interfaces, classes and abstract classes. Some frameworks like Mockito and RhinoMock have built in support, while others like EasyMock and JMock (not sure about TypeMock) have class extensions that lets you mock/stub Classes.

    In the TDD community (esp. Interaction Based testing community), lot of people discourage you from mocking classes. I like the spirit of that argument, but there are lots of cases when I would break the guideline and just mock/stub a concrete class.

  • @Stephen, most mocking frameworks today support exact same mechanism to mock/stub interfaces, classes and abstract classes. Some frameworks like Mockito and RhinoMock have built in support, while others like EasyMock and JMock (not sure about TypeMock) have class extensions that lets you mock/stub Classes.

    In the TDD community (esp. Interaction Based testing community), lot of people discourage you from mocking classes. I like the spirit of that argument, but there are lots of cases when I would break the guideline and just mock/stub a concrete class.

  • 5x1llz

    I agree about some annotation to class/interface names do seem like noise. On one hand people want to be expressive and code for future concerns but on the other hand there are a lot of classes/files interfaces and jumping around.

    That being said it’s a minor thing to me to see it there, there are other things people do in code that are far more annoying than unecessary interfaces… so I guess it’s an issue of picking battles… it’s also nice to know that sometimes for consistency there might be a small deviation from principles.

    I’ll also add that there is nothing worse than a developer inflexibly sticking to some prescribed dogma no matter the case.. This whole fist full of Principles thing is taking over the .net world and it’s like groundhog day.. there are always exceptions to the rule and using principles to win an argument sometimes just seems like a copout because they’re not for every case, they’re not an ace in the hole..

    Anyway good points, I do agree with the noise factor of the classes but then if it’s a standard in that project to use interfaces always for whatever reason, then who cares if it breaks YAGNI? you know?

  • 5x1llz

    I agree about some annotation to class/interface names do seem like noise. On one hand people want to be expressive and code for future concerns but on the other hand there are a lot of classes/files interfaces and jumping around.

    That being said it’s a minor thing to me to see it there, there are other things people do in code that are far more annoying than unecessary interfaces… so I guess it’s an issue of picking battles… it’s also nice to know that sometimes for consistency there might be a small deviation from principles.

    I’ll also add that there is nothing worse than a developer inflexibly sticking to some prescribed dogma no matter the case.. This whole fist full of Principles thing is taking over the .net world and it’s like groundhog day.. there are always exceptions to the rule and using principles to win an argument sometimes just seems like a copout because they’re not for every case, they’re not an ace in the hole..

    Anyway good points, I do agree with the noise factor of the classes but then if it’s a standard in that project to use interfaces always for whatever reason, then who cares if it breaks YAGNI? you know?

  • Interface names starting with ‘I’ can be a great way to anthropomorphise your code 🙂
    For example, in your vet application, you could have:
    IAmAVeterinaryProcedure

    public class Injection implements IAmAVeterinaryProcedure, IAmChargeable

    The Injection class has declared what he does in terms of his roles in the system.

    IThinkCodingShouldBeFun 🙂

  • Interface names starting with ‘I’ can be a great way to anthropomorphise your code 🙂
    For example, in your vet application, you could have:
    IAmAVeterinaryProcedure

    public class Injection implements IAmAVeterinaryProcedure, IAmChargeable

    The Injection class has declared what he does in terms of his roles in the system.

    IThinkCodingShouldBeFun 🙂

  • Kalpesh

    I think, the idea of I prefix for interface is to separate it from abstract class (or base class). That is – if you see I in front of any entity, it can be an interface.

    You can see that in .net framework, there are interfaces that start with I (IDisposable)

  • Kalpesh

    I think, the idea of I prefix for interface is to separate it from abstract class (or base class). That is – if you see I in front of any entity, it can be an interface.

    You can see that in .net framework, there are interfaces that start with I (IDisposable)

  • Kalpesh

    Sorry, I am repeating what you have said already.

    I agree that IDE can help differentiate between abstract class and interface. I guess, people define interface to start with and then write classes that implement that interface. And, it could turn out that there are some common things among inheritors. Hence, the need of base class (so the interface idea goes out OR the interface remains, a base class comes in with interface implementation and inheritors derive from base class & interface so that the instances of child class can be substituted for base class OR interface for extra flexibility).

  • Kalpesh

    Sorry, I am repeating what you have said already.

    I agree that IDE can help differentiate between abstract class and interface. I guess, people define interface to start with and then write classes that implement that interface. And, it could turn out that there are some common things among inheritors. Hence, the need of base class (so the interface idea goes out OR the interface remains, a base class comes in with interface implementation and inheritors derive from base class & interface so that the instances of child class can be substituted for base class OR interface for extra flexibility).


    Licensed under
Creative Commons License