I find that puns don’t age well in code. I still regret that we use the name Mockery in JMock. One of the clues is that the variable names are always different from the type names. We often write:

Mockery context = new Mockery();

and you write:

IBrowseTheWeb browser

Maybe I’m just too fixed in my ways but I believe I would have more consistent language with:

MockContext context = new MockContext();

Browser browser

The point that Udi was making was that by leveraging the ‘I’ prefix, you can anthropomorphise your interfaces into roles. A class then defines itself in terms of things that it can do.

Have you seen this blog post on Interface Names that was inspired by my experience of that presentation?

JNarrate also contains some good examples of the direction that we took this.

http://www.artima.com/articles/dci_vision.html

Might be interesting to you…

I think your rule of thumb is interesting. IAddOrdersToCustomer looks a bit like a duplicate of its method — except that sometimes it’s really hard to find a better name.

Same with (C#) delegates. Predicate and Converter<I> are reasonable enough, but when you get to Action (”take a thing and do something”) you’ve lost all sense of what role is being performed. Which is OK in some contexts, but not in most.

Maybe the rule of thumb should be that an interface name should convey something beyond what’s already implied by its method signatures?