2. SOLID
• These principles not only help in writing a well-structured
code but they also make sure that the code can easily be
extended later.
• If developers design and implement their codes without
using structured design principles such as SOLID principles,
they will create long-lasting problems for other developers
that will want to work on the project in future.
• Software Rot or Code Rot or Software Erosion is either a
slow deterioration of software quality over time or its
decreasing responsiveness, which will eventually lead to
software becoming faulty, unusable, and in need of
upgrade.
3. Single Responsibility
• Single Responsibility, as its name suggests, means that your classes should
have only one responsibility
• The reason behind Single Responsibility is that it makes your class more
complex and lead to code duplication issues which almost always ends up
with non-updated codes.
4. Open-Closed Principle
• This means that your software entities like classes, functions, modules etc. should be open to
extension but not modification.
• This is a very basic principle that should be followed no matter what platform you are coding
for.
• This principle requires you to write a class or function or module in a way that it does need to
be changed whenever your requirements change.
• For example, if you are making a class to calculate the area of a shape like a circle then you
shouldn’t change the class every time a new shape comes as an input.
• Designing a base class and then extending it with the help of inheritance, or any other
technique depending on the language you are using, is the way to go.
5. Liskov Substitution Principle
• “Objects should be replaceable with their subtype instances
without having the need to alter the program.”
• In short, you can replace the objects of List with any of its
subtype without causing the program to break
6. Interface Segregation Principle
• The Interface Segregation Principle states that there should be a lot of
Client-specific User Interfaces rather than a general purpose User
Interface.
• A general purpose User Interface will make your code complex because of
the multiple callbacks as well as make the user confused. Remember,
always give users small achievable goals rather than a big time-consuming
task.
7. Dependency Inversion Principle
• High-level modules should be independent of the low-level
modules. Both should depend on abstractions.
• Details should depend on Abstractions instead of Abstractions
depending on the Details.
• requirements for an application changes a lot. And, changes
are risky.
• So, making your modules independent will make them
reusable as well as significantly reduce the risks involved in
changing the implementations.
