4

Pretty simple question. Should package structure closely resemble class hierarchy? If so, how closely? Why or why not?

For instance, let's say you've got class A and class B, plus class AFactory and class BFactory. You put class A and class B in the package com.something.elements, and you put AFactory and BFactory in com.something.elements.factories. AFactory and BFactory would be further down the hierarchy package-wise, but they'd be further up class-wise. Is this sort of thing a good idea or a bad idea?

Panzercrisis
  • 3,145
  • 4
  • 19
  • 34
  • Something to consider: one way (among many other considerations) of packaging is to look at the frequency / volatility of releases (updates, changes, etc) http://stackoverflow.com/questions/63142/the-reuse-release-equivalence-principle-rep – rwong Nov 13 '13 at 02:38

2 Answers2

5

According to Uncle Bob, classes should be grouped together into packages if they change together. Presumably, if class A changes, then class AFactory would need to change as well, but class BFactory would not. So, if A and B are unrelated, then each should be in a separate package together with the corresponding factory. On the other hand, if there is a dependency between A and B that forces you to change one when you change the other, then the two classes and the two factories should all be in the same package.

If you follow this pattern, then you should be able to build each package into a separate library, independently of the other one.

Dima
  • 11,822
  • 3
  • 46
  • 49
  • While the advice is quite handy, I don't think it completely answers the question leaving a single package structure uncovered. – superM Nov 13 '13 at 13:36
  • I am not sure I understand what you mean. What single package structure? – Dima Nov 13 '13 at 15:22
  • You've explained a method of placing classes together in a package, but IMHO the question was more about how to structure the classes inside the package. – superM Nov 13 '13 at 17:24
  • 1
    @superM, sorry, but that's not what I understood. The class structure is given. The question is about how to organize the classes into packages. – Dima Nov 13 '13 at 18:06
  • What about when there are many different classes for different purposes that still end up changing together, and you want to organize more or build packages or libraries on top of other ones? Would it be the same principle, except just trying to group by how much certain classes change together? – Panzercrisis Nov 14 '13 at 13:39
0

You are asking the wrong question. It is not whether something is a good or bad idea but whether it is useful.

Consider another developer who has to deal with your code. What will they understand from the package structure? Will it improve their understanding and ability to maintain and expand you code, or will it make them want to change it?

The technical aspects of OO are clear, inheritance and polymorphism (implements/extends) amongst others, and these are apparent from the code, along with design patterns. Package structure and naming should be about describing the aims and functionality of the code base (e.g. what is an xxxImpl and how does it work?)

The previous answer talks about coupling and may help in general development, but having the business goals and requirements clearly defined in the overall structure is much more useful.

user108620
  • 11