Loss of loose coupling

Translation of the article LOSING LOOSE COUPLING

When I am asked to attend interviews, I usually ask one candidate question: “What is a good code?”. It is disturbing that you can often hear from recent graduates: "Having good comments." This is the wrong answer. Who teaches them this? Scary. But I was distracted ... I do not think that there is a correct answer to my question, however I would accept something like "strong coupling (high cohesion) and weak coupling (loose coupling)". At least it says something about the code. But if this is a Java developer's job interview, I won't let the poor fellow leave without a few additional questions. Because Java developers are completely crazed. They are obsessed with the desire to chop the code into a super-duper small pieces. We chop and chop until practically nothing remains. As soon as the little paths are separated, we start to worry about them not touching each other. Oh, baby! We must protect them from each other at all costs. Each small piece of code gets its own interface so that it cannot mess its hands by reaching the other parts directly. We link them with magical frameworks. Who use abstract proxies, creating factories and so on.

Imagine a bike made on such principles. The frame is chopped into pieces, 1 centimeter long, connected by the type of spine. Will it be more flexible? Definitely yes. Will it be practical? Of course not. It will be more expensive to produce hundreds of times. It will also break a hundred times more often. Such a bike will lead to more accidents, and last but not least, it will look strange and difficult to ride. Our back must be flexible, so the vertebrae make sense. Bicycles - no.

We do not make bicycles from a single piece of metal or carbon fiber. We can change the wheels, we can change the steering wheel, but we are not crazy about this. Some parts are small, some are large and this is not bad.
')
Another thing we do when developing a bicycle is developing a bicycle, rather than a generic “transportation device”. We do not powder the brain of our customers, that one day they will be able to cross the Atlantic Ocean on it. If they want to do this, then certainly not on our bike. If our customers want to fly up to the roof of a skyscraper, we will not help them much. This is normal. We want to make the best in the world of BIKE. A bike that can be reconfigured into any vehicle and still works well may be an option for Batman, but unfortunately many of us do not have such budgets. We want our systems to be cool, fit for purpose, and we want to know what we are building. Flexibility and configurability for people who do not know what they want, or when you want third-party vendors to develop parts of the system. Bicycle frame makers do not precisely limit their bikes to just one type of seat, one type of steering wheel or one type of wheel. In terms of programming, they are connected to the interface, which can be implemented by any number of specific models of steering wheels. But the frame is their own product, which is not cut into small, replaceable fragments. If they want to make different frames - guess what? They will make different models. Models use many similarities, but they are still completely different.

In programming, we are pursuing the ability to replace parts of our system with any other implementations. If we change one thing, and this leads to the fact that something else stops working, then we see that this is a bad design. But what happens if we put the wheels of the monster truck on our bike? The bike will not work very well, right? But does this also mean that the bike is poorly designed? In the real world, we put up with the fact that things are connected to each other (“zakardkozheny”, if you will), we even prefer such things. We understand why this thing is suitable and why not. The bike needs wheels that fit its frame. We can not just use the interface we must be fairly accurate. The design of the bike, to which you can attach any wheels will be quite complicated. It is not worth it.

If we want our bike to have wheels from a monster truck, it will be necessary to change our design and make something to fit them. And you know what - we can do it in programming. I came to this amazing technique, I don’t know if you can do the same in IntelliJ, but at least in Eclipse (which I use) you can choose a code that needs changing: hold down the SHIFT key and press the cursor buttons until , while the part of the code that needs to be changed will not be highlighted; release the SHIFT key and press DELETE. And the code will disappear! And then you can write something else. It really works! I tried. In Java code too, not only in xml or properties files! This is amazing!

Ever noticed how large corporate projects are worth a fortune, take forever in development and then fail effectively when trying to get a result? There are many reasons for this. But I am convinced one of them is flexibility. Flexibility of the cleaver and vacuum package, individually packaged in mini pieces of generic code. Instead of creating (possibly several) systems that are good in specific known cases, we insist on creating a UNIFIED (super configurable) SYSTEM WHICH ALL CONTROLS. A program that will work for anyone, everywhere, no matter what their needs are.

But what to do if one day we need to change the database? What if we need this data elsewhere? What if the format of this message changes? We can change it. Does the frequency of releases of our systems come first? What if we change them? If our systems are well tested and well designed, change is not a problem.

I am for weak connectivity, but do me a favor: make sure your decision is related to your problem.