Comments on: Naming the Java Implementation Classes

By: Geucimar

Geucimar — Fri, 07 May 2010 02:32:40 +0000

I agree that this is a bad convention. But the problem is that persons like Gavin King used it to appoint as SessionFactoryImpl class.

By: Isa Goksu

Isa Goksu — Wed, 17 Feb 2010 03:37:50 +0000

@beko I guess u lost the point somewhere. If you do have 2 possible implementations of that ReservationService, u should make implementation class names meaningful. In ur example I'd have: com.foo.service.ReservationService (interface), com.foo.service.impl.OpenTableReservationService, com.foo.service.impl.YelpReservationService kinda. If you don't have multiple implementations of that interface, YAGNI should stop u to have an interface there, don't u think?

When u don't give meaningful names to your classes, then as u pointed too, u end up having stupid names like RestaurantReservationService. If you can't give a meaningful name to ur classes, I'd say ur class is either not supposed to be there, or it has more than one reason to change. I hope this clarifies a bit.

By: beko

beko — Wed, 17 Feb 2010 00:33:35 +0000

disagree with u guys.it depends on your business logic.if u need a ReservationService interface and your company is just a restaurant or somethng like that, u cant call its implementations as RestaurantReservationService or RichCustomerReservationService..that would be silly.of course ide can tell us which one is a interface or a concrete impl. so u recommend us to add a impl. package to our projects with exactly the same class names? like com.foo.service.ReservationService and com.foo.service.impl.ReservationService.. =)

By: Isa Goksu

Isa Goksu — Fri, 22 Jan 2010 18:20:21 +0000

@jigar, I see your point. But when you're naming the classes, I believe you should be talking in ubiquitous language. Your design details come after this perspective. In your case I don't think putting base or abstract would make any difference since after a while you'll find everyone is naming their classes BaseXXX, AbstractXXX. And then you'll notice that (in the project I work right now) Abstract classes extending from other AbstractBase classes :) LOL. It's just crazy.

Anyways, I'd rename your cookers like this if it makes sense to you: Cooker (your base or abstract), FastCooker (fast one), SlowCooker (slow one). If you really need to have base and abstract at the same time, I think you should just look at your design, maybe something shouldn't be there. Then again I don't know your context. For interface vs Impl difference that you say, FastCooker cannot be an interface to me. Being Fast and can Cook are 2 different concerns. You're trying to merge them. That's why you think an interface (FastCooker) and an implementation (FastRealCooker) will be needed. I'd say, make CanCook, IsFast and IsSlow interfaces and implement FastCooker with CanCook and IsFast together. You can do better encapsulation with this way.

As I said, all these are just from my perspective. Maybe people think I'm bullshitting. But when I see a name contains Can, Is, Able, etc I know for sure it's interface. Beside, any stupid IDE can tell you if it's an interface or implementation.

By: Jigar Shah

Jigar Shah — Fri, 22 Jan 2010 08:52:15 +0000

One more issue I see here....What if we have and Cooker (interface) AbstractCooker (abstract class), A BaseCooker (Base class to / can be extended by all cookers) and FastCooker, SlowCooker ? Isn't Base and Abstract necessary ?

Same way if we have Cooker enum, It would better spelled as CookerType or CookerEnum ? CookerEnum says its enum and easy to identify at first glance ?

I agree with case of context. FastCookerImpl and SlowCookerImpl is not needed. But What if we Have FastCooker interface and SlowCooker Interface and implementation as FastRealCooker and FastFakeCooker ? Isn't it easier to find "Intf" and "Impl" clearly ?

By: Isa Goksu

Isa Goksu — Mon, 20 Jul 2009 07:57:31 +0000

@dan Spring issue is really weird. Most of its users are using Spring just for DI, nothing more.. I don’t know, IMHO Spring is way big for a DI mechanism. I remember I read an article about how Google Guice is 100 times faster than Spring in DI.. Anyways..

By: dan

dan — Mon, 20 Jul 2009 01:13:32 +0000

You make a good point in your first comment. If you are forced by framework to violate YAGNI and create an interface due to spring, which pushes you to make a decision of creating IPerson or PersonImpl, maybe its time to question the usage of the framework.

By: Isa Goksu

Isa Goksu — Mon, 20 Jul 2009 00:58:40 +0000

@pavel, my point about duplication was not about the Cooker part. It's about the Impl part. It's a suffix that doesn't mean anything. It's like this in your example: CakeCooker, FactCakeCookerClass, HTTPCakeCookerClass, MockCakeCookerClass etc.. Of course it's class, we know that. Why repeat again and again..

Then again, I agree about our nature. That's biggest cumbersome we have actually :)

By: Pavel

Pavel — Sun, 19 Jul 2009 06:57:53 +0000

It costs additional efforts to supply implementation with good descriptive name. People are lazy, it's our nature.

From other side if there is interface CakeCooker then we probably can name implementations like FastCakeCooker, HTTPCakeCooker, MockCakeCooker but it doesn't resolve duplication problem.

BTW often it's harder to get working software then to figure out naming conventions

By: Isa Goksu

Isa Goksu — Sun, 19 Jul 2009 05:18:57 +0000

@andrew, yeah that’s another problem too. If you have only one implementation for that particular interface and it’s hanging there 3 years, then YAGNI says maybe you don’t need an interface there :) A bit of the problem comes from Spring DI mechanism though. But that’s another story..