Is implementing an interface defined in a subpackage an anti-pattern?

Posted by Michael Kjörling on Programmers See other posts from Programmers or by Michael Kjörling
Published on 2013-10-21T09:43:02Z Indexed on 2013/10/21 10:14 UTC
Read the original article Hit count: 234

Let's say I have the following:

package me.my.pkg;
public interface Something {
    /* ... couple of methods go here ... */
}

and:

package me.my;
import me.my.pkg.Something;
public class SomeClass implements Something {
    /* ... implementation of Something goes here ... */
    /* ... some more method implementations go here too ... */
}

That is, the class implementing an interface lives closer to the package hierarchy root than does the interface it implements but they both belong in the same package hierarchy.

The reason for this in the particular case I have in mind is that there is a previously-existing package that groups functionality which the Something interface logically belongs to, and the logical (as in both "the one you'd expect" and "the one where it needs to go given the current architecture") implementation class exists previously and lives one level "up" from the logical placement of the interface. The implementing class does not logically belong anywhere under me.my.pkg.

In my particular case, the class in question implements several interfaces, but that feels like it doesn't make any (or at least no significant) difference here.

I can't decide if this is an acceptable pattern or not. Is it or is it not, and why?

© Programmers or respective owner

Related posts about java

Related posts about patterns-and-practices