DRY, Separation of Concerns, and AOP

I like this distillation of the DRY principle

“Every piece of system knowledge should have a single, authoritative, unambiguous representation” – Dave Thomas

as it goes with the idea of Separation of Concerns that each module

  • does one thing
  • knows one thing
  • keeps the secret of how it does that thing hidden

Combined, these are a good rule, but in practice how do you keep your code aligned with these principles and implement a few standard requirements such as

  • All service layer operations must be wrapped in a transaction
  • All transactions are secure
  • Send JMS and / or email messages to users if certain business criteria in the service layer logic are met
  • Expose usage statistics for data access objects

OO techniques such as Proxy, Decorator, Command, and Callbacks can help a design stay DRY but these work-arounds are easily “invasive, cumbersome, and weakly typed” (SpringSource). So what pattern do we see emerging? The above examples share that

1:1 principle

“There should be a clear, simple, 1:1 correspondence between design-level requirements and the implementation”

  • 1:n violations of a single design requirement is scattered across multiple parts of an implementation
  • n:1 implementation details for multiple requirements are tangled up inside the same module
  • n:n it’s all mixed up (typical case)

- SpringSource

So why does this matter? Consider a system, even a software system, as a changing, growing organism in space and time vs a static system. It needs to be agile, easy to maintain and scale, easy for new people to contribute to (no spaghetti code or design), etc. Enter AOP.

AOP (Aspect Oriented Programming) is a modularity technology allowing us to decouple application layers and modules through several implementation options and technologies. Which technology you choose depends on constraints and fit of needs. Some are easier to start with yet limiting such as Spring AOP, while others such as AspectJ require the addition of another technology and language yet allow for decoupling but even that is debatable.


This next topic will be in my next blog entry..