Software Design Principles (SOLID)

Before moving on Design Patterns let's discuss few things about Software Design Principles.



What are Software Design Principles?
Design Principles are set of guidelines that helps to design a software, which needs to avoid these 3 characteristics
  • Rigidity :- Your design is as flexible as it can be. Because if your design is rigid, your minor change will effect majorly in other part of system.
  • Fragility :- It means when you make a change in system, unexpected part of system breaks.
  • Immobility :- Hard to reuse code in another application because its tightly coupled.

and follow these Five Rules (SOLID):-

Single Responsibility Principle 
A class should be designed with one goal but that doesn't mean it will have only one method. It simply means all methods are created to fulfill class goal.
Also if we have more than one reason to change a class and (changes)they are not aligned with class goal, then it is better to split them in more than one class.
Reference :-
http://www.oodesign.com/single-responsibility-principle.html

OCP (Open Closed Principle)
 This is one of the most fundamental principle for a good design software. This principle state that
"Software entities like classes, modules, libraries functions are open for extension but closed for modification". It clearly means once you have created a class or modules it has all work done in it. For further work you can extend it but you can not modify it.
Simple example is use of Abstract class and use concrete class for implementing behavior.
Real-time Example :- You have created a class parse which have basic functionality of parsing data from file. For parsing a Text file, CSV file or XML file you have to extend parser class and create TextParser, CSVParser and XMLParse class  from that, not add additional conditional code in your Parser class.
Reference :-
http://www.oodesign.com/open-close-principle.html

Liskov's Substitution Principle 
It simply states that a derived class can extend feature of Base Class but can not  change feature of Base Class that results in undesired effects.
Reference :-
http://www.oodesign.com/liskov-s-substitution-principle.html

Interface Segregation Principle 
It states that client should not enforce to implement interface's they don't use. So its better to split interface into small interfaces according to their work ethics.
Reference :-
http://www.oodesign.com/interface-segregation-principle.html

Dependency Inversion Principle 
High Level module should not depend on low-level module. Both should depend on Abstraction.
Abstraction should not depend on Details, and detail should not depend on abstractions.
It means a high level class is not directly work with low level module, they are using interface as abstract layer.
Real-time Example :-
Suppose there is a class Manager which needs to take work from class Worker.
So manage will call  work Method of Worker class. But suppose if we need to introduce a new class SuperWorker(super class of ) Worker. Then we need to change implementation of Manager. Dependency Inversion says that we need to create an Interface which had work method and Worker and SuperWorker will implement this method and Manager will call the Method of this Interface instead of calling class method. So the desired class method will automatically called.
Reference:-
http://www.oodesign.com/dependency-inversion-principle.html











Comments

Popular posts from this blog

Draw Over Screen App Example Android

Sync Adapter Overview

Launch Stock Apps using Intent