A principle is a law or rule that has to be followed, or is an inevitable consequence of something, such as the laws observed in nature or the way that a system is constructed. The principles of such a system are understood by its users as the essential characteristics of the system whose effective operation or use would be impossible if any one of the principles were to be ignored.
In development the most important phase is design. The design phase is where the sense of an application and its pieces come together; design it’s not only about domain model, business objects, architecture and features, but about considering every piece of code that will be part of the whole. In Object Oriented Programming there are some fundamental principles that can guide you to build better software, that can be more readable, clean, testable, extensible and maintainable over time. These are known as the SOLID principles, which consist of 5 rules. Below we will see an introduction to these 5 rules, that can help us to build better software. SOLID is an acronym that is made up of the first letter of every principle, so we’ll go through them in that order.
Single of Responsibility
This principle stipulates that a concrete object can have only one job. For example a Person model object does not need to know details about its environment, or complete tasks related to persistence, notifications (message brokers) or any function outside the object. In sum, its only job is handle the Person state and its characteristics.
Open/Close Principle
According to this principle, you should be able to extend a class’ behavior without modifying it. Please do not confuse this principle with inheritance; it’s about DI (Dependency Inversion) and IS (Interface Segregation). When you understand these principles in depth you will know that they complement and collaborate with each other to help you design software.
Liskov Substitution
The Liskov Substitution principle stipulates that derived classes must be substitutable for their base classes without altering any of the desirable properties. In short, this means behaving as expected. In a future article we will look more closely at this principle, and talk about abstract/concrete classes and interfaces.
Interface Segregation
This principle instructs us to make fine-grained interfaces that are client-specific. ‘Fine-grained interfaces’ refers to interfaces with a small amount of methods. Here ‘client-specific’ signifies that interfaces should define methods that make sense from the point of view of the client that uses the interface.
Dependency Inversion
‘Dependency inversion’ refers to a specific form of decoupling software that depends on abstractions, not on concretions. The name of this principle contains the word inversion, from which we may infer that without following this principle we usually depend on concretions, not on abstractions. The principles tells us to invert that direction: we should always depend on abstractions.
In a future series of articles we will see each principle with some practical examples to try to understand them more clearly to incorporate them in our way of thinking and designing software.
