A train ticket to Brisbane - on the wrong track

The last story told us that we should buy an air ticket. However, some times we do buy train tickets. What will be their destinations? And what can we do with them?

If we do buy some train tickets, the destination of the tickets definitely can not be Brisbane. Well, yes, maybe there are chances to ship the carriages. Let's suppose it is in a common condition and we can't ship the carriages. So, you would probably get a ticket to Guangzhou, a ticket to Hong Kong, a ticket to Hanoi, or a ticket to New Delhi. We can take a train with the ticket we bought and we can arrive at the destination printed on the ticket. Yet, we can't get to Brisbane. If some one bought such a ticket for you, I guess you will be clever enough to make a dicission to refund the train ticket and bought an air ones instead. Even the most stupid ones who do get on the train will get off it as soon as possible. It is because we know that farther we get, the more it costs. It is a common sense, too.

However, in code designing world, we often fail in the simular situations. Here is a funny story:

Long long ago, we started a asp.net project. In the early age of the project, we needed to rewrite paths to cover some meets. So, we created a HttpModule in one of which events we checked the request paths and rewrite the paths in some conditions. We could call it an url rewriting module at that time.

Centuries passed, and one day, we found that we need to mount an equipment called smartcard in order to enhance our security strength in some special scenes. I don't who, since the alphabets were not yet developed and no history about this was recorded, decided to append some codes in this module to achieve the goal. It did achieve the goal. And it seems convinience for the author to write the codes in such a place. It is sure there was no such kind of module which could capture global events except the so called url module. Ah, yeah! I forgot to mention that the module was called url rewriting and smart card supporting module since then on.

Another decades passed, and one day, we found that DOS attack happened. We need an interceptor or a black list. Yet, there is no clue about why but it did happen that some one put the intercepting logic in this module. From then on, its name became the url rewriting, smart card supporting, and DOS intercepting module.

I think you may guess what would happen next. Yes, indeed, there were more and more functions sat inside this module. And one day, we found that the module was named "the url rewriting, smart card supporting, DOS intercepting, error handling, users and directories authorizing, load balancing, logging, access recording and analyzing module. If there were something missed, I can say nothing but a "coffee making" function.

All right, what is wrong? Yeah! It just broke an important rule called "SRP" - Single Responsibility Principle. I think most of you should know this clearly. Nevertheless, there are still too many developpers who do not know that. Or, even worse, some of them know its name but nothing more, and they do not only obey the rule, but also reject it and sweep them out of the code. It is horrible if you are in such a situation because you will found that you are a cleaner, a disrespectable cleaner. Day after day, you will find this job will be becoming more and more unenjoyable.

Okey, let us focus on the story again. After reading this story, you should ask why this happened. I provide two posible answer: One is lack of designers; another one is that concepts were not formed up concretely. In my opinion, one who do not know SRP clearly should not be called a designer. So let us take a look into the second reason.

Sometimes we did know what SRP is, and we did design it in the beginning like our story. However, we would found that the things happened next was out of the track, like our story too. First, you should ask your self whether the concept of the module was defined clearly. In this example, it was. But sometimes it is not, for example: a module for preliminary tasks. If you are in this situation, you should clarify the concept and pick out the frustrating part. Another depressinging situation is that the module was neither limited enough, nor understood by the others enough. If so, you so do the following two steps:

1. Refactory the module with better design patterns so that the others cannot insert irrelevant codes. One pattern I love most is the "Template Method". Maybe you have your own favorite, it does not matter;

2. Train or educate your colleagues. Sometimes they just do not know what they did would harm the quality of the codes.

Overall, it is easier said than done. Probably you would find that you are in the same boat with me.

Next time, maybe I will continue talk about something. Or maybe not, who knows?!