Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

Thanks

share|improve this question
    
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 '13 at 7:39
    
@lorus So this is not a design problem? –  vainolo Feb 13 '13 at 7:59
    
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 '13 at 8:08
    
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. –  Kilian Foth Feb 13 '13 at 9:08
add comment

2 Answers

up vote 3 down vote accepted

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.

So

my.public.package.Layoutable
my.implementation.package.Layout
my.public.package.Drawable
my.implementation.package.Figure

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.

share|improve this answer
    
Isn't this the same as the Container interface as suggested in the question? –  Baqueta Feb 13 '13 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 '13 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. –  Baqueta Feb 13 '13 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 '13 at 11:44
    
Nice idea. thanks! –  vainolo Feb 13 '13 at 13:27
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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