Red Hat
Nov 26, 2010
by Carlo de Wolf

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:

  1. Spagetti
  2. Packages
  3. Modules
  4. Components

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.

 

Pros:

  • blatantly easy
  • randomly test bits and pieces (if at all :-) )

Cons:

  • 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.)

 

Pros:

  • relatively easy
  • test concerns on a package level
  • almost doesn't need an IDE (vi can be enough )

Cons:

  • 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).

 

Pros:

  • automatic guarding of separation, clean packages
  • allows an easy big bang integration test
  • a single codebase for multiple concerns

Cons:

  • needs proper integration (is that really a con :-) )
  • no more Q&D shortcuts before the deadline

Have one concern per component

Pros:

  • automatic guarding of separation
  • isolated development, testing and documenting
  • re-usable in different scenarios

Cons:

  • 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.

http://en.wikipedia.org/wiki/The_Cruelty_of_Really_Teaching_Computer_Science