some comments to Sonja’s post about switch and cyclic dependencies

*.data.*

Most always I have some package called data. In that package I usually put the classes that contain the data my software works with. For example the data a customer enters or the stuff that is stored in the database or the stuff I retrieve from the database. With that type of structure I ran into a design issue today.

I don’t like it. First of all it could lead to two parallel hierarchies, one containing the “working class(es)” and one containing the “data classes”. Additionally, it’s no silver bullet against CycDep. You still have to worry about the dependencies of your other classes. And if you are able to avoid cycles there, avoiding cycles in data objects should be a piece of cake.

to switch or not to switch

Another code smell I try to avoid like the plague are switch statements. Often enough though, I have to take some data specific Action. It is tempting to use a Factory to produce that Action and switch over some kind of identifier (enums, classes, ints and more) to get the specific Action needed.

The factory method looks nice but the switch isn’t too bad, either. I think I would use the factory method (probably without the 1.5 enum ) because it could improve maintainablility a little bit – if you add a protocol to your list, you are forced to add a getAction method – but it’s a close call.

If you wouldn’t separate you data members in another package you could avoid these ugly dependencies. You could move Protocol to project.actions and everything from project.rmi.actions into project.actions.rmi, thus below Protocol. But I don’t know how much you omitted in your example, so I might be completly wrong…