Helena Edelson

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.

Aspects

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

“Every module in the decomposition is characterized by its knowledge of a design decision which it hides from all others… It’s interface or definition was chosen to reveal as little as possible about its inner workings” – On the criteria to be used in decomposing a system into modules – Parnas (1972)

“A module is a unit whose structural elements are powerfully connected among themselves and relatively weakly connected to elements in other units” – McClelland and Rumelhart (1995)

“Refactor mercilessly to keep the design simple as you go and to avoid needless clutter and complexity. Make your code clean and concise so it is easier to understand, modify, and extend. Make sure everything is expressed once and only once”. – http://www.extremeprogramming.org/rules/refactor.html

To me, this principle is about writing elegant code, elegant being clean, clear, and concise, which takes an intelligent design to create.