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

1. 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 theIt takes a touch of genius - and a lot of courage to move in the
opposite directionopposite direction””
- Albert Einstein- Albert Einstein
Indika Maligaspe

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

3. December 2013

Design SmellsDesign Smells

Being SOLIDBeing SOLID

SRP – ?SRP – ?

OCP – ?OCP – ?

LSP – ?LSP – ?

ISP – ?ISP – ?

DIP – ?DIP – ?

QAQA
What we will coverWhat we will cover
Indika Maligaspe

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

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

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

7. December 2013
SRP - SingleSRP - 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
}
}

8. December 2013
A module should be Open for extensionA 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
}
}

9. December 2013
Methods that use references to the base classes must beMethods 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();
}
}
}

10. December 2013
LSP - Liskov Substitution PrincipleLSP - 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.

11. 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 specific
public 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
}
}

12. December 2013
ICP – Interface Segregation PrincipleICP – 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
}
}

13. 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”. DetailsAbstraction” 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.

14. December 2013
DIP - Dependency Inversion PrincipleDIP - 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.

15. 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 5331
703 433 0146
info@rezgateway.com
www.rezgateway.com
Tel :
Fax :
Email :
Web :