Scribd
Upload
36 views

Solid Principles: S - Single Responsibility

Gives Complete Knowledge on Solid Principles

Uploaded by

mukul_mangla
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
36 views

Solid Principles: S - Single Responsibility

Gives Complete Knowledge on Solid Principles

Uploaded by

mukul_mangla
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 11

Solid Principles

S – Single Responsibility
0 – Open Closed Principle
L – Liskov substitution Principle
I – Interface Segregation Principle
D – Dependency Inversion Principle

Benefits:
Loose Coupling
Code Maintainability
Dependency Management

Single Responsibility: A class should have one and only one reason to change, means a class
should have only

Public class book{


Private String book;
Private string author;
// getter setter for book and author
Void print console(){
// prints
// this breaks single responsibility as its unrelated to book class
// create another class for book printer
}
}
Open Closed Principle:

You should be able to extend a class behavior, without modifying it.


Public class operation{
Public double calculate(){
Switch(){
// add operation
//subtract
}
}
}

- One can easily modify the above class and create bugs.
This can be achieved by interface

Public interface operation{


Public double calculate(double a1,double a2);
}

Class AddOperation implements Operation{


@Override
Public double calculate(double a1,double a2){
Return a1+a2;
}
}

Class Division Operation implements Operation{


@Override
Public double calculate(double a1,double a2){
Return a1/a2;
}
}

This way one does not modify the code in the existing class Add Operation.

Liskov Substiution:
Derived classes must be substitutable for their base classes.

Interface Segregation:
Make fine grained interfaces that are client specific.
Classes implementing the interface should not inherit unnecessary methods. Here square class
is implementing volume unnecessarily.
Fix:

Dependency Inversion:
High Level Modules should not depend on Low Level Modules. Both should depend on
abstractions. Here Desktop class is tightly coupled with monitor and keyboard.
Instead of passing generic keyboard qwerty we can have abstract as keyboard can be gaming
keyboard or any other key board. So create an interface keyboard.

Design Patterns:

Why do we Need Design Patterns:

Creational Pattern:

Creational Patterns are related to the way of creating Objects.


Types of Creational Patterns:

Factory Pattern:
Code Example:

Abstract Factory Pattern:


Factory of Factories Producer Class Ex:
Factory Class:
Client will get the Factory instance from Factory of Factory Class:

Singleton Design Pattern:


Private static SingletonClass instance = new SingletonClass();
Since its static only once this object wl be loaded into the memory,making it private means it
cannot be accessed from outside.

You might also like