What diagrams can tell you

let’s talk about diagrams

I know that many of you may feel sick at the very thought of UML’s, but, whether you want or not, in certain moment of your career you will have to work with them and, what’s more frightening, there’s a chance that you will have to create them on our own.

Why so many programmers don’t like diagrams anyway? Well, I think it’s because of some kind of unwillingness towards something unknown, in this particular case – to the language which is unknown for us. Because that’s what UML really is, a language that isn’t understandable by all of us. It’s a language that not each of us “speaks”.
However, today I don’t want to write about this.

It happens in each language, sometimes we can know essence without deep investigation of details. We just know, that in each sentence there are less important words, as well as those words which matter most.
It’s exactly like with those sentences with word “but” inside. We all know that everything that stands before “but” is irrelevant and the real sense is just after :) And that’s what I want to describe today: cases, when you don’t have to look deeper to understand the context. A quick look at a diagram is enough to get the hang of what is the most important in it.

In presented examples it’s all about quick catch design mistakes, without the need to understand the context, which is described by those diagrams.

„arrows” will tell you everything

Today I want to show you a few cases, a few class diagrams, which tell you that “something is wrong with them” just at first glance. To classify whether a diagram is good or not it would be enough to look at arrows, which determine relationship between classes.
In some cases it is really not worth starting to read the thing that was described by the diagrams, because this first look will tell us not only that something is wrong in here. It will also tell us WHAT exactly is wrong.

inheritance – can’t be too much

Look at the diagram. What can you see?

Inheritance. This is the thing that will draw all your attention just from the beginning. Inheritance tree. This takes your mind from the context, from the reasons of creating such a diagram and choosing a particular solution.

Many programmers after this first contact with diagram probably would move on to investigate what kind of solution was proposed. Yet, I’ve got a different piece of advice. Don’t be such a type of programmer and remember that thing which take all your attention at the beginning, thing which stops you, even if only for a moment, is exactly this thing that you should carefully look at, with extreme attention.

When you see a diagram like this you have to talk with its author a little bit and ask what were the reasons, what were the motives which convinced him or her to draw this picture. Because, well… this is not a good solution. And you don’t have to even start to think about logic behind this, you don’t even have to know what the software is doing. Relationship tree like this may only be a root of many problems in future. Structures like this aren’t readable and often tend to give rise to many special cases. And we end up with bunch of inherited methods, which aren’t really needed at the lowest level.

Remember - composition over inheritance. And with this principle on your mouth go to the author (or ask for help if you are the one:) and with this principle in your mind refactor this design. Thanks to that your functionality will be open for extension and closed for changes.

It happens rarely (never?) that design like this will be the most optimal and one of the best solution possible.

And one more thing. You can notice that in the presented diagram we have only classes with inheritances. Do you think that we should have similarly negatives feelings when we would look at the same diagram, but instead of classes inheritance we would have implementation of interfaces? Would it be another situation that should worry us?

cross fire

On another diagram we can see another group of classes:

It’s a bit crowded here, don’t you think? I believe you know why :) Of course, there are too many arrows here which means that we have too much relations between classes. As you can see, someone forgot about principles of high cohesion and low coupling. Or he just mixed up order of the words and decide to design everything in a totally opposite way :)
As you can see, almost each class is in relation with all the others. Additionally we have also bi-directional relationships. While the second isn’t something wrong, it becomes meaningful when accompanied by so many others relations.

When you design like this is have to know that something is going on. What you can certainly see from the number of relations :)

Often the first step to fix from such a solution is to introduce a proxy classes (take a look at Mediator design pattern). Thanks to this we would avoid these cross relations and responsibility of managing them will be moved to the different class, which would do only this.

This is of course a beginning; however, it’s a good starting point and often just after doing it we know what will have to be done next.

I want to give you a lot

The following is the last diagram that I'd like to show you:

What can you tell about it? Certainly that objects of this classes have got many “goodness”, but the better is not always equal with the many. And proof you have on the picture.

What problems come from solutions like this? Too many dependencies tell us a few things. Firstly, it says in all likelihood that this particular class has to handle too many things. Secondly, there are a lot of places, which have potential influence on the way how it will behave, determines its behavior.

A quick fix for those two problems is extraction of some part of the code from the class which has so many relations to the other classes. You have to convert one class into n less complex where each will be responsible for less amount of instructions. And what goes with this, it would have fewer dependencies and influence from the outside on its behavior also will be smaller.

diagram will tell you the true

Presented examples aren’t the only types of diagrams that tell you a lot about their quality just after giving them a first look. Yet, I think those are the most popular ones.

Of course I will look forward to knowing from you what your diagrams tell. Share your experience in comments :)