SOLID: The First 5 Principles of Object Oriented Design

Why we use SOLID Principle

1.Coding standard should a clear idea on developing software in a proper way to avoid bad design

2.Easy to understand and modify

SOLID stands for:

S — Single-responsiblity Principle

O — Open-closed Principle

L — Liskov Substitution Principle

I — Interface Segregation Principle

D — Dependency Inversion Principle

Single-Responsibility Principle the class should have only one reason to change it. It doesnt mean it should contain single method .It can have n number of methods associated with the particular class.

Example of violating Single Responsibility Principle

In the above principle you can see getemailreport() method violates Single Resposibility Principle as its doesnt belong to the class of employee

Example of Single Responsibility Principle

Open-closed Principle

Open for extension closed for modification mean we should not modify the existing class that has been tested instead we can create a new code but not changing existing code.

Example violating Open closed Principle

In case in future if you need to add one extra accounttype mean we have to open the existing class and have to make modification with another else if loop this might affect the already tested code.

Example Of Open closed Principle

In the above example we have created a seprate interface with method interestcalc() and we extend that in three different account class so in future if you want to implement any new account type we can create a new class and extend it without modfying already tested or completed class.

Liskov Substitution Principle

1.The object of the super class should be replaced by the object of the sub class without breaking the application.

2.Object of the subclass should behave in same way of object in super class.

Example of Liskov Substitution Principle

Interface Segregation Principle

we may not need to call all method of interface on a particular class so inorder to avoid that we will be creating seperate interface that needed for the class

Example of Interface Segregation Principle

Dependency Inversion Principle

High-level module must not depend on the low-level module, but they should depend on abstractions.

It helps acheiving lossely coupled

Example violating Dependency Inversion Principle

in the above example Apple class depend on Employee class it means it tigtly copuled in order to make loosely coupeled we can achieve it by abstraction or interface

Example Of Dependency Inversion Principle

Knowledge is everything.Check out my app at https://play.google.com/store/apps/details?id=com.vibe.britevibe

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Layout Optimization in Android

Role Based Authentication and Authorization with DjangoRestFramework and SimpleJWT

Handing Station to mankind

Google embraces the enterprise by taking its cloud (well, Kubernetes) on-prem

Boost Libraries — C++ Libraries for Intermediate Programmers

A picture of programming environment on a desktop

Ecosystem approach to automation

Koalament — Under the Hood

Deep learning on a combination of time series and tabular data.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Pandiyan Mani

Pandiyan Mani

Knowledge is everything.Check out my app at https://play.google.com/store/apps/details?id=com.vibe.britevibe

More from Medium

Code Challenge Review — What Most Reviewers Prefer

Refactoring Summaries

What is the difference between Encoding, Encryption, Hashing?

Design Patterns — Prototype Pattern