SOLID OOP Principle

There are five OOP principles named as SOLID. Each character in the word SOLID stands for a principle which is nothing but a guideline for better design of OOP applications. These five principles are outlined below:

S : Single Responsibility Principle – This principle states that every entity should be assigned only single responsibility. In other words, it recommends for high cohesion.

O : Open Closed Principle – This principle recommends using inheritance and code reuse so as to provide abstraction for complex operations. The closed word is used to mention that the base entities should be defined in terms of interfaces or abstract classes.

L : Liskov Substitution Principle – The Liskov substitution principles guides that one should be using the base class for invoking operations on concrete classes. However it also mentions that the behavior of concrete class method should not be stronger than the one expected from base class. One important point to mention here is that the logic would of concrete class specific for example area method for Square and Rectangle classes will use different formula but eventually they do calculate the area for specific geometry.

I : Interface Segregation Principle – This principle asks the designers to go for different interfaces for different requirements. For example there should be different interface for Stack, Queue and Tree and one should not be using a generic interface named DataStructure for these three different implementations.

D : Dependency Inversion Principle – It is a common scenario for one entity to be dependent on another and can’t be avoided. But usually developers tend to provide a quick fix by making one entity depend upon the details another one. By using abstractions, one can avoid the use of details and code to abstractions. A common example is to use a XMLParser class to parse an XML containing Employee data than to add a “parse” method in the Employee class itself.

There are five OOP principles named as SOLID. Each character in the word SOLID stands for a principle which is nothing but a guideline for better design of OOP applications. These five principles are outlined below:
S : Single Responsibility Principle – This principle states that every entity should be...

There are <strong>five OOP principles</strong> named as SOLID. Each character in the word SOLID stands for a principle which is nothing but a <a href="http://www.javaexperience.com/java-best-practice-avoid-final-for-tdd/" title="Best Practice – Avoid Final for TDD">guideline</a> for better design of OOP applications. These five principles are outlined below:
<strong>S : Single Responsibility Principle</strong> – This principle states that every entity should be assigned only single responsibility. In other words, it recommends for high cohesion.
<strong>O : Open Closed Principle</strong> – This principle recommends using inheritance and code reuse so as to provide abstraction for complex operations. The closed word is used to mention that the base entities should be defined in terms of interfaces or abstract classes.
<strong>L : Liskov Substitution Principle</strong> – The Liskov substitution principles guides that one should be using the base class for invoking operations on concrete classes. However it also mentions that the behavior of concrete class method should not be stronger than the one expected from base class. One important point to mention here is that the logic would of concrete class specific for example area method for Square and Rectangle classes will use different formula but eventually they do calculate the area for specific geometry.
<strong>I : Interface Segregation Principle</strong> – This principle asks the designers to go for <a href="http://www.javaexperience.com/java-marker-interfaces/" title="What are Marker or Tag Interfaces in Java">different interfaces</a> for different requirements. For example there should be different interface for Stack, Queue and Tree and one should not be using a generic interface named DataStructure for these three different implementations.
<strong>D : Dependency Inversion Principle</strong> – It is a common scenario for one entity to be <a href="http://www.javaexperience.com/force-maven-to-download-dependencies-in-eclipse/" title="Force maven to download dependencies in Eclipse">dependent on another</a> and can’t be avoided. But usually developers tend to provide a quick fix by making one entity depend upon the details another one. By using abstractions, one can avoid the use of details and code to abstractions. A common example is to use a XMLParser class to parse an XML containing Employee data than to add a “parse” method in the Employee class itself.

adminhttps://plus.google.com/108156674671499593770/posts[email protected]AdministratorI run this blog with lots of passion. In this website, you will find tutorials on Core Java, Spring, Struts, Web Applications, Portals and Database.
Please support me and the website by sharing the posts on your facebook / twitter. You can tap the share button at the top of each post.
Thanks for the support.Java Experience

I run this blog with lots of passion. In this website, you will find tutorials on Core Java, Spring, Struts, Web Applications, Portals and Database.
Please support me and the website by sharing the posts on your facebook / twitter. You can tap the share button at the top of each post.
Thanks for the support.