21
Lately, I’ve heard a lot about the term but for me it’s never clear if it’s a Pattern design or good practice in object orientation. Maybe it’s a very broad question, but why SOLID is useful and when should we use it?
In particular what is the S - Single Responsibility Principle (Principle of Single Liability)?
21
SOLID is a programming principle associated with object orientation. Therefore, it is a rule that is recommended to follow. Some will call it good practice. In fact they are very interesting concepts to learn and know why there are, what problems they solve and especially when to use. The worst thing you can do with it is always use it. The right thing is to use it whenever necessary, when it will bring more benefits than harm. SOLID should be a tool, not the goal, as many people do.
It is useful for organizing applications complex who need a lot of maintenance, who deal with enough uncertainty and that meets many different expectations.
In general, it is only known even when it is useful or not with much experience and deep understanding of everything that surrounds it. As this rarely occurs, people either leave it totally or adopt in everything they do without having a criterion.
Some principles are more important than others. But those who are a big fan of SOLID think that all should be used equally.
It is common to think that to deal with complexity it makes the code even more complex. Of course there are advantages too.
It’s an acronym of the 5 principles that helps you remember them when designing an application.
SIngle Responsibility principle
The class should have a single responsibility, should not do more than necessary. The name must indicate clearly what it does to indicate its unique function. Applies to other entities as well
Software entities should be open to extension, but closed for modification. Thus, it facilitates maintenance and avoids conflicts between versions
Objects in the program can be replaced by instances of their subtypes without affecting the coherence of the application, so the subtype cannot have activities, either in the contract or in the implementation, that are incompatible with the supertype
Interface segregation principle
Interfaces should indicate as little as possible instead of doing everything possible. More interfaces are better than larger interfaces. It’s almost the same thing as the single responsibility applied to the interface
Dependency inversion principle
The code must depend on abstractions and not on concreteness. How something works must be defined by the object and not by the contract used. So it is better to use interfaces as parameters and receive objects that implement it as argument
Browser other questions tagged oop software-engineering solid programming-principles
You are not signed in. Login or sign up in order to post.
What is and how to use SRP?
– rray
What is the Inversion of Dependency Principle (Dependency Inversion Principle)?
– Caffé