In this blog I'll outline four strategies that allow separation of concern with your Java code. I'll assume that Maven is used as the build tool.
For more information on SoC, please read http://en.wikipedia.org/wiki/Separation_of_concerns .
The four strategies are done through:
Randomly place classes in packages
While not being an actual strategy I mention it because of strategy number two. If you ask developers whether they allow this kind of strategy they will vehemently deny using it.
- blatantly easy
- randomly test bits and pieces (if at all :-) )
- I hope you like spaghetti (bolognese)
Have one concern per package
This strategy is mostly subscribed to. Every developer wants to build clean packages that capture one concern per package. Be it a feature package or an integration package.
The thing is that we don't have real tools that guard such architectural concerns. We could use something like http://www.headwaysoftware.com/products/structure101/index.php or http://jboss.org/tattletale but usually it's kept to the developer.
Ultimately this leads to this strategy actually ending up the same as strategy number one. (Trust me, the deadline is always looming.)
- relatively easy
- test concerns on a package level
- almost doesn't need an IDE (vi can be enough )
- needs vigilant developers
Have one concern per module
Let's define a module as a Maven module. We have a single project containing multiple modules. The single project will provide a component that fulfills multiple functions and integrations.
With this strategy we actually have Maven guarding the bounderies of each module (as long as we don't fiddle freely with the dependencies).
- automatic guarding of separation, clean packages
- allows an easy big bang integration test
- a single codebase for multiple concerns
- needs proper integration (is that really a con :-) )
- no more Q&D shortcuts before the deadline
Have one concern per component
- automatic guarding of separation
- isolated development, testing and documenting
- re-usable in different scenarios
- release management
- bottom-up integration testing is needed
- multiple codebases where multiple concerns are spanned
Now most of these cons stem from the fact that there are no tools available to help us out. We don't have a toolbox that says: component development integration tools. Thus releasing many components becomes a choir. Testing each commit on a component doesn't reach up the component integration tree, again we need to invtervene manually. And lastly we loose the overview of when many components are involved and we don't like it when we see something that does not fit our brain.