Naming Conventions

When foo people don’t know how to name things, they call it XXXXImpl. Worse yet are those that perhaps call it Standard. How about you use Default? If there is any deviation, at least people will know about it.

9 Replies to “Naming Conventions”

  1. I soooo hate Impl, why do people still use it?

    Sometimes I also use Simple instead of Default to represent it’s *very simple* implementation

    PS. love the new site style, can u do one for me 😉

  2. Yep Impl sucks! I don’t much like Default either, it seems like, err, the default when you can’t think of anything else! Much the same as impl really. No matter what word(s) you use, the most important thing is that it is in the language of the domain.

  3. I’ve seen Impl a lot ay my current client – mostly because I lost a battle. I said mocking concrete classes was ok, no-one agreed. They had a simple class with a good name, couldn’t name the implementation (class) seperate from the role (interface), so you end up with SimpleName (interface) and SimpleNameImpl (class). Needless to say that the moment they we’re out of the door I was Shfit-F6’ing till the cows came home…

    That said, I still prefer it to people sticking ‘I’ and ‘A’ on front of their interface/class names…

  4. I don’t think it has anything to do with mocking, it’s a smell that people don’t understand what an interface is for. An interface should represents behaviour, i.e. what something does, rather than a class which represents entity, i.e. what something is. Get the two mixed up and you end up with XXXImpl, where XXX is really describing entity and therefore there’s no honest name left for the class.

    I think it’s a common pattern because it’s often much easier to use XXXImpl rather than thinking about the real intent of the code.

    This aplies whether you are using TDD and mock objects or not. However, mocking classes opens up a whole world of concrete class dependencies, which in the long run isn’t going to give you the decoupling and therefore flexibility that TDD, mock objects and OO are intended to provide.

    So you didn’t lose the argument, you were just wrong 😉

  5. I prefer Simple and Default as well but XxxxImpl has an advantage.
    By adding it to the end it groups the interface with the implementations in your packages:

    SimpleName
    SimpleNameImplA
    SimpleNameImplB
    Money
    MoneyImpl

    Default could get ugly:

    DefaultMoney
    DefaultSimpleName
    Money
    SimpleName
    SpecialSimpleName

    Sam’s I and A groups the interfaces and implementations:

    ADefaultSimpleName
    ASimpleMoney
    ASpecialSimpleName
    IMoney
    ISimpleName

  6. We consciously have chosen in our current project to not to create interface for interface sake. But alas we ended up in situation where we have to decide whether to use Default, I/A, Impl? Its a .NET 2.0 project. We have interface which is implemented by WebProxy and WebService. No problem till now as we call eg.
    Interface –> CustomerService
    Proxt –> CustomerServiceProxy
    Class –> CustomerWebService
    But when we wanted to write integration NUnit for CustomerWebService we ran into issue. Looks like in VS.NET 2005 you cannot add project reference to web service project. So we decided we would have to create another project to test it where actual implementation of CustomerService resides. We are calling it RealCustomerService. Default didn’t seem right.

  7. Damian – I disagree that Default and Impl are the same. They might be a lot of them all over the place (the cause might be the same) but for someone coming along, at least it Default might mean something more to them that Impl (the consequence).

    Sam – Though mocking interfaces/classes is another subject altogether I try to avoid it because people get confused and start trying to mock everything instead of thinking about the real interactions between objects. I do agree with you that if you have too many Impl/Default/etc classes, then perhaps the interface is not fine grained enough or something is just not right.

    Petrik – Impl does have its advantages, but it doesn’t really bother me when you use good IDEs, a simple CTRL-T in Eclipse or a ALT+B in IntelliJ!

    Vivek – I think your case is a little unusual because of the number of classes that represent the same thing and using RealCustomerService.

  8. Interesting. After much wailing and gnashing of teeth I decided to use “Standard” as our language of communicating the implementation to be used in production. Impl I don’t like, nor Default.

    We have a number of environments that are used in various modes of testing, and using DI to inject the implementation means that we have in some cases 3-5 different implementations (from mock->production).

    I’d rather eat my own flesh that use any form of Hungarian notation on my classes and interfaces (I, A); just doesn’t communicate well enough for my liking.

    I didn’t really like Standard, but it seemed the “safest” word to use at the time, and I couldn’t think of anything better. So, what do other people use then ?

Comments are closed.