Internships are a great way to learn the must do and must don’t of the software industry. A really great way to know how do you perform in this industry is by doing interviews. This week I got feedback from the general interview they did here at Encora Academy.
The important thing to carry from this feedback is to know your weakness and strengths in Computer Science and my main technology stacks. One thing I learned from myself this week, is that I get mixed when defining concepts such as OOP and SOLID principles.
To get better at these concepts I continue reading Cracking the Code Interview as well as started a course on SOLID principles. In this essay, I will elaborate on those principles a little bit more, and why they are important.
Avoid the technical debt
Technical debt can have too many concepts, for example. Technical debt can be the extra coding you must to tomorrow, next week, etc., because you decide to take a shortcut instead of delivering the best product.
Another term you can also here is that is a cost, of poorly made decisions regarding code and architecture.
The truth is both of these concepts are correct, as it term says it: something you gotta pay eventually. Can be with money, code, or resources over a period and exhausting time.
When we come around like concepts and practices of code fragility: the tendency of the software to break in many places every time it is changed; or code rigidity: the tendency for software to be difficult to change, even in simple ways. This is when we need to apply the SOLID principles.
What are the SOLID principles?
SOLID Principles are coding standards that all developers should have a clear concept for developing software in a proper way to avoid a bad design; in this case, to avoid technical debt in the future.
They were proposed by Robert C Martin (you may know him as Uncle Bob) and they are used in the object-oriented design for code quality improvements. Also to make code more reusable and reliable.
Single Responsibility Principle
A class should have one, and only one, reason to change.
This explains that one class should only serve one purpose, this does not imply that each class should have only one method but they should all relate directly to the responsibility of the class.
All the methods and properties should all work towards the same goal. When a class serves multiple purposes or responsibilities then it should be made into a new class.
Open-Close Principle
Entities should be open for extension, but closed for modification.
Software entities (classes, modules, functions, etc.) be extendable without actually changing the contents of the class you’re extending. If we could follow this principle strongly enough, it is possible to then modify the behavior of our code without ever touching a piece of original code.
Liskov Substitution Principle
Subclass/derived class should be substitutable for their base/parent class.
It states that any implementation of abstraction (interface) should be substitutable in any place that the abstraction is accepted.
Interface Segregation Principle
A Client should not be forced to implement an interface that it doesn’t use.
This rule means that we should break our interfaces into many smaller ones, so they better satisfy the exact needs of our clients.
Similar to the Single Responsibility Principle, the goal of the Interface Segregation Principle is to minimize the side consequences and repetition by dividing the software into multiple, independent parts.
Dependency Inversion Principle
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Or simply: depend on abstractions, not on concretions.
By applying the Dependency Inversion the modules can be easily changed by other modules just changing the dependency module and the High-level module will not be affected by any changes to the Low-level module.
Conclusion
I admit they are hard to understand, I still read my notes to understand SOLID principles. But the important thing is to get the gist of it and start applying it to your projects so the concept can be master faster.
Next time you are doing a module, class, interface, or some piece of code try to have these principles at hand to know if you are breaking one of them, and of course, know the effective way to fix it.
