Tuesday, June 25, 2013

Software Design Principles



Different Types of Software Design Principles

Software design principles are a set of guidelines that helps developers to make a good system design. The most important principle is SOLID principle. The short abbreviation is  known as
SOLID

The key software design principles are as:
It is combination of five basic designing principles.

1.           Single Responsibility Principle (SRP)

This principle states that there should never be more than one reason for a class to change. This means that you should design your classes in such a way that each class should have a single purpose means single responsibility.

2.           Open/Closed Principle (OCP)

This principle states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. The "closed" part of the rule states that once a module has been developed and tested, the code should only be changed to correct bugs. The "open" part says that you should be able to extend existing code in order to introduce new functionality.

3.           Liscov Substitution Principle (LSP)

The principle defines that objects of a superclass shall be replaceable with objects of its subclasses without breaking the application. That requires the objects of your subclasses to behave in the same way as the objects of your superclass.

4.           Interface Segregation Principle (ISP)

This principle states that Clients should not be forced to depend upon interfaces that they don’t use. This means the number of members in the interface that is visible to the dependent class should be minimized.

5.           Dependency Inversion Principle (DIP)

The Dependency Inversion Principle states that:

1.     High level modules should not depend upon low level modules. Both should depend upon abstractions.

2.     Abstractions should not depend upon details. Details should depend upon abstractions.

It helps us to develop loosely couple code by ensuring that high-level modules depend on abstractions rather than concrete implementations of lower-level modules. The Dependency Injection pattern is an implementation of this principle



No comments: