Software Development Principles
There are some software development principles is followed by software engineers to solve the problem and build/construct the software. These are the best procedure to avoid issues in build a software.
They are:-
- S.O.L.I.D principle
- Guidelines for Approach the solution
- Guidelines for Implement the solution
S.O.L.I.D principle
S.O.L.I.D principle contains 5 object-oriented principle is followed by software developers when develop a software
- Single responsibility
- Open-Close
- Liskov substitution
- Interface segregation
- Dependency inversion
Single responsibility
“A class should have one and only one reason to change, meaning that a class should have only one job”
This theory emphasizes that a class has only one obligation and therefore should only have one purpose to change. One cause could be program-defined business logic or database logic that should affect the class specification.
Open-Close
“Objects or entities should be open for extension, but closed for modification”
In practice, this denotes developing software entities whose manners can be modified without editing and recompiling the code itself. Consider a technique that just accomplishes one thing to exemplify this idea. Assume it writes to a certain file whose name is hard coded within the procedure. If the requirements change and the filename needs to be changed in particular cases, we must open the mechanism for changing the filename. If, on the other hand, the filename had been provided in as a parameter, we would be able to change the behavior of this function without modifying its source, keeping it closed to change.
Liskov substitution
“Every subclass/derived class should be able to substitute their parent/base class”
The concept states that superclass’s objects must be interchangeable with its subclass’s objects without causing the application to fail. This necessitates that your subclass’s objects act in the same manner as your superclass’s objects. You may accomplish this by following a few guidelines that are quite close to Bertrand Meyer’s design by contract notion.
A subclass’s overridden method must accept the same input parameter values as the superclass’s method. That is, you can create less stringent validation criteria, but you cannot enforce tougher ones in your subclass. Otherwise, any code that uses this method on a superclass object may throw an exception if it is invoked on a subclass object.
The same rules apply to the method’s return value. The return value of a subclass method must follow the same constraints as the return value of a superclass method. You may only impose tougher requirements by returning a particular subclass return a value or by returning a subset of the superclass’s return values.
Interface segregation
“Clients should not be forced to implement methods they do not use”
For software developers, this indicates that you shouldn’t merely start with an existing interface and add new methods. Instead, begin by creating a new interface and then allow your class to implement numerous interfaces as needed. Smaller interfaces imply that developers should favour composition over inheritance and decoupling over coupling. Engineers should strive for a large number of client-specific interfaces rather than a single large, general-purpose interface, according to this idea.
Dependency inversion
“Higher level modules should not depend on lower-level modules, but they should depend on abstractions”
A dependency inversion design is a common technique to comply with this notion, although it is not the only option. Whatever approach you use, incorporating this notion into your code will make it more flexible, agile, and reusable.
References
https://deviq.com/principles/open-closed-principle
https://stackify.com/solid-design-liskov-substitution-principle/
