• Post Reply Bookmark Topic Watch Topic
  • New Topic

Impl Classes Are Meaningless  RSS feed

 
sid smith
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have come across java classes whose names end in "Impl" to show that they implement only one interface. I was reading a book called "growing object oriented software guided by tests" and came across a note on Impl classes which says they are meaningless. I understand that Impl will not describe the class which implements an interface. For example ShapeImpl will not tell you if a shape is circle, square or triangle. Other than this, I don't understand the points being made by the author. Can someone please explain it in simple words ?

Thanks.


Sometimes we see code with classes named by adding “Impl” to the single interface they implement. This is better than leaving the class name unchanged and prefixing an “I” to the interface, but not by much. A name like BookingImpl is duplication; it says exactly the same as implements Booking , which is a “code smell.” We would not be happy with such obvious duplication elsewhere in our code, so we ought to refactor it away. It might just be a naming problem. There’s always something specific about an implementation that can be included in the class name: it might use a bounded collection, communicate over HTTP, use a database for persistence, and so on. A bridging class is even easier to name, since it will belong in one domain but implement interfaces in another. If there really isn’t a good implementation name, it might mean that the interface is poorly named or designed. Perhaps it’s unfocused because it has too many responsibilities; or it’s named after its implementation rather than its role in the client; or it’s a value, not an object—this discrepancy sometimes turns up when writing unit tests, see “Don’t Mock Values” (page 237).

 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If a class that implements Booking is named BookingImpl, that sort of implies that it is the only class to implement that interface - because you would have a naming problem as soon as there were another class that also implements that interface. And if you have only a single class implementing an interface, and don't anticipate having another, why make it an interface to begin with?

Aside from that interfaces are generally named something like "...able", so a more standard naming scheme might have an interface Bookable, and maybe a class DefaultBooking that implements it, and then future classes might be named ComplexBooking, VerySpecialBooking etc.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sid smith wrote:Can someone please explain it in simple words ?

I think Ulf's said far better than I could.

I will just add that some of these "conventions" may be imports from other languages - perhaps as a result of a port of a program or application to Java - and there are several others, like Hungarian Notation (often characterised by the use of an 'I' prefix for interfaces), which really don't have any great value in Java.

About the only one I can think of in that category that does make sense is the prefix 'Abstract' for a skeleton implementation of an interface, which you'll find used quite extensively in the Java collections framework (eg: AbstractList and AbstractMap).

HIH

Winston
 
sid smith
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ulf Dittmer wrote:If a class that implements Booking is named BookingImpl, that sort of implies that it is the only class to implement that interface - because you would have a naming problem as soon as there were another class that also implements that interface. And if you have only a single class implementing an interface, and don't anticipate having another, why make it an interface to begin with?

Aside from that interfaces are generally named something like "...able", so a more standard naming scheme might have an interface Bookable, and maybe a class DefaultBooking that implements it, and then future classes might be named ComplexBooking, VerySpecialBooking etc.


Thank you. Its crystal clear. The author makes it so sound complicated. I wonder why some authors don't use simple sentences and simple examples.
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is one situation I have seen this and think it might be legitimate. There are times you want to present an interface that a user might use, but whose implementing class is hidden. There is likely just one implementation, but the user of your code would never make one (or rather should or could not make a functional one), and would probably never need to know the specific class used.

For example, JEE has an HttpSession interface. Servlet containers would provide implementations that work in their container. It wouldn't surprise me or offend me if one of them called their implementation HttpSessionImpl because the only thing it is is an implementation of the HttpSession in their container. And no user of the container needs to make or reference that class, and they can't mix it up with some other HttpSession implementation. So how would you rename it to avoid duplication of the name? Surely calling it TomcatHttpSession (for example) is just as much duplication as HttpSessionImpl, and naming it HttpSession (but in a different package) is more confusing.

What differentiates this from other scenarios is that the JEE API is created by one group (Oracle), and the implementation by another (container maker). So the use of an interface is required to normalize use across implementations, even if there is ever only one implementation in a given container.
 
Stevens Miller
Bartender
Posts: 1445
30
C++ Java Netbeans IDE Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sid smith wrote:I was reading a book called "growing object oriented software guided by tests" and came across a note on Impl classes which says they are meaningless.

Sometimes we see code with classes named by adding “Impl” to the single interface they implement.
...
A name like BookingImpl is duplication; it says exactly the same as implements Booking...

This is a rare chance to put on my lawyer's hat here in a useful way: This author is not saying that Impl classes are meaningless. He is saying that classes that implement a given interface and call themselves <interface>Impl do not have useful names. The classes themselves might be very useful (or, if you prefer, "meaningful"), but calling a class <interface>Impl doesn't tell you anything about the class, other than (we assume) that it implements <interface>.

Winston and Ulf know a lot more about this stuff than I do, but I will stick my neck out and say that the "...able" suffix for interfaces was, for me, more useful as a learning tool than a standing coding convention. That is, it helped me get over an early difficulty understanding how one could not create an object of type <interface>, but one's methods could have return types of <interface>, if what they were returning were references to instances of classes that implemented <interface>. In the Java standard library, you see this convention used (for example, in the Adjustable interface), but also not used (as in the ObjectOutput interface). My take is that interfaces should follow the same naming conventions as classes, as you will often find yourself being given references of types that may be either a class or an interface, but it won't matter to you at all which one.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stevens Miller wrote:In the Java standard library, you see this convention used (for example, in the Adjustable interface), but also not used (as in the ObjectOutput interface).

And that's because interfaces can define aspects of behaviour or actual things - the most obvious example being Comparable and Comparator. The first is an aspect of a class that would probably exist anyway, so its name is an adjective; the second could almost be an abstract class, so its name is a noun. It's not a universal rule, but when you're trying to think of a name it often helps.

Winston
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!