SOLID Principles

SOLID principles are the design principles that enable us to manage with most of the software design problems.

S: Single Responsibility Principle (SRP)

O: Open closed Principle (OSP)

L: Liskov substitution Principle (LSP)

I: Interface Segregation Principle (ISP)

D: Dependency Inversion Principle (DIP)

Single Responsibility Principle

SRP says “Every software module should have only one reason to change”. This means that every class, or similar structure, in your code should have only one job to do. Everything in that class should be related to a single purpose.

Eg: UserService  Class with Register method–>it has validate email, send email etc

refactor in such a way that create new class for Email service and put the email validation and emailsend logic in it and call it from userservice

Open closed Principle

The Open/closed Principle says “A software module/class is open for extension and closed for modification”.

Here “Open for extension” means, we need to design our module/class in such a way that the new functionality can be added only when new requirements are generated. “Closed for modification” means we have already developed a class and it has gone through unit testing. We should then not alter it until we find bugs. As it says, a class should be open for extensions, we can use inheritance to do this.

Liskov substitution Principle

The Liskov Substitution Principle (LSP) states that “you should be able to use any derived class instead of a parent class and have it behave in the same manner without modification”. It ensures that a derived class does not affect the behaviour of the parent class, in other words that a derived class must be substitutable for its base class.

This principle is just an extension of the Open Close Principle and it means that we must ensure that new derived classes extend the base classes without changing their behaviour.

Interface Segregation Principle

The Interface Segregation Principle states “that clients should not be forced to implement interfaces they don’t use. Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one sub module”. Like classes, each interface should have a specific purpose/responsibility.

Dependency Inversion Principle

The Dependency Inversion Principle (DIP) states that high-level modules/classes should not depend upon low-level modules/classes. Both should depend upon abstractions.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s