I am refactoring a large codebase where most of the classes are located in one package. For better modularity, I am creating subpackages for each functionality.

I remember learning somewhere that a package dependency graph should not have loops, but I don't know how to solve the following problem: Figure is in package figure, Layout is in package layout, Layout requires the figure to perform layout, so package layout depends on package figure. But on the other hand, a Figure can contain other Figures inside it, having its own Layout, which makes package figure dependent on package layout.

I have though of some solutions, like creating a Containerinterface which Figure implements and putting it in the Layout package. Is this a good solution? Any other possibilities?


  • 1
    It is modules (e.g. different Jars) can not have circular dependencies. Packages CAN and often HAVE circular depenencies, as long as they belong to the same module.
    – lorus
    Feb 13, 2013 at 7:39
  • @lorus So this is not a design problem?
    – vainolo
    Feb 13, 2013 at 7:59
  • 3
    No, it is not. Packages are normally just a namespaces.This may change only when they used for something else, e.g. to change their contents visibility in OSGi environment. Don't bother otherwise.
    – lorus
    Feb 13, 2013 at 8:08
  • 3
    Note that many authorities condemn cyclical dependencies, and sometimes with good reason, but before you blindly refactor, you should make sure one of those reasons actually applies to you. If the package structure is giving you no trouble, and you cannot, in good conscience, see why it would in the future, don't change something so fundamental just to satisfy abstract architectural values. Feb 13, 2013 at 9:08

2 Answers 2


You should think about Inversion of Control

You basically define an interface for your Layout which is located somewhere near your Layout class in an own package so you would have an implementation package and a public interface package - for instance call it Layoutable (I don't know if that's proper English). Now - Layout won't implement that interface but the Figure class. Likewise you would create an interface for Figure that's Drawable for instance.



Now - Figure implements Layoutable and thus can be used by Layout and (I'm not sure yet if that is what you wanted) - Layout implements Drawable and can be drawn in a Figure. The point is, that the class that exposes some service makes it available by an interface (here: Layout and Layoutable) - the class that wants to use that service has to implement the interface.

Then you would have something like a creator object that binds both together. So the creator would have a dependency to Layout as well as to Figure, but Layout and Figure themselves would be independent.

That's the rough idea.

An excellent source for solutions to this problems is the book Java Application Architecture by Kirk Knoernschild.

  • Isn't this the same as the Container interface as suggested in the question? Feb 13, 2013 at 11:29
  • Yes - and no - I wouldn't put them both in the same package as I stated. And there wasn't much theory behind it. And in this case it is not sufficient to do it one side, you'll have to do it on both sides. Alright?
    – michael_s
    Feb 13, 2013 at 11:32
  • Oops, I missed the bit in the original question about Container going in the same package as Layout. That wouldn't work, whereas your solution would. Feb 13, 2013 at 11:41
  • ah - ok - I seemed to have missed the part with the Container though when I was hacking - should have named it Container ;)
    – michael_s
    Feb 13, 2013 at 11:44

I'm not too clear on what a Figure is, but perhaps it should be in the same package as Layout?

Your proposed Container interface solution wouldn't work - unless you put the Container interface in a 3rd package then you would still have a circular dependency between the two packages. See michael_s's answer for something which would work.

Another thing, as others have mentioned - it will probably never be an issue. You're only going to run into problems in future if Figure and Layout want to be in separate modules. You can deal with this if and when that becomes necessary, but given that the two classes seem quite closely related this seems highly unlikely.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.