The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Naming of Java interfaces and implementing classes?

Out of curiousity, what sort of naming conventions do folks here use for interfaces and implementing classes in Java, particularly in the situation where both could be named identically and you need to diffentiate between the two. For example, I have an interface Workflow and a class that provides an OOTB implementation of that interface.

Options as I see it:

a. Call the interface IWorkflow and the implementing class Workflow. Works well and is descriptive, but for some reason I've never liked prefixing interfaces with 'I' though this is prevalent in some large code bases like Eclipse.

b. Call the interface Workflow and the implementing class something like StandardWorkflow, DefaultWorkflow or <ProductName>Workflow to signify the OOTB implementation.

Thoughts and any other suggestions?
Gerald Send private email
Wednesday, April 12, 2006
I avoid the 'I' prefix because I often find myself promoting interfaces to abstract classes as I discover common logic among the implementors. Better refactoring tools would probably make that a non-problem, but I just haven't been able to give up Emacs yet.

I use your convention B quite a lot; I occasionally think it seems a bit redundant to repeat 'Workflow' in a form like 'clas DefaultWorkflow extends Workflow', but I find that it generally enhances readability to do so, and that feels like a good tradeoff.

I suspect the 'I' convention is more useful when you're doing something that requires a separately-declared-but-only-implemented-once interface for many classes, but I solve that problem by avoiding those situations as best I can.
Mark Jeffcoat Send private email
Wednesday, April 12, 2006
one thing to think about...

if you use an ide like IDEA and like to use "find class by name", the IWorkplace style makes finding what you're looking for less nice.

i'm running into that now working with some third-party packages that have about 600 different classes that start with "Abstract".

Basically I don't like duplicating information that's already available in the definition...
Wednesday, April 12, 2006
I don't like to see Java interfaces prefixed with "I" because  I think it's a Microsoft convention from COM. I'd probably go with Workflow for the interface and WorkflowImpl for the implementing class.
John Topley Send private email
Wednesday, April 12, 2006
I use the 'I' convention and find it most helpful.

Its just annoying when using some other package (whose docs could be substantially better) and finding that half the time I need to pass a Something, but of course Something is an interface so I cant create one of those, so now Im looking around for some class that implements it and is suitable for my needs.

Ah... SomethingElse.. No... Thats a blasted interface too. ThatThing? Yes its a class. Oh. It doesnt implement Something. Grrrr.. Finally give in and go generate some javadocs, and find it by looking at the list of things that implement the interface.

A decent naming convention would have saved a good few minutes of frustration.

JFreeChart is particulaly egregious in this respect.
Java GUI Programmer
Thursday, April 13, 2006
"Call the interface IWorkflow and the implementing class Workflow."

No. Now, if you really want to place a prefix on the interface, then fine, but expect me to mock you publicly.
But naming a interface ISomething and a implementing class Something is *censured*. Yes, it compiles. Yes, I can distinguish one from the other. No, it's not a good idea.
Thursday, April 13, 2006
What is a OOTB anyway?
Thursday, April 13, 2006
Out Of The Box.
John Topley Send private email
Thursday, April 13, 2006
The I and C prefixes are defensible in COM because you can't define a class without also defining an interface.  In most languages, you define the interface as an abstraction, and implement it in one or more classes.  In this case though, a class name like Workflow is totally meaningless.  All it does is suggest that it implements IWorkflow, which I can tell from the first line of the class definition.  Give it a name that suggests how it differs from FooWorkflow.
bmm6o Send private email
Thursday, April 13, 2006
The "I" prefix for interfaces is standard in .NET. Works fine, and it's actually useful to distinguish interfaces from abstract classes because there are two big semantic differences (same as in Java AFAIK): you have multiple inheritance from interfaces but not from classes, and you can have implementation in abstract classes but not in interfaces.

So reusing the same name when you promote an interface to an abstract class, as suggested, actually strikes me as a bad idea. Recompiling source code that depends on such a changed library is bound to break anyway, better make it obvious by changing the name.
Chris Nahr Send private email
Thursday, April 13, 2006
Thanks for the comments everyone, I think I'll go with John's suggestion of Workflow as the interface and WorkflowImpl as the implementing class type naming convention. The relationship between the two is clearly explained in the naming convention and it makes it easy to derive what the likely name of the implementing class will be.
Gerald Send private email
Thursday, April 13, 2006
I tend to name an interface XxxInterface and the implementing class Xxx.  I do not like the XxxImpl scheme because that falls apart when a single class implements 2 (or more) interfaces.  I do not like prefixing with I because then when i sort the interfaces/classes, all the interfaces are grouped.
Markus Send private email
Thursday, April 20, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz