After reading Chris Matt’s comments on interfaces, I started noticing all kinds of FooImpl classes in the code over here. As far as I can tell, the only reason for using …Impl for a class name is because the Foo interface only exists to be mocked – so the implementations are FooImpl, MockFoo and any other one-off Foo implementations used in testing.
I like ‘real’ names. I’d prefer to see classes named, say, DefaultFoo or SimpleFoo or BasicFoo instead. FooImpl feels clunky, especially if it’s still there after AdvancedFoo and QuickFoo are created. Is this a good thought, or am I missing something?
These thoughts mostly prompted by reading about PicoContainer, which is cute but seems to promote the naming pattern.
Update: there are better names than DefaultFoo (thanks for anonymous advice)
Liz Keogh, lunivore 
I think DefaultFoo, SimpleFoo and BasicFoo are just as bad names. They don’t tell me anything about WHAT the class does to implement the interface. The difference between an interface and a class is that an interface represents a *relationship* between two objects, while a class represents an “actor” in the system. The design, and therefore the name, of an interface should be driven by the needs of the objects that will use that interface, not by the behaviour of the classes that implement the interface.
Okay; so TableCellRenderer is the interface, and DefaultTableCellRenderer should probably be called StringTableCellRenderer, since all it does is display the toString() method of objects. Similarly DefaultListModel should probably be VectorListModel, and so on.
So why were these classes named Default… in the first place? I assume it’s so that users of the APIs could find them easily… but since Javadocs and decent IDEs can do that regardless of name, there shouldn’t be a need.
So should I use MockFoo until I need a real Foo, then decide what’s special about my peculiar kind of Foo and name it accordingly?
One important lesson I’ve learned while Java programming… never look to the standard APIs for examples of good programming practice. In fact, the opposite usually applies.
Let’s drop the Foo name, since it makes no sense. I’m going to use an example of sending an Invoice to a supplier.
I would design an InvoiceDelivery interface by mocking InvoiceDeliver (using a dynamic mock library) while designing/writing the client(s) of InvoiceDelivery. Eventually I would need to create a class that provided the InvoiceDelivery service to one or more of those client classes. For example, EmailInvoiceDeliverer that sends invoices by email.
Note the different grammatical conventions. The interface name identifies the *Service* being used by client classes. The class name describes what objects of the class are in terms of their responsibilities and behaviour.
It’s a good place to find things called “Default…”.
Okay. I’ve got something here equivalent to “EmailInvoiceDelivery” and “EmailInvoiceDeliverer”. Inspection reveals that the EmailInvoiceDelivery doesn’t actually specify “Email” anywhere. So it should probably be renamed as above, since the clients don’t care how they get their invoices.
Thanks. I shall look out for other examples of poorly named class / interface in my code, and refactor where appropriate.
I think I didn’t explain myself very well. The clients of the class don’t care HOW the invoice is delivered. They just want to be able to use an invoice delivery service. So the interface is named InvoiceDelivery and the name does NOT include how the service is implemented.
On the other hand, the class is providing the invoice service by sending invoices by email, so that fact SHOULD be included in its name.
Oh. I misunderstood your post. Sorry.
np; you’ve been most helpful.
Whoever you are. 🙂
It’s me.
Cheers, you’re a star. Now I know who to bug the next time I have a mad idea. ;-D