15
Reservations Gateway Inc. Reservations Gateway Inc. YOUR LINK to e-TRAVEL SOLUTIONS YOUR LINK to e-TRAVEL SOLUTIONS December 2013 - OO Design Principles - - OO Design Principles - Creating ROBUST Applications Creating ROBUST Applications Any intelligent fool can make things bigger and more complex... Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction It takes a touch of genius - and a lot of courage to move in the opposite direction - Albert Einstein - Albert Einstein Indika Maligaspe

Object Oriented Software Design Principles

Embed Size (px)

DESCRIPTION

This presentation explains the principles of S.O.L.I.D. Design principles. I am trying to capture in brief about SOLID and how to practically use them

Citation preview

Page 1: Object Oriented Software Design Principles

Reservations Gateway Inc.Reservations Gateway Inc. YOUR LINK to e-TRAVEL SOLUTIONSYOUR LINK to e-TRAVEL SOLUTIONS

December 2013

- OO Design Principles -- OO Design Principles -

Creating ROBUST ApplicationsCreating ROBUST Applications““Any intelligent fool can make things bigger and more complex... Any intelligent fool can make things bigger and more complex...

It takes a touch of genius - and a lot of courage to move in the It takes a touch of genius - and a lot of courage to move in the opposite directionopposite direction””

- Albert Einstein- Albert Einstein

Indika Maligaspe

Page 2: Object Oriented Software Design Principles

Intro...Intro...

December 2013

Indika Maligaspe

K. Indika Maligaspe

Developer, Designer, Architect , Trainer

Tech Geek specialized in JAVA and .Net

Over 13 years if experience in IT / Web Technologies

Lover of almost all sports... http://www.linkedin.com/profile/view?id=201732082&trk=nav_responsive_tab_profile

Page 3: Object Oriented Software Design Principles

December 2013

Design SmellsDesign Smells

Being SOLID Being SOLID

SRP – ?SRP – ?

OCP – ?OCP – ?

LSP – ?LSP – ?

ISP – ?ISP – ?

DIP – ?DIP – ?

QAQA

What we will coverWhat we will cover

Indika Maligaspe

Page 4: Object Oriented Software Design Principles

December 2013

Rigidity – Difficult to ChangeRigidity – Difficult to Change

Fragility – Can easily break (Xmas Tree)Fragility – Can easily break (Xmas Tree)

Immobility – Hard to Re-UseImmobility – Hard to Re-Use

Viscosity – Need of Hacks vs MethodsViscosity – Need of Hacks vs Methods

Design SmellsDesign Smells

Indika Maligaspe

Page 5: Object Oriented Software Design Principles

December 2013

Rigidity – Difficult to ChangeRigidity – Difficult to Change

Fragility – Can easily break (Xmas Tree)Fragility – Can easily break (Xmas Tree)

Immobility – Hard to Re-UseImmobility – Hard to Re-Use

Viscosity – Need of Hacks vs MethodsViscosity – Need of Hacks vs Methods

Design SmellsDesign Smells

Indika Maligaspe

Page 6: Object Oriented Software Design Principles

December 2013

Five Design Principles to overcome Design SmellsFive Design Principles to overcome Design Smells

Not easy to implement yet neededNot easy to implement yet needed

Not a Rule, but a Guide LineNot a Rule, but a Guide Line

Can be implemented anytime, but earlier is BESTCan be implemented anytime, but earlier is BEST

Every Software Engineer should know ofEvery Software Engineer should know of

What is SOLIDWhat is SOLID

Indika Maligaspe

Page 7: Object Oriented Software Design Principles

December 2013

SRP - Single SRP - Single Responsibility PrincipleResponsibility Principle

Indika Maligaspe

An Object should have one and ONLY one reason to changeAn Object should have one and ONLY one reason to change

