Big stream about SOLID and GRASP

We have already looked at the high-level division of a project into modules and microservices in order to reduce the number of connections between individual subsystems. As an example, we used a complex growing software system for a large reinforced concrete plant offering strawberry-flavored concrete to VIP clients.

Then we briefly mentioned the principles and patterns of SOLID and GRASP in relation to modules. This topic is interesting in itself, and there are always many questions about it from viewers. Therefore, it will be useful to consider this topic separately, not only using the example of high-level modules, but also at a lower level of dividing the code into procedures, functions, or classes.

Projects usually only grow, becoming more complex. Over time, it becomes increasingly difficult for a programmer to make changes, which extends the work time. The question of how to make life easier for a programmer and a customer with the constant growth of a project is becoming increasingly relevant. This is exactly what we need to solve.

Whether you are developing your own project or someone else's, it is important to understand such things as early as possible, so as not to turn the project code into chaos over time.

And even if you do not want to apply this to a work project now, you can practice on personal projects. This experience will help you during an interview at a more interesting company.

Articles and books often simply list the SOLID principles, forgetting to mention why they are needed. Often they provide code examples without fully explaining the reasons that led the author to this option. As a result, it is difficult to understand what exactly is happening from the code.

After studying such materials, many people strive to apply something to themselves, but due to a misunderstanding of the original idea, the programmer either does it poorly or does it in the wrong place. In the end, it seems that all this is useless and only hinders the work.

There is no point in cramming principles or patterns like SOLID or GRASP for interviews. This is a way of thinking that needs to be lived. In screencasts and streams, we are used to not cramming, but looking for the meaning in what we do. We try to understand the original reasons and experience everything that the author thought about when inventing something. What the author did not like initially and what solution he eventually came to. We can do the same here. Having understood the main idea of ​​​​architectural principles, it will immediately become obvious to us which GoF patterns will help in our code.

If you let the project code drift, without making an effort to improve it, the work usually becomes more difficult. The more unnecessary dependencies, the higher the risk of breaking something. Without understanding the key ideas, it's hard to apply anything.

We often rely on these principles in many screencasts, when writing new code and when refactoring old code. There's a lot of material, but it's scattered. It's helpful to collect it all and create a big picture.