In which package should the implementation of a Java interface reside?

Question

Let's say I have an interface:

package org.my.dicom.CEchoSCU;

public interface CEchoSCU {
    // stuff here...
}

I will also have an implementation of the interface:

public class SimpleCEchoSCU implements CEchoSCU {
    // stuff here...
}

My question is, which package should house the implementation? I have seen other developers place the implementation is in the same package as the interface (org.my.dicom, in this case), and also cases where a separate package is used (typically something like org.my.dicom.impl). Other than personal preference, is there any reason to prefer one over the other?

"impl" in packages and classes is IMHO a sign of not putting any effort into your naming conventions. It is a sad state of affairs that this is considered an acceptable convention by so many developers. May as well call it ".actualclass" for all the information it conveys. — Robin, Oct 19 '12 at 14:46

Rohit Jain · Answer 1 · 2012-10-19T14:37:50.590

Well, it is not a hard-and-fast rule as to where would you place your implementation class and interface. You can have them in any package, as long as they can be accessed where they are supposed to be.

But, of course, you would also want to have all your related classes in one package, and the class which is not related to your set of classes, to be in different package.

Most of the times, my approach is that : - I keep my interfaces in a different package, and the implementing classes in different package. That way, if I want to give my interfaces to some one else, then I can directly give away my package that contain all my interfaces.

But again, that completely depends upon your requirement, and the design practice that you follow in your code.

So my choice of package name generally is: -

com.someName.api -> For Interfaces
com.someName.impl -> For Implementing Classes.

That way I can easily separate my api from the implementation.

Scooter · Accepted Answer · 2012-10-19T14:45:40.507

A class implements, among other things, an interface. I would stick the class in a package that is related to what the rest of the class does/contains, not a package that reflects one interface it implements. For instance, if I had 200 classes that implement Printable, I wouldn't stick them all in a package com.mycompany.impl.printable. The Airplane class that implements printable would go in a package with other airplane stuff. The Boat class would go in a package with other boat stuff. The Car class that implements Printable would go in a package with other car stuff.

If all SimpleCEchoSCU (and any other future classes) does is implement CEchoSCU, then you should consider making CEchoSCU an abstract base class and deriving different implementations. And either way, (interface or abstract base class) things would be completely related and I would put them in the same package.

wouldn't completely agree on abstract class - same interface is not a reason to consider an abstract class. abstract class implies inheritance, and inheritance implies more than same interface, implies first level type ancestor same. If you know what I mean. Fish and Bird might have same interfaces, move, breath, but I would consider risky to do any functional code re-usage through inheritance - they are too far different types. Though you may expect to have to much differences in their implementations to do code re-usage. — magulla, Jul 28 '17 at 13:34

Puce · Answer 3 · 2012-10-22T16:23:44.887

I usually follow rules like:

if you want to provide common implementations, put them in the same package (e.g. List and ArrayList)
if you have reusable implementations, but e.g. for different technologies or different business features, put them in separate packages
if you have private implementations, which others should not instantiate directly, put them in *.impl or *.internal packages. This is quite common for OSGi bundles.

Kokozaurus · Answer 4 · 2012-10-19T14:41:01.387

1

I prefer putting the implementation in a package with such name:

path.to.package.of.interface.impl

However, I don't think this is a universal convention and I guess it is something specific to the organization that develops the software.

edited Oct 19 '12 at 14:41

answered Oct 19 '12 at 14:17

Kokozaurus

639
7
22

score 1 · Answer 5 · answered Oct 19 '12 at 14:17

Packages as a rule are a matter of preference and organisation. Some places will use build scripts to filter out API interfaces for example which might be easier to do if they're in separate packages to implementations. Really I think the main thing is to just be consistent so people know what to expect (unless you're using a tool or script that puts restrictions on you).

score 1 · Answer 6 · answered Oct 19 '12 at 14:23

There is nothing wrong to place the implementation class in any package. There will not be any compliation error for this. However it depends on the project code setup where to place the impl classes. In most cases, the implementation classes will be in the same package as of the interface.

However interfaces can be implemented by different breed of classes so in that case, the implementation class and interface will be in different packages.

Example is an Interface Bounceable can be implemented by Ball, Jelly or even a Car!

In which package should the implementation of a Java interface reside?

6 Answers6