Software engineering principles are approaches, styles, philosophies, and best practices recommended by experts in the field of software engineering.
Following the principles can help individual developers and teams to build software successfully which fulfills its intended purpose, built within
stipulated time and budget and which is easily extendable and maintainable.
List of most popular Software engineering principles
Keep It Simple Stupid (KISS)
This principle means that we should keep our implementation simple. Following this principle results in code which people other than the original author
can also easily understand and maintain. Debugging or bug fixing on such a code is also very easy.
Don’t Repeat Yourself (DRY)
This principle states that we should not implement the same behavior in multiple places or copy paste code in multiple places. If we break this principle
than in future if the behavior changes then we will have to update all the instance of the copies, if we miss to update any instance it will result in unexpected
behavior, basically it will create maintenance problems. Following this principle will result in easily maintainable code.
You Aren’t Gonna Need It (YAGNI)
Most programmers suffer from the desire to add all the functionality from the start of the project. But most of this functionality is never used and do not add any
value. This becomes a huge waste of time and effort. This principle states that only add the functionality which is need at the moment and extend your software
when need for new functionality arises. Following this principle saves lot time and effort and also leads to simple implementation.
S.O.L.I.D
Solid is an acronym for a set of five object oriented design principles.
- Single Responsibly Principle (SRP): This principle states that “A class should have one and only one reason to change, meaning that a class should have only one responsibility.” If a class implements multiple responsibilities, making change in one responsibility could have unforeseen side effect on the other responsibilities. Aim of this principle to separate behaviors so that changes made to one behavior, won’t impact unrelated behaviors.
- Open-Close Principle (OCP): This principle states that “Classes should be open for extension and closed for modification.” When new functionality is needed often developers modifies existing well tested code to add new features, which sometimes leads to unforeseen bugs. Aim of this principle is design classes in such a way, that when new functionality is needed it can be added by extending the behavior of existing classes without modifying them.
- Liskov Substitution Principle (LSP): This principle states that “If A is a subtype of class B, then we should be able to replace object of B with object of A without altering the behavior of our program.” This principle simply means that derived classes should extend the the base class without changing behavior. Aim of this principle is to avoid unexpected behavior as a result of change.
- Interface Segregation Principle (ISP): This principle states that “Clients should not be forced to implement interfaces they don’t use.” If a class cannot implement some of the method of an interface then using then class in code can lead to unexpected behaviors. Aim of this principle is to define smaller interfaces so that client can choose composition over inheritance and for decoupling over coupling.
- Dependency Inversion Principle (DIP): This principle states that “High-level modules should not depend on low-level modules. Both should depend on the abstraction. Abstractions should not depend on details. Details should depend on abstractions.” Aim of this principle is to reduce the dependency of high level modules on the low level modules by introducing an interface.
References:
http://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html
https://en.wikipedia.org/wiki/SOLID
https://martinfowler.com/bliki/Yagni.html
https://en.wikipedia.org/wiki/KISS_principle
https://en.wikipedia.org/wiki/Don%27t_repeat_yourself