Solid Principles of OOP

Share on facebook
Share on twitter
Share on linkedin
Share on pinterest

Object oriented programming has 5 basic rules that we called solid rules where s stands for Single Responsibility Principle,o stand for Open Close principle,l stand for Liskov Substitution Principle,I stand for Interface Segregation Principle and the last but not lease is  Dependency Inversion Principle.

If you want to use object oriented design in your application or project you must use these rules only using a class,object  and some basic rules like inheritance and Encapsulation doesn’t make your application fully object oriented application.

Here are some advantages of using Solid principals.

  1. Separation of concern in code(S)
  2. Extension in application with less effort (O)
  3. Easy maintenance (O)
  4. fully loosely coupled code(D)

Single Responsibility Principal : SRP states that every class should have only one responsibility and that responsibility should be entirely encapsulated by the class,if the class have more than functionality then it should be split into two classes.

Open Close Principal :   A class should be open for extension, but closed for modification.

In other words, you should never need to change existing code or classes: All new functionality can be added by adding new subclasses or methods, or by reusing existing code through delegation. This prevents you from introducing new bugs in existing code. If you never change it, you can’t break it. It also prevents you from fixing existing bugs in existing code.

Liskov substitution Principal  : LSP states that objects in a program should be replaceable with instances of their subtypes without altering the correctness of that means that we must make sure that new derived classes are extending the base classes without changing their behavior.

Interface Segregation Principle : When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named fat interface or polluted interface. Having an interface pollution is not a good solution and might induce inappropriate behavior in the system.

 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 submodule.

Dependency Inversion Principle : The Dependency Inversion Principle states.High-level modules should not depend on  low-level modules. Both should depend on upon abstractions. abstractions should not depend on  details. Details should depend on upon abstractions. The class should not be dependent on any other class it should be fully loosely coupled. 


Share on facebook
Share on twitter
Share on linkedin
Share on pinterest
Share on whatsapp
Share on email
Author Bio

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Recommended for you
Connect With Us
Stay Connected

Subscribe to our newsletter today to receive updates on latest tech news, tutorials SEO tips many more.

Latest Articles

Free hub for guest blogging nerds and newbie writers

  • Submit Guest Post
  • Share your Knowledge
  • Build your Backlinks
  • Advertise your products
  • Make money by writing
Subscribe to our newsletter today to receive updates on latest tech news, tutorials SEO tips many more.