It’s interesting to learn the theory of some software design principles. But in general the students do not understand their motivations, they never worked for real projects, and these concepts still fuzzy for them.

For example they could learn about coupling, cohesion, MVC or ESB. But why I have to master these concepts and hen I have to use them? It’s very easy to learn by heart some UML diagrams, but it’s hard to know when I have to use them, or maybe did some modifications to these concepts to adapt them to my application needs.

To understand better the software design concepts, an interesting idea practiced by some professors is to do a projection to some real world scenarios. Which makes the concept more easy to understand and master.

Let’s take as example the low coupling principle, and do a projection with this real case story:

Mike wants to have a passport, he goes to the administration concerned and he founds Jack

After two days, he returns to give the papers needed, and he founds Patricia:

In the real world, the behavior of Patricia is illogical. The service is not highly dependent to Jack. What’s important is the service provided by the administration to citizens.

The contract is simple, if you want a passport, give us some specific papers. No need to give them especially to Jack.

Moral of the story: If the service is highly dependent to Jack, we will have some problems if some changes occur. Indeed, if Jack is always present, no one will detect any problem, and if not, it will influences the service.

But in the software design, many developers did this big mistake without care if a high coupling is illogical or not. And, what’s annoying is that the problems occur after some future changes, which could influence the whole architecture, and could needs more time and money to fix them.

In software programming it’s better to visualize the concepts and not only master the theory. There are also some tools that help you visualize what happens in your source code by using diagrams like dependency graph, dependency matrix or treemaping technique. We can enumerate JDepend, JArchitect and Structure101 for java and CppDpend for C/C++.

DSM

The Design Structure Matrix (DSM) is a simple, compact and visual representation of a system or project in the form of a square matrix.

Here’s as example the DSM from JArchitect of rt.jar from the JRE. With the matrix we can easily detect the most used packages, dependency cycles and the less used packages.

Tree Maping

Treemaps display hierarchical (tree-structured) data as a set of nested rectangles. Each branch of the tree is given a rectangle, which is then tiled with smaller rectangles representing sub-branches. A leaf node’s rectangle has an area proportional to a specified dimension on the data.

Here’s as as example a treemap from JArchitect to shows all classes using String class.

The diagrams are very useful to visualize easily your source code, and the projection to real world case helps you to master better the motivation behind software design principles. In many cases the theory is not sufficient to understand better a concept.