At the beginning of the 2000s, the acronym SOLID was introduced for better remembering the main principles of object-oriented programming. Here are the principles:
- Single responsibility principle. This idea means that every module, class, or component should be responsible for only one task. If a class solves several tasks, all the subsystems of this class become intertwined. So, the changes in one place cause the changes all over. A chain reaction is not something a programmer wants to see in the code.
- Open-close principle. The principle says “Software entities should be open for extension, but closed for modification.” It means that whenever you need a change, you add new code to the existing one, but you do not change the code that already works.
- Liskov substitution principle. This principle means that the inheritance classes can be used instead of the parent classes from which they are derived, without disrupting the program. The violation of this rule leads to the violation of the previous one, as the modification of the entity will happen.
- Interface segregation principle. This one stands for the idea that “Many client-specific interfaces are better than one general-purpose interface.” In the word segregation, we trace the initial idea of separation, mentioned at the beginning of the article. We only do what is needed, we do not complement any additional functionality.
- Dependency inversion principle. When the functionality of the application does not fit a single module anymore, a developer should deal with the dependencies. The dependencies should follow the rules: high-level modules shouldn’t depend on low-level modules; abstractions shouldn’t depend on details; details should depend on abstractions.
Studying thoroughly those 5 principles, you can notice a common idea underneath. That’s where we come back to the point of separation. One task for a class, no changes within a working code, a new interface for a new client, only one-way dependencies – all those SOLID principles follow the idea of separate tasks and one task at-a-time.
Now let’s proceed with the ideas of how and what to separate while creating the JS user interface of an application.
Separation in the development
MVC, which stands for Model-View-Control, suggests splitting the whole application into three parts.
- Model – is the data you are using across your application.
- View – is the user interface. It allows users to interact with the interface.
- Control – is the connector between the two. Some data comes to the user from the Model, the user interacts with it in the View, and the Control sends the request to the backend and, when received, renders it through the Model in the View.
The whole MVC reflects the first SOLID principle. Each part is responsible for one task only. If you need to change something, you adjust only one part. If your app consists of parts A, B, C, and D, and you are setting the D part, nothing will happen to the other three. Besides, the team of the developers can be divided, and every person will be responsible for only one part of the project, making it easier to manage.
Separation for the sake of speed
Separation for easier fixing
Separation for readability
This one is quite a logical point which comes as a consequence of all the above-mentioned information. If you keep all your codes in one file, there must be more than 1000 lines of code, which is quite difficult to read and maintain. A more convenient solution is to separately have, for instance, 300 lines of code in the HTML, 300 in the CSS, and 600 in JS.
Interesting Related Article: “10 Reasons to learn Java Programming Language and its Career Benefits“