public class ErrorLogManager{

public void logToFile(){ // Open File // Check file size and if over limit create a new one // write to File // Close File } public void logToDatabase{ // Open Connection // write to Db // Close Connection }}

Page 8: Object Oriented Software Design Principles

December 2013

A module should be Open for extension A module should be Open for extension and Close for Modificationand Close for Modification

Indika Maligaspe

OCP – Open/Close PrincipleOCP – Open/Close Principle

public class ErrorLogger{ public void log(ILogSource source){ //Logging Code }}public interface ILogSource{ logError(Exception err);}public class FileLogSourcer implements ILogSource{ public void logError(){ // Open File // Check file size and if over limit create a new one // write to File // Close File }} public class DatabaseLogSourcer implements ILogSource{ public void logError(){ // Open Connection // write to Db // Close Connection }}

Page 9: Object Oriented Software Design Principles

December 2013

Methods that use references to the base classes must be Methods that use references to the base classes must be able to use the objects of the derived classes without knowing it.able to use the objects of the derived classes without knowing it.

LSP - Liskov Substitution PrincipleLSP - Liskov Substitution Principle

Indika Maligaspe

Children should not break Parent ClassesChildren should not break Parent Classes

class Bird { public void fly(){} public void eat(){}}class Parrot extends Bird {}class Ostrich extends Bird{ fly(){ throw new UnsupportedOperationException(); }}public BirdTest{ public static void main(String[] args){ List<Bird> birdList = new ArrayList<Bird>(); birdList.add(new Parrot()); birdList.add(new Ostrich()); letsFly (birdList ); } static void letsFly ( List<Bird> birdList ){ for ( Bird b : birdList ) { b.fly(); } }}

Page 10: Object Oriented Software Design Principles

December 2013

LSP - Liskov Substitution Principle LSP - Liskov Substitution Principle contd.....contd.....

Indika Maligaspe

class Bird{ public void eat(){}}

class FlyingBirds extends Bird{ public void fly(){}}

class NonFlyingBirds extends Bird{ public void walk(){}}

class Ostrich extends NonFlyingBirds{ walk(){ }}

How to identify LSP Violation? How to identify LSP Violation?

Derived class may require less functionalities than the Base class, so some methods would be redundant.

We might be using IS-A to check for Super-Sub relationships, but LSP doesn’t use only IS-A,

but it also requires that the Sub types must be substitutable for the Super class. And one cannot decide the

substitutability of sub class in isolation. One has to consider how the clients of the class hierarchy are going to use it.

Page 11: Object Oriented Software Design Principles

December 2013

ISP – Interface Segregation PrincipleISP – Interface Segregation Principle

Indika Maligaspe

Make fine grained interfaces that are client specificMake fine grained interfaces that are client specificpublic interface IAnimal { void fly(); void run(); void bark();}public class Bird implements IAnimal { public void bark() { /* do nothing */ } public void run() { // bird running code } public void fly() { // bird flying code }}public class Cat implements IAnimal { public void fly() { throw new Exception("Undefined cat property"); } public void bark() { throw new Exception("Undefined cat property"); } public void run() { // cat running code }}public class Dog implements IAnimal { public void fly() { } public void bark() { // dog barking code } public void run() { // dog running code }}

Page 12: Object Oriented Software Design Principles

December 2013

ICP – Interface Segregation Principle ICP – Interface Segregation Principle contd....contd....

Indika Maligaspe

public interface IFlyable { void fly();}public interface IRunnable { void run();}public interface IBarkable { void bark();}public class Bird implements IFlyable, IRunnable { public void run() { // running bird code } public void fly() { // flying bird code } }public class Cat implements IRunnable{ public void run() { // running cat code }}public class Dog implements IRunnable, IBarkable { public void bark() { // barking dog code } public void run() { // running dog code }}

Page 13: Object Oriented Software Design Principles

December 2013

DIP - Dependency Inversion PrincipleDIP - Dependency Inversion Principle

Indika Maligaspe

Depend on abstraction , not concretions.Depend on abstraction , not concretions.

““Abstraction” should not depend upon “Details”. Details Abstraction” should not depend upon “Details”. Details should depend upon abstractionshould depend upon abstraction

class Worker {public void work() {

// ....working}

}class Manager {

Worker worker;public void setWorker(Worker w) {

worker = w;}public void manage() {

worker.work();}

}class ShiftWorker {

public void work() {//.... working much more

}}

We have to change the Manager class

Some of the current functionality from the manager class might be affected.

The unit testing should be redone.

Page 14: Object Oriented Software Design Principles

December 2013

DIP - Dependency Inversion Principle DIP - Dependency Inversion Principle contd....contd....

Indika Maligaspe

interface IWorker {public void work();

}class Worker implements IWorker{

public void work() {// ....working

}}class ShiftWorker implements IWorker{

public void work() {//.... working much more

}}class Manager {

IWorker worker;

public void setWorker(IWorker w) {worker = w;

}public void manage() {

worker.work();}

}

Manager class doesn't require changes when adding ShiftWorkers.

Minimized risk to affect old functionality present in Manager class since we don't change it.

No need to redo the unit testing for Manager class.

Page 15: Object Oriented Software Design Principles

December 2013

Indika Maligaspe

Thank You

Reservations Gateway Inc.Reservations Gateway Inc. YOUR LINK to e-TRAVEL SOLUTIONSYOUR LINK to e-TRAVEL SOLUTIONS

Reservations Gateway Inc.Reservations Gateway Inc.

11654 Plaza America Drive , Unit 645 Reston, Virginia 20190-4700

USA

703 286 5331703 433 0146 [email protected] www.rezgateway.com

Tel : Fax :

Email :Web :