The Architect´s Napkin

Software Architecture on the Back of a Napkin
posts - 69 , comments - 229 , trackbacks - 0

My Links



Post Categories

Sweet Aspects

When a module has a single responsibility that means it’s focused on producing the behavior of a single aspect. That’s how I described the Single Responsibility Principle (SRP) in my previous article.

Since the SRP is so important and at the same time a bit elusive, I thought, I try to illustrate this “traits and aspects thing” a bit more. Maybe you can even develop a taste for the SRP :-)

Look at this heap of sweets:


Let them represent logic in your code. You know, those 5,000 lines of code in a method, or those 200 methods in a class, or those 1000 classes in a library… It’s all the same. Unstructured stuff. High entropy. Disorder. Not clean. Yet at least ;-)

At some point it might have been a good thing to throw all this together. Maybe that way delivery was faster/easier? You know all those explanation how legacy code just happened over time. Should get into technical debt very consciously; have a plan how to pay it back. But in my experience that’s not how it works for teams. Like many private households (and companies) they stumble and falter and fall; or each time they they borrow it’s an exception and sure will never happen again. Promise! Until the next emergency which requires an exception.

5,000 line methods happen. They happen one line at a time. And each time there is a very good reason why to add the line instead of first refactor the whole heap of logic.

So that’s what there is at the end for 5,000 very good reasons: a huge bag of stuff. A brownfield.


But now is the time to bring order to the chaos ;-) Refactoring time. Let’s apply the SRP. It will make it easier to get an overview of what’s there, to make it easier to pick just the sweet you like most. Or in code: Order will make it easier to understand code, when you want to add new features or fix a bug. Also extending the code will be smoother. Less refactoring, less digging around, less unwanted side effects.

But what kind of order should there be? How to group the parts? Which traits to select to define sets with high cohesion between their elements?

I think, with regard to the depicted sweets people are divided into those who like licorice and those who don’t ;-) So “taste” could be a single trait to split the sweets into sets.

One set has the responsibility to make people happy who like licorice. The other one has the responsibility to make those happy who don’t like it. And then there is a third set with just one sweet which tastes like a gummibear, but with licorice.


Picking just a single trait splits a whole into as many parts as there are values the trait can assume. That might lead to a coarse grained grouping aka modularization as you can see above.

So now let’s pick two traits and see what happens, e.g. “taste” and “form”:


You see, this doubles the groups! There is one for (licorice, cube), (licorice, tube), (gummibear, bear), (gummibear, fruit), (gummibear, frog), (licoricegummibear, bat).

And again. Now with yet another trait: “taste”, “form”, “color”.


Wow! More than 20 groups of sweets. A fine grained modularization, I’d say.

The closer you look, the more traits you learn to distinguish, the smaller the groups/modules covering an aspect become. Yes, that what I’d call the selected traits: an aspect.

The combination of taste+form+color we could call the “gourmet aspect” ;-) It’s relevant for someone who relishes these kinds of sweets.

But someone who needs to pack them up (or is very hungry) might be more interested in the “size aspect” which groups according to the trait volume.


Or someone who wants do use sweets to lay out a picture with them might just look at the “color aspect”:


So as you can see, cohesion sometimes is tangible, but sometimes it’s not. For sweets color, form, size are “hard” traits. You don’t need experience with “using” the sweets in order to group them along these lines. In software it’s easily visible traits like APIs, data, logic that lead to “hard aspects”. You don’t need to understand the domain for modularization - but a scrutinizing view helps.

The trait taste is different though. You need to experience the sweets. Only then you can distinguish values and group the sweets. That’s comparable to parts of logic where just looking at it won’t help to find aspects. You have to really understand it’s parts. What’s the purpose of each line, of groups of statements? Only then you realize their “taste” and can separate them into focused modules.

The result: What formerly was just a heap of stuff - sweets or logic - now is a nicely structured, clean, modularized system of code. Each module having a clear single responsibility on one of several levels of abstraction.


I hope this excursion into an analogy helps you to get am even better grip on the SRP. It’s worth trying. Good modularization is at the heart of any clean coding effort.

Bon appétit! :-)

Print | posted on Monday, April 27, 2015 8:59 PM | Filed Under [ Thinking outside of the box Software architecture ]


No comments posted yet.
Post A Comment

Powered by